[C.CC USERS] Serial questions

Matt Jadud matt at jadud.com
Mon Jan 14 01:46:39 GMT 2013


Hi James,

A few quick answers. I'll have to try things on an Uno to verify.


1.  Can I use the TX RX pins on an uno or are they effectively redundant and
> taken up for use by USB?  I was assuming I could simply have an occam
>

You should be able to use them.


> Code
> Sender
> serial.write.byte (TX0, #AA)
>

FWIW, you can use any of the serial.write.* commands; they'll all go there.
But, you know that.


>
> Receiver
>   WHILE TRUE
>     SEQ
>       serial.read.byte (RX0, read)
>       IF
>         read = #AA
>           detected ! SIGNAL
>         TRUE
>           SKIP
>

That should poll the receiver. (I cannot, at the moment, remember if that
is a blocking call. I'll look it up in a moment.) And, it should work. You
might turn on an LED in your "IF" as a verification of receipt.



> 2.  Using occam serial.write.byte I can get it generate something (i.e. at
> least a flash on the TX LED on board) ONLY if connected to the PC's serial
> monitor (in which case the byte is written out as an ascii character on the
> monitor - that's ok).
>

Weird. Underneath, the code that is doing the serial send is, for all
intents and purposes, identical to what the C libraries for the Arduino
environment do. So, there is nothing special about the PC's serial monitor.


> 3.  I cannot get it to accept anything other than bit rate 57600.  Anything
> else generates garbage on the monitor.
>

Hm.

serial.setup (TX0, 9600)

(or some other baud rate) should do the trick for you. That said, I'd have
to check the Uno to make sure all is well. However, we don't typically make
special concessions for the Uno, so again, all *should* be well here.


> 4.  Looking at the "printing" module code I can see calls to procs such as
> serial.byte.in.  What are these and where are they documented?
>

While this is an open source project, we'd like you to refrain from looking
behind the emerald curtain. NO MORE READING THE SOURCE CODE FOR YOU!

Humor aside, that's an internal function. serial.read.byte converts your
pin number to the appropriate pin number for the hardware you're using. So,
if you were using a Mega, it would translate the external pin number (on
the board) to the chip pin number, so we could talk to the correct location
in memory.

Using those directly is ill advised, unless you're keenly interested in
writing code that is specific to a single MCU in the AVR family, and you
use the mapping PROCs as well.

You'd find those down in the "architecture" directory, BTW. That level of
implementation gets specific to boards and chips.


> 5.  Finally, if I want to use serial comms, will I have to use something
> like "twi" (which seems quite complicated to start out with) or am I just
> doing something hopelessly wrong?
>

We have done exactly what you're doing in the past, with no particular,
special treatment.

That said, I've found that occam-pi is too slow to keep up with fast baud
rates, and you'll probably have to run at 300 baud. (That is, you can use
9600 baud to send characters, but we can't service the receive register
fast enough to keep up with a full-speed stream.)

Push back, James, if you continue to be stuck. That's all
off-the-top-of-my-head, and without hardware in hand. However, you're not
doing anything overly weird, and it should work. (That is, doing sends and
receives over the serial should not be difficult, and TWI is definitely not
necessary. Besides, I never implemented TWI SLAVE in occam-pi, so you
wouldn't be able to set it up as a receiver at the moment, anyway...)

Cheer,
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.concurrency.cc/pipermail/users/attachments/20130113/3bcad0f0/attachment.htm>


More information about the users mailing list