(gert asked me to put this on the forum; this seems to be the best place)
Some automation would help the gertbot, particularly when the programmer wants to do things rapidly with exact timing. I don't know what resources it has, particularly memory, so here goes:
I want to send it an array of DAC values and tell it to set the DAC and read the ADC in a loop, to fill up an array of ADC values corresponding to the DAC values. When that's done I want to read the ADC values.
And if it could repeat sending the array automatically while still being able to accept a new time-per-point and read out the data, that would really be great. Then it could be used to look for a resonance, without disturbing the system under test by interrupting it to set a new time-per-point and restart the signal.
A similar approach with the PWM range would be good for very fast, smooth motor control.

I will see what is possible as this seems a very specific application which would
benefit more from running the whole algorithm on the board.
Beware that the ADC are not very fast (about 1 millisecond per sample) and that the DACs have only limited range.
Furthermore I found that the DACs need to be calibrated as they seem to have a slightly different
range between processors.
I will look at what it takes to produce a waveform from the DACs.
What output sample length and frequency are you thinking off?

In general: the Gertbot can be bulk-erased which will remove the security bit (but also the normal code) after which anybody
can write and download their own code to it.

Gert van Loo wrote:[I will see what is possible as this seems a very specific application which would benefit more from running the whole algorithm on the board.
Beware that the ADC are not very fast (about 1 millisecond per sample) and that the DACs have only limited range.

I need to do some experimenting with a thread that writes DAC samples and gets ADC samples,
and find out how fast it can go reliably. Obviously there will be timing issues from processor context switching. On the other hand, doing it on the RPi can be a lot more versatile. I need to do arrays of thousands of samples, so memory on the gertbot could be limiting if it is done that way.

Gert van Loo wrote:Furthermore I found that the DACs need to be calibrated as they seem to have a slightly different range between processors.
I will look at what it takes to produce a waveform from the DACs.
What output sample length and frequency are you thinking off?

thousands of points, and 1 ms per sample is fast enough for most of the things I want to do.
Do you know about reproducibility and stability, i.e. can I hardwire an amplifier for a particular DAC output and always get the same voltage out of it?

Gert van Loo wrote:In general: the Gertbot can be bulk-erased which will remove the security bit (but also the normal code) after which anybody
can write and download their own code to it.

What information is available for people who want to try writing their own gertbot code?

mikronauts wrote:You will not be able to sample thousands of points every ms.

You will be able to sample thousands of points in just a bit over (number of points)*1ms

assuming you add enough multiplexers / ADC channels

Sorry, I should have been more clear. I want to sample from 1 or 2 ADCs, getting thousands of samples in total, as fast as I can (like 1 or 2 ms per sample).
As I understand it the ADC's are running automatically and to read 2 (or more) of them does not require 2*n ms. It only requires the time to do those serial data transactions.

What information is available for people who want to try writing their own gertbot code?

I will release more information over the weekend.
The processor is a SAM3S2B (which anybody can read from chip)
I will also post the UART code as it took me a looong time to get that running.
(not the UART code itself. I had to match the I/O pins with the various UARTs.)
You can then switch to 115Kbaud giving you more then enough bandwidth to transport
two twelve-bit ADC's values every millisecond. You can also add a flow control (e.g. X-on X-off protocol)
which is currently not required. Keep an eye on http://www.gertbot.com

I would love to give out the full schematics and the software. Unfortunately there are many unscrupulous people out there.
(They call themselves "Robin Hood: Steal from the rich and give to the poor" I am not rich neither are they poor.)
It took me over a year working 96 hours a week as well as 120% of my money to get the products out,
so you can see that I am reluctant to give it all away.

Gert van Loo wrote:
You can then switch to 115Kbaud giving you more then enough bandwidth to transport
two twelve-bit ADC's values every millisecond.

This requires user to reprogram the gertbot. Maybe it would be worthwhile to give it a 'baud-change' command (no board re-design needed for that apparently), or jumpers to select the baud. What is the highest reliable baud?

I would love to give out the full schematics and the software. Unfortunately there are many unscrupulous people out there.
(They call themselves "Robin Hood: Steal from the rich and give to the poor" I am not rich neither are they poor.)
It took me over a year working 96 hours a week as well as 120% of my money to get the products out,
so you can see that I am reluctant to give it all away.

I know how hard it is to get something to the point where I feel it can be released to the ignorant masses, although I am not financially dependent on the return. I'm sure you know best where your interests lie. But I have always believed that the best, most long-lived projects are the ones that release everything and develop a user community with a vested interest in keeping it alive and improving.

Miscellaneous notes and questions on the gertbot hardware and documentation:pdf errata
p. 26, sec. 4.7 read error status: command number '0x06' should be '0x07'
p. 28, sec. 4.10 stop all: 'id' number '0x0A' should be '0x81'
(consistent with command table on p.19 and the action of the GUI)
p. 29, sec. 4.13 read ADC command number '0x0C' should be '0x0D (2 places)
remove '> <MS> <LS>' from the command syntax line
p. 31, sec. 4.17 set ADC/DAC: command number '0x12' should be '0x11'
p. 31, sec. 4.18 board configure: command number '0x??' should be '0x12
The 'emergency halt' command 0xA0 0x17 0x81 0x50 (generated by the GUI) is not found in pdf.pdf clarification
Do these commands: 'Stop All', 'Execute Sync' and 'Emergency Halt' act on all boards simultaneously?
There is no paragraph on 'Execute Sync'.
The 'poll' button on the GUI generates 0xA0 0x16 0x00 0x50 0x50 0x50 0x50
and the return is 0x00 0x16 0x00 0x00 There is no mention of 'poll' or
command number 0x16 in the pdf.GUI error?
The 'sync' button is generating 0xA0 0x15 0x18 0x50 Should the third byte by 0x81?
The command table (sec. 3.4) does have 0x18 but 0x81 would seem to be consistent with certain other commandsQuestions
What are the four pins (I think they are labelled J13) with jumpers on them near J12?
What is J10?
Does the board do anything with the GPIO pins besides the power, ground and serial port?
How to use them since they are blocked?

I have done preliminary testing on GPIO and gertbot operating code for experix, and will be posting a new release including that in near future. If there is anybody who can't wait, I'll send the working version. Best to send me a private message in case I don't get around to checking this forum regularly.

I am sorry: I just saw the "Miscellaneous notes and questions" section.

Do these commands: 'Stop All', 'Execute Sync' and 'Emergency Halt' act on all boards simultaneously?

Yes!

What are the four pins (I think they are labelled J13) with jumpers on them near J12?

They set the board ID.

What is J10?

The JTAG to the controller. The pins are described in the "advanced user guide".

Does the board do anything with the GPIO pins besides the power, ground and serial port?

I assume you mean the Raspberry-Pi GPIO pins.
There is a one signal pin: "attention" which goes to GPIO25 and it shared between all boards.
See section 2.7.2 Connect to J6 (Pi connector) of the manual.
For more information on that: see section 4.18.2 'Attention' signal mode.
It allows the PI to find out if all the stepper motors on all boards are 'done' without having to send commands to the board.

Would it be possible for the Gertbot's processor to also handle rotary encoders, i.e. reading gray code from 2 interrupt pins per motor? It would be nice to send Gertbot precise movement commands without using the Raspberry at all.

I have though about that and I wrote some code two years ago.
You will rapidly run out of pins as you would need four per motor:
Two for the end-stops and two for the encoder.
Also you need a rather different way of controlling the whole thing.
All in all not a trivial amount of SW to write.
At the moment I am in a new job and have little spare time.
You know you can erase the board and write your own drivers....

Your wish has been granted!
Gertbot SW release 2.6 supports quadrature encoders.
With it come a series of new commands like:
- Set current position to X.
- Got position Y.
- Do NOT go past position MAX/MIN (as the end-stops are no longer available)
- When close to max/min/goto position start running slowly (Prevents overshoot)

Gert van Loo wrote:Your wish has been granted!
Gertbot SW release 2.6 supports quadrature encoders.
With it come a series of new commands like:
- Set current position to X.
- Got position Y.
- Do NOT go past position MAX/MIN (as the end-stops are no longer available)
- When close to max/min/goto position start running slowly (Prevents overshoot)

The Gertbot has full support for working with quadrature encoders. You can specify a zero position and
then tell the motor to "run to position X'.
You can also specify max and min positions which it will not go beyond.
It also has support for automatic slowing down near the end point which prevents 'overshooting' .
All that is explained in chapter 7 of the manual which is dedicated to quadrature encoders.