From: Henrik M. <hen...@gm...> - 2010-01-05 08:45:17
|
I haven't looked at the latest code in sourceforge, will do that straight away. Thanks! /Henrik 2010/1/4 David Kopf <da...@em...> > Hi Henrik, > > Contiki 2.3 uses a combined mac layer and radio driver, apparently it was a > quick way to add the existing Atmel code to contiki. When the contiki core > calls the radio driver to send a packet it is actually calling the mac > driver which reconstructs the packet. Presumably this fixes the CRC, I > didn't look into it that closely when adding the RF230BB code, which is > supposed to be an actual radio driver that uses the core sicslowmac.c. This > was after the 2.3 release. > > Have you looked at the latest code on sourceforge > > http://contiki.cvs.sourceforge.net/viewvc/contiki/contiki-2.x/cpu/avr/radio/ > > rf230bb.c has an extra length: > #define AUX_LEN (CHECKSUM_LEN + TIMESTAMP_LEN + FOOTER_LEN) > which hasn't been tested in all its configurations. Also, there is still > some problem with fragmented packets when using this driver. > > ----- Original Message ----- > From: "Henrik Mäkitaavola" <hen...@gm...> > To: <con...@li...> > Sent: Monday, January 04, 2010 11:47 AM > Subject: [Contiki-developers] RF230 Crc (Packet length) > > > Hi, > > I'm working on porting Contriki to a platform that we are developed here at > Luleå University of Technology (Mulle <http://www.eistec.se/>). > > Mulle has a RF230 chip and I'm currently porting the > "contiki-2.3/cpu/avr/radio" code to it. In the implementation the chip crc > auto generation is turned on through the PROCESS_THREAD mac_process in > sicslowmac.c. This implies that the packet length sent over the radio must > be "[my data length] + 2", the two extra bytes hold the crc. But when a > packet is sent in sicslowmac_dataRequest() this is not considered, thus > always making the crc check fail on the receiver side because the last 2 > bytes are dropped from the payload. When I increase the length by two of > the > packet in the radio_send_data call from sicslowmac_dataRequest() everything > works fine. > > I wounder if there is something that I have missed when porting the rf230 > code or if this is a bug? I have a hard time believing that this is a bug > because I thing that someone should have spotted this earlier then so it is > probably a mistake from my side somewhere. I haven't done any major changes > in the code, just replaced the mcu specific code to make it work on the mcu > we are using (Renesas M16c). > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Contiki-developers mailing list > Con...@li... > https://lists.sourceforge.net/lists/listinfo/contiki-developers > |