[CCC DEV] Max effective baud rate...

[Matt Jadud]

Hi all,

It looks like we have a max effective baud rate of 2400 bps (baud?).

Yes, we can communicate data at 9600 (or, probably, higher). However,
we cannot continuously communicate data at that rate.

Here's my first program; I'm running it on an Arduino Mega:

#INCLUDE "plumbing.module"

VAL INT32 BAUD IS 2400:
VAL INT MSG.SIZE IS 6:

PROC mega ()
  SEQ
    serial.setup(TX1, BAUD)
    INITIAL [MSG.SIZE + 1]BYTE str IS "XHELLO*n":
    WHILE TRUE
      SEQ
        SEQ i = 0 FOR (SIZE str)
          SEQ
            serial.write.byte(TX1, str[i])

:

This sends a string "HELLO" over and over, with a single character as
a "flag" (the 'X'). (There are bonus SEQs because I used to have some
other code in there.)

Now, on a Seeed Studio Mega (a Mega variant):

#INCLUDE "plumbing.module"

#INCLUDE "mega.occ"

PROC main ()
  SEQ
    serial.start(0, 57600)
    serial.start(1, BAUD)

    [MSG.SIZE]BYTE buffer:
    WHILE TRUE
      SEQ
        -- First, find our marker
        INITIAL BYTE b IS 'x':
        WHILE b <> 'X'
          serial.byte.in.blocking(1, b)
        -- Then, read in the word HELLO
        SEQ i = 0 FOR (SIZE buffer)
          serial.byte.in.blocking(1, buffer[i])
        -- Then, write it out
        SEQ i = 0 FOR (SIZE buffer)
          serial.write.byte(TX0, buffer[i])
:

I haven't committed the code just yet, but I added a "blocking" read
that just busywaits on the data register.

At 2400 baud, I can run this pair of programs on two AVRs, and get
good data. At 4800 baud, I'm out of luck. I loose data, sometimes miss
the flag, etc.

If I delay on the sender, I can do this at 9600 baud... but, of
course, the data isn't actually arriving that quickly.

This is only problematic if, say, you want to read from a GPS running
at 9600 baud, or (worse) the GPS unit cannot be run below 4800 baud.
In a nutshell, a TVM-based solution to reading character data at this
speed does not, it would seem, work.

I will be tying in a C function to do busy-wait reads on the serial
port so that we can get the UAV group moving. Note that I'm not happy
about #ifdefs in the C code, but I'm in a hurry, so I'm going to throw
one or two in. We can rethink how the C firmwares are generated soon,
but for the moment, this will get the code into the 1280-based
firmware and not the 328-based firmware.

If you have any thoughts about how to do this better, please give a shout.

Cheers,
Matt

-- 
Sent from my TRS-80