serial port full duplex

[rocachondo]

Hi!

I'm programming an application for communicating with mica2 motes (for a wireless sensor network). To do this i have make some VIs that send and receive many bytes according to the TinyOS serial protocol. This program runs without problem when i try to write or read any message.

The problem appears when i try to write and read on the same application. I would need to use the RS232 serial port on a full duplex way, but i don't know how to do it. When i put a VI that reads the serial port waiting for a message from a mote, the application stops until a message arrive, but i don't know how to crete an interruption for control it. Now if the program is reading the serial port, i can't write any byte.


How could i do it? I have thought about using a semaphore but i don't know how to use it.

Any idea?

Thank you very much!

[echarry]

Hi Rocachondo,

I am also (trying) to work with the Mica2Dot motes. There's a link : http://sine.ni.com/apps/utf8/niid_web_display.download_page?p_id_guid=1FB66B354ED149C7E0440003BA230E... that provides interface to the Mica2 motes and some specific boards.  Maybe it can give you some guidance.

I am though, trying not to listen to any packets coming through my TOSBase, but just trying to access the ADC's straight. Practically, I am not interested in the wireless link (or the EEPROM program) but just in the CPU control (and its registers naturally). Implementing a low-level comm with this USB port will demand some time, which I at the moment don't have.

Any ideas?

Thank you!!!

Edgar Charry

[rocachondo]

Hi!

I'm not sure if i have understood you.

I think the easiest why to access the CPU is beyond a program on the mote. You could develop a TinyOS program that listen then serial port (instructions from PC) and depending on the messages sent to the mote, generates an answer. For example, you can make a program on the mote that, when it receives a message on AM = 1, then reads the A/D conversor and sends the answer to the PC. I think this is very simple, don't?

[echarry]

Exactly....

It would be Ok keep listening to the serial port with TOS_Msg packets coming (PC commands) and with Labview handle the events. But I'll still need to program this onto the mote's memory using TinyOS. Instead of that, I'd like just to have access to the registers, CPU, ALU, multiplying and ADC without having to "listen" to the packets.  It wanna do something like: call ADC2.getData();  and get the event: async event result_t ADC2.dataReady(uint16_t data).

Got it?

Thanks anyway for your reply..!

[rocachondo]

I know what you mean, but i think that is very difficult. I don't know how i can help you, sorry. If you have another question i can resolve, ask to me.

[echarry]

Hi,

By the way, using the Mica2Dot as TOSBase was a problem for you?

The command setbaud is not implemented in the module HPLUART0M for the Mica2Dot platform. just for the Mica2 (at least using the MoteWorks configuration files).

Using the Mica2 HPLUART0M module in the /platform/Mica2dot/ directory doesn't solve the problem.  XSniffer can't read any packets coming.

I am in fact, trying your suggestion to program the mote using the UARTReceive interface and an event related to that (that will be the ADC reading). The event, Labview should read.

Cheers!

Edgar Charry

[rocachondo]

I have never used mica2dot motes, so i don't know if there is a problem with TOSBase.

Sorry....

[echarry]

Hi!

As you work with the Xbow motes, i think we should take up contact. 🙂

Anyway: maybe you can help me out with the following, as maybe you had also this sort of problem:

I am experimenting problems with the packet structure. The TOS_Msg struc is intact, but i've changed the xsensor header a bit. However i cannot recognized some bytes that my programm is listening (and shouldn't be received). They are marked with a "???" below.  As strenght and ack bytes are not sent,  don't really know what they are (or where the CRC is).

My packet struc should be 5 bytes of TinyOS Header :

a. Dest Add - 2, AM Group - 1, AM Type - 1, Length - 1

another 6 bytes of xsensor header (which i changed to count the packets supposed to be transmitted and the transmitted in fact):

b. packet_id - 2, tx_id - 2, node_id = 1, rsvd -1

and the payload that should contain 8 bytes:

c. thermistor - 2, adc2 - 2, adc3 - 2, adc4 - 2.

and:

d. 2 bytes of crc.

Leading to a total of: 21 bytes.

However listening to the UART Port using Labview i read 27 bytes everytime.

Below:

FFFF 007D 5D0E A200 A200 0700 DB01 A701 5B02 1702 CD00 C5B3 7E7E 42, that are described below:

FFFF: Dest Add |

00: AMGroup |

7D:  AMType|

5D = ????

0E: length (which is 14bytes and is correct)|

A200: packet id|

A200: tx id|

07: node id|

00: reserved|

DB01:Thermistor|

A701:ADC2|

5B02:ADC3|

1702:ADC4|

CD00:???

C5B3:???

7E7E:???

42:???

Do you know where do these bytes come from (which file should I look at - AM.h  has already the TOS_Msg description, but these bytes are not implemented)????

Thanks many times for any kind of guidance!

Edgar Charry

[rocachondo]

Hi!

You have a little concept error with the packet. You cannot transmit the bytes in the way you want because you need to use a START/STOP byte: 7E

When you want to transmit a packet, the first thing you have to do is send 7E. After this you must to send the packet type (ACK or NO ACK); the typical value of this field is 42. After this value you begin to transmit the TinyOS packet and at the end you must to transmit 7E again. So, the serial data you need to transmit (and that you will receive) will be the following:

7E 42 <address (2)> <AM(1)> <group(1)> <size(1)> <payload(size)> <CRC(2)> 7E

And what happens if you want to send 7E inside the message (for example with the UART ADDRESS (007E)? You need to use a scape character: 7D. If you find a 7E you must to do a XOR with 20 and put character 7D below; so, if you want to transmit 7E you will send 7D 5E; and if you want to transmit 7D you will transmit 7D 5D.

You can view this information on

www.octavetech.com/pubs/TB5-01%20Deciphering%20TinyOS%20Serial%20Packets.pdf

[echarry]

Hi Rocachondo,

Thanks for your fast reply.

I've been running in a lot of things, so i coudn't answer you back.

To the problem: basically then, if the packet receives a 0x7D, the code checks if its subsequent byte is 0x5E or 0x5D to discover if its a 7E or 7D being transmitted.

Somehow and sometimes only, reading through the VISA, my packets are not being received correctly. The read packet bounces and i get the wrong data.My buffer is set to the default (4096), so i think it's not a problem of buffer. I suspect XSniffer filters this half-packets off, just to display the right data.

Have you experienced such a thing? Did you implement any flow control?

Cheers and thanks,

Edgar Charry