[C.CC USERS] Serial questions

[Omer Kilic]

Hi James,

On (14/01/2013 23:28), James Brown wrote:
> 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.

(I am assuming you are using the older, FTDI based Arduino boards)

The FTDI drivers tend to do that after a while, you might find the "CDM 
Uninstaller" utility from [1] useful. Keep the default VID and PID 
intact and it will get rid of the extra port numbers.

When working on Windows, I like to manually assign high COM port numbers 
(like COM99) to my boards so that the incremental numbering scheme 
doesn't interfere with things. You can do this by going into the driver 
options under the Device Manager.


HTH,
Omer.


[1] http://www.ftdichip.com/Support/Utilities.htm


> *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 <http://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
>
>
>
> _______________________________________________
> users mailing list
> users at concurrency.cc
> http://lists.concurrency.cc/mailman/listinfo/users
>