[C.CC USERS] Serial questions

Mon Jan 14 23:28:42 GMT 2013

Matt

As usual thank you very much for your help and support.

I haven't had a great deal of time this evening but you seem to have the
Midas touch because I now seem to be up and running.  I have a programme now
successfully sending and receiving a simple on off signal between 2 boards.
That's progress.  I guess I methodically stripped out everything that could
be getting in the way.  So not sure where the problem was.

I still have issues with the serial monitor though (only a minor thing).
Even if I use the following:  serial.setup (TX0, 9600) the monitor still
reports communicating at 57600 and prints garbage when it receives data.

This isn't occam related I don't think:

I get frustrated with the upload process.  Various errors I can't fathom out
about not finding files, not in sync.  In the end I usually end up having to
restart the pc and that solves it.  Would be nice to understand what is
going on there.

Also if anyone can tell me why my pc insists on allocating COM7 and COM8 for
my 2 arduino boards.  As far as I can see I am not using any of the lower
number ports.  Not that important I suppose but would be great to understand
these things better as helps troubleshooting.

Finally, yes you are right I am inquisitive I have now found those
libraries.  Thanks for that.  I promise to keep my nose out!  Seriously
though, it is nice to see how things work.  Again helps troubleshooting
possibly.

Attached code for anyone else's benefit of sender and receiver code.

James

From: jadudm at gmail.com [mailto:jadudm at gmail.com] On Behalf Of Matt Jadud
Sent: 14 January 2013 01:47
To: James Brown
Cc: C.CC USERS
Subject: Re: [C.CC USERS] Serial questions

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/20130114/bc96998c/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sender.occ
Type: application/octet-stream
Size: 1353 bytes
Desc: not available
URL: <http://lists.concurrency.cc/pipermail/users/attachments/20130114/bc96998c/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: receiver.occ
Type: application/octet-stream
Size: 373 bytes
Desc: not available
URL: <http://lists.concurrency.cc/pipermail/users/attachments/20130114/bc96998c/attachment-0001.obj>