[C.CC USERS] Serial status?

[Matt Jadud]

Hi Goran,

On Sun, Aug 22, 2010 at 4:17 PM, Michael Pirrone-Brusse
<pirronm at allegheny.edu> wrote:
>     The basic Arduino models do only have the one serial port, so I'm not
> sure what would have to go into getting a pair of RF transceivers and an SD

>     Once setup has been called, you've access first to serial.read.byte,
> serial.write.byte, serial.write.int, serial.write.int32 (though I thought

>     What I'd like to do is just point you in the direction of some
> documentation on this subject, but I'm not sure there's any out there...

I have been slammed by getting ready for the semester, so the occamdoc
hasn't gone up. I'll do my best to get that hooked in

My single largest concern, which other members of the group may want
to weigh in on, is the speed of the VM. While we can easily configure
the Arduino to, say, do 9600 8N1, the problem is that our
interrupt-driven serial implementation cannot

1. Handle the interrupt
2. Pass it into the runtime and
3. Get back to get the next character

fast enough. If you're receiving data slowly, then yes, everything is
fine. But if you actually have lots of data coming in at the full 9600
bps rate, then we loose data. This is a problem that I encountered
near the end of the summer, and we haven't yet had a discussion of how
best to fix.

My interim fix was that I provided a C routine that would read into a
buffer until a termination character was found. We used this in our
UAV work this summer for reading from a GPS: the buffer would start
filling when a '$' was seen, and it stops reading when a '\n' is seen.
The problem is that it does this by falling into a polling loop, and
nothing else can happen while that string of characters is being
handled. For the GPS, that was fine, because it only took 2-3ms for
the whole string to come in, anyway.

My point? When you start working in a VM on a device as small/slow as
the Arduino, there are some tradeoffs. In this case, I'm pretty sure
that doing high-speed serial in a process-oriented framework is
something that we're going to have to find a way to manage/inform
users about/etc.

So, Goran, I suspect you can do what you want (I mean, we were able to
handle accelerometers, gyroscopes, GPS, and servos on an Ardupilot
Mega in a UAV application), but you might discover limitations or need
to think about solving problems differently than if you were writing
in C.

Certainly, if you decide to give our tools a go, we're keen to help.

Cheers,
Matt