ARM... for stargate.
download arm-linux-gcc package
and substitute gcc with arm-linux-gcc in the Makefile.
Oh... that one byte... 00
Yes... it seems that that one byte does come to sflisten.
Look at prettylisten.c to see how to strip that one byte.
Thanks
- jpaek
KURT PETERS wrote:
OK, any hints on how you modified the makefile in the C SDK to compile
for the ARM in the stargate?
Also, following along with my other thoughts:
is the statement in TEP113 para. 3.4: "SerialDispatcherC places a
one-byte header, the packet format identifier, on the packets sent and
received through SerialP." no longer accurate, since the type's now
contained in AMPacket.type? I didn't notice this preceding value in my
raw output, unless it's the:
"D = Packet format dispatch byte: SerialDispatcherC". Lesson 4
can't possibly be right unless the java code adds that preceding 00 and
strips P & D???????. Of course, I don't know since I'm running the
stargate and can't really do that lesson.
Also, perhaps the title of 3.6 should be "frame format" or "protocol
format" if it's truly "frame stuff".
Regards,
Kurt
----Original Message Follows----
From: Jeongyeup Paek <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: KURT PETERS <[EMAIL PROTECTED]>
CC: tinyos-help <[email protected]>
Subject: Re: [Tinyos-help] Making heads or tails of TEPs113, 111, and
actual code
Date: Sat, 10 Nov 2007 17:43:51 -0800
You don't need to do/worry about any framing stuff
if you are willing to use what tinyos provides.
In T2, if you are using AMSender/Receiver on the motes to
communicate with the PC, then use the libraries in
tinyos-2.x/support/sdk/c to send/receive packets.
'seriallisten' is a good example to start.
If there is a function called 'read_XX_packet', then
there always is a counter part: 'write_XX_packet'.
(where XX can be sf or serial)
Sometimes, it is easier to access the mote via SF
than directly through serial, but this is up to you.
In T1, when you use GenericComm/UartComm on the motes to
communicate with the PC, then use the libraries in
tinyos-1.x/tools/src/sf to send/receive packets.
'seriallisten' is a good example to start.
If there is a function called 'read_XX_packet', then
there always is a counter part: 'write_XX_packet'.
(where XX can be sf or serial)
Sometimes, it is easier to access the mote via SF
than directly through serial, but this is up to you.
And I heard that there are many more richer set of
stuff(libraries and codes) provided in Java that you can use.
But I don't know them well enough to point you to any...
since I had to work on stargates with C too, just like you.
Thanks
- jpaek
KURT PETERS wrote:
Thanks, If I'm transmitting TO a mote via the serial port, I need to
include all the framing info, though, right? I noticed that the
stargate's motetest.c did not, and I don't think that's right, but
wanted to confirm.
Also, when CRC is calculated, should it include any 0x7d's the char
that has been escaped AND the first two bytes "P and D"?
Do you have a routine (in C or java) that calculates CRC or is that
ignored on the mote?
Regards,
Kurt
----Original Message Follows----
From: Jeongyeup Paek <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: KURT PETERS <[EMAIL PROTECTED]>
CC: [email protected]
Subject: Re: [Tinyos-help] Making heads or tails of TEPs113, 111,
and actual code
Date: Sat, 10 Nov 2007 15:59:34 -0800
while the actual source code shows it as:
typedef nx_struct serial_header {
nx_am_addr_t dest;
nx_am_addr_t src;
nx_uint8_t length;
nx_am_group_t group;
nx_am_id_t type;
} serial_header_t;
in serial.h, which is 7 bytes.
7 bytes is correct. I heard that there has been a recent modification
to the serial packet format: added 'src' field. TEP should be updated.
TEP111 implies that the serial header is 5 bytes (in section "3.1
Headers"), when, in reality, according to my experiments, it's at
least 7 bytes, and, most likely, 9 bytes. Let me elaborate...
No, you should not call it 9...
that is a different story as you've mentioned below...
they are 'frame-related' stuff...
TEP111. I understand why it might not be mentioned there, since it's
frame-related and not really related to message_t.
Notice my data starts at byte 9 (like it should based on the
reasoning above). Bytes 109 and 110 seem to be the CRC. The framing
0x7e (and any escaped chars) have been removed automatically by my code.
If 'your code' removed the framing and escape chars, then
'your code' should *also* remove bytes 0,1,109,110.
That is what 'frame-related' stuff do: remove framing (start/end),
remove framing protocol header (0,1), escape chars, CRC...
and return only 'serial_header'.
Does all this sound reasonable?
Yes...
-jpaek
Regards,
Kurt
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
--
Jeongyeup Paek
Ph.D. student
Embedded Networks Laboratory
Department of Computer Science
University of Southern California
http://enl.usc.edu/~jpaek
--
Jeongyeup Paek
Ph.D. student
Embedded Networks Laboratory
Department of Computer Science
University of Southern California
http://enl.usc.edu/~jpaek
--
Jeongyeup Paek
Ph.D. student
Embedded Networks Laboratory
Department of Computer Science
University of Southern California
http://enl.usc.edu/~jpaek
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
