[C.CC USERS] serial.write.int question
matt at jadud.com
Sat Oct 29 14:26:44 BST 2011
On Fri, Oct 28, 2011 at 15:12, Aaron Ryan <bringfire at gmail.com> wrote:
> A: Learning to read HEX is not uncommon.
FWIW, I'll postulate a few reasons (and perhaps they'll make it
somewhere into some kind of documentation):
1. They are more concise.
#FF is 255.
2. They become representative of bit patterns.
#0A is decimal 10. In binary, that would be
So, if you have something that you are masking that is 4 or 8 bits
wide, and you only want the second and fourth elements, the hex value
#0A becomes the concise way to say "turn on bits 2 and 4."
3. Hex values spell fun words.
0xDEADBEEF is a 32-bit value. It is far more fun than 3735928559 in
decimal, or 11011110101011011011111011101111 in binary.
For a while, I think we initialized memory (or something else) in the
Transterpreter to 0xBEEF, because it... spelled BEEF. (Note, I've been
switching between the occam notation for hex values, which is #0A,
while in C it would be 0x0A. No confusion intended.)
4. Hex shows up in datasheets. Lots.
When you have to talk to particular registers on (say) a real-time
clock chip (like the Chronodot or similar), all of the documentation
is in terms of hex values. That's because the documentation is written
by electrical engineers, and to make sure that the Lowly Common People
do not gain access to the Holy Documents, they write the documents in
Code. (Not really.) But, if you balk at hexadecimal representations of
numbers, then the documentation for your hardware becomes even more
> B: delay() is parallel friendly..that is really exciting!
Under the hood, there is code like this:
tim ? current.time
In other words, if you look in the old occam books, and look up TIMER,
you'll see that there is a special channel that can be read from that
gives the current system time. The reason that delay() is
parallel-safe is because there is a channel communication in the
middle of it, which means (like all channel communications) that other
processes will have a chance to execute at that point.
If we did delay() the same way as the Arduino does (simply by
inserting no-op instructions in a loop), then we would block. (In
theory, we could timeslice on loops, but I don't think the Arduino
implementation does this at this time.)
More information about the users