[C.CC USERS] serial.write.int question

Matt Jadud matt at jadud.com
Fri Oct 28 19:08:10 BST 2011

On Fri, Oct 28, 2011 at 12:42, Aaron Ryan <bringfire at gmail.com> wrote:
> ok...thanks...I didn't see that one in the module...will use it instead.

S'ok. I forgot it was there. I still think we should change

serial.write.int ()

to display decimal, and introduce

serial.write.hex ()

to display in hex.

> Asking genuinely, Do people eventually learn to read HEX in the same manner
> as Integers and Decimals?


> Also, is the delay() function the same as its Arduino counterpart, in the
> way that it actually halts program flow or does it only effect the local
> PROC that calls it?  Wondering if I need a "millis" type work around in
> order to call multiple delay()'s without too much slow down.

Nope. This deserves a chapter in the cookbook.

delay (ms)

in occam actually causes a reschedule. If you have multiple parallel processes:

  proc.a (...)
  proc.b (...)
  proc.c (...)

and you have a delay() call in proc.a, then proc.b and proc.c will
have a chance to execute while proc.a is sleeping. Likewise, when you
do a channel communication, that triggers an opportunity for everyone
else to have a turn.

So, in that regard, delaying is exactly *unlike* a delay in C++. In
occam, it is parallel-friendly out-of-the-box.

Does that make sense?


> aaron
> On Thu, Oct 27, 2011 at 1:20 PM, Matt Jadud <matt at jadud.com> wrote:
>> Hi Aaron,
>> On Thu, Oct 27, 2011 at 14:32, Aaron Ryan <bringfire at gmail.com> wrote:
>> > Hey Guys,
>> > I am getting all HEX values from the serial.write.int () PROC.Which
>> > makes
>> > sense looking at "printing.module"  Is there a Process that converts HEX
>> > to
>> > DEC?
>> I sometimes forget what is in the modules, even if I wrote some of the
>> code.
>> PROC serial.write.dec.int (VAL INT port, VAL INT n)
>> That will output a value as a decimal. I'll add it to the cookbook in
>> the obvious place (at the moment).
>> The bigger question is whether the default should be to print in
>> decimal and require the user to specify hex when they want it? That,
>> most likely, is the better behavior.
>> > Are the PROCs described in the docs on this site available in the KROC
>> > build
>> > of the Transterpreter?
>> > http://occam-pi.org/occamdoc/convert.html#name-HEX32TOSTRING
>> This is a good question. I think there are some tricky problems that
>> the group has never decided to tackle having to do with the 16-bitness
>> of the Arduino in making some of those routines work. Anyone else have
>> a comment on this part of the question?
>> Cheers,
>> Matt

More information about the users mailing list