headers
Borms, Joris | 1 Sep 2010 10:14
Picon
Favicon

32-bit rtimer

Hello All,

Some time ago there was some talk on this mailing list about a 32-bit implementation of rtimers, providing
an alternative rtimer_long type. Is the code for this available somewhere?

Regards,
Joris

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
Permalink | Reply | 0 comments |
headers
Marek Bykowski | 1 Sep 2010 15:50
Picon

Makefile DEFINES

Hello,

I have a question.
Say I define a macro in a project Makefile

DEFINES = RF_CHANNEL=5

And it's for fine for a fresh build. But when I'm rebuidling it again with a different value such as

DEFINES = RF_CHANNEL=6

It doesn't take any effect. The RF_CHANNEL is still 5. So basically I have to clean it (make clean) to get this change effective.

Would it be any failure on the dependency check?

Thanks,
Marek, WISAR

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Contiki-developers mailing list
Contiki-developers@...
https://lists.sourceforge.net/lists/listinfo/contiki-developers
Permalink | Reply | 1 comment |
headers
Colin O'Flynn | 1 Sep 2010 17:02
Favicon

Re: Makefile DEFINES

Hello,

 

Unless you’ve gone out of the way to make it happen, Makefiles don’t normally rebuild when the makefile itself changes. Presumably it’s because if you did that, you’d need to rebuild everything any time the makefile changed. This could be very annoying when trying to add/fix a small part of the makefile.

 

It’s a better idea to have such a define in a .h file or similar, so the compiler can rebuild just the required part (probably a single file).

 

  -Colin

 

From: Marek Bykowski [mailto:marek.bykowski-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: September 1, 2010 2:51 PM
To: Contiki developer mailing list
Subject: [Contiki-developers] Makefile DEFINES

 

Hello,

I have a question.
Say I define a macro in a project Makefile

DEFINES = RF_CHANNEL=5

And it's for fine for a fresh build. But when I'm rebuidling it again with a different value such as

DEFINES = RF_CHANNEL=6

It doesn't take any effect. The RF_CHANNEL is still 5. So basically I have to clean it (make clean) to get this change effective.

Would it be any failure on the dependency check?

Thanks,
Marek, WISAR

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Contiki-developers mailing list
Contiki-developers@...
https://lists.sourceforge.net/lists/listinfo/contiki-developers
Permalink | Reply | 0 comments |
headers
Dingxin Xu | 1 Sep 2010 17:06
Picon

CFS, cooja

Hello everyone!

i want to cfs_read() big size of file in cooja, but i don't know how to simulate the file system(the file content but not the cfs_write() and cfs_read() opration). Now before i use cfs_read(), i have to manually perform cfs_write() with a string buffer. 
Is there a way to "upload" the whole file content to the node's file system outside of my code in cooja( so i can just cfs_read() it in my code)? I have tried "Mote interface viewer-> Coffee File System", but it failed with the  error message"Error when parsing coffee file system".
Could anybody give some help?
Thanks in advance!
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Contiki-developers mailing list
Contiki-developers@...
https://lists.sourceforge.net/lists/listinfo/contiki-developers
Permalink | Reply | 6 comments |
headers
David Kopf | 1 Sep 2010 18:15
Gravatar

Re: Jackdaw CDC-ECM Support

Hi Robert,
I am stabbing now. Apparently you have been compiling with RF230BB=0 (else 
the energy scan is not included, very nice btw, I might get it going on a 
web page) which won't work anymore in contiki-2.x. Be aware the atmel 
sicslowpan.c uses the old HC02 header compression method regardless of the 
contiki-conf.h settings.
Your last build behaves the same as before on my Win7/64 and Vista/32, no 
CDC enumeration and RNDIS device "can not start", but the vmware snow 
leopard seems to work with it. Hopefully if I put compile switches on the 
enumeration priorities I can track that down.

----- Original Message ----- 
From: "Robert Quattlebaum" <darco@...>
To: "Contiki developer mailing list" 
<contiki-developers@...>
Cc: <ticso@...>; "Contiki developer mailing list" 
<contiki-developers@...>
Sent: Tuesday, August 31, 2010 1:06 PM
Subject: Re: [Contiki-developers] Jackdaw CDC-ECM Support

I've merged my cdcecm changes into contiki-2.x, and got it to compile. It's 
not quite working though, and I haven't had time to diagnose what is wrong.

If anyone wants to take a stab, you can find it here: 
<http://svn.deepdarc.com/code/contiki/branches/contiki-2.x-cdcecm/>

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
Permalink | Reply | 0 comments |
headers
6983135310 | 1 Sep 2010 20:27
Picon

GPIO on atzb 24-a2 module

Hello,
I use the atmel “atzb24 a2” module and I am a bit confused about the use of ports GPIO. At the beginning I want just to light a led that I have connected on GPIO0.
My problem is that I cannot understand which is the register GPIO0, in order to use it when I write the program. Of course I want to know how to use all the GPIOs but

letʼs start from GPIO0. I have tried to study the datasheet of my module “atzb24 a2” and the datasheet of the microcontroller that is being used (1281v) but

I do not understand how the matching is done.

All the above are being implemented in the contiki environment. I have created a file led.c and the appropriate makefile.
My program is very simple and you can see it below:


//program Led
#include "contiki.h"
#include <stdio.h>
int main()
{
 GPIO0 = 0;             //make GPIO0 output
  while(1){            
      GPIO0 = 1;        //led on*************this is the problem
      delay_ms(1000);           //delay 1 sec
      GPIO0 = 0;        //led off *************this is the problem
      delay_ms(1000);   //delay 1 sec
   }  
}

kind regards
Dragoumanos Apostolos

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Contiki-developers mailing list
Contiki-developers@...
https://lists.sourceforge.net/lists/listinfo/contiki-developers
Permalink | Reply | 2 comments |
headers
Colin O'Flynn | 1 Sep 2010 23:56
Favicon

Re: Latest CDC-ECM Jackdaw

xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

Hi Robert,

 

> I've also updated a lot of the USB busy-wait-loops to time out after a brief period so that it won't

> lock up

 

This was partially kept like that for “debugging reasons”. Basically if those loops fail to clear, it would often mean the USB bus had something go wrong. The current code didn’t do a lot of error handling so in reality it should have probably detected something else happened that is resulting in the transaction not finishing. If the loops stay forever you could attach a JTAG-2 and see what the state of the USB registers was and maybe get an idea what went wrong!

 

If you just jump out of the loops there’s no guarantee the USB will be in a working state. Unfortunately the original Atmel code didn’t have any error handling so it would be need to be added all over…

 

Regards,

 

  -Colin

 

From: Robert Quattlebaum [mailto:darco-JejpW2WYlyRWk0Htik3J/w@public.gmane.org]
Sent: September 1, 2010 10:53 PM
To: ticso-sWnWvldIKvCzQB+pC5nmwQ@public.gmane.org
Cc: Wouter Horré; Colin O'Flynn; David Kopf; Bernd Walter; Contiki developer mailing list
Subject: Re: Latest CDC-ECM Jackdaw

 

 

On Sep 1, 2010, at 2:35 AM, Bernd Walter wrote:



I noticed only one USB side problem so far.
My device disconnected once unexpectedly.
FreeBSD didn't like it, but that's a FreeBSD problem.
Since this is not a clean environment it is difficult to say if the
disconnect was the fault of the device or anything else.
There is also a major chain of USB hubs and other devices on my test
system.
I didn't send much traffic either because communication with the device
doesn't work completely for likely different reasons.

 

I implemented the watchdog timer for the AVR CPU (Which was so easy to add that I was rather surprised it wasn't implemented already) and started using it in my CDC-ECM branches. If the stick locks up for more than 500ms, it will automatically reset. This is likely what you experienced.

 

As a result of adding the watchdog code, I've also updated a lot of the USB busy-wait-loops to time out after a brief period so that it won't lock up (and subsequently reset) if the USB port gets into a weird state. There may be a few more busy-wait-loops that I missed, however. 

 

I have seen the watchdog kick in a few times, but I haven't figured out where it is getting tripped up yet. It seems to happen when there is lots of traffic.

 

 

 

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Contiki-developers mailing list
Contiki-developers@...
https://lists.sourceforge.net/lists/listinfo/contiki-developers
Permalink | Reply | 3 comments |
headers
Robert Quattlebaum | 2 Sep 2010 00:09
Gravatar

Re: Latest CDC-ECM Jackdaw

On Sep 1, 2010, at 2:56 PM, Colin O'Flynn wrote:

> Hi Robert,
>  
>> I've also updated a lot of the USB busy-wait-loops to time out after a brief period so that it won't lock up
>> 
>  
> This was partially kept like that for “debugging reasons”. Basically if those loops fail to clear, it
would often mean the USB bus had something go wrong. The current code didn’t do a lot of error handling so
in reality it should have probably detected something else happened that is resulting in the transaction
not finishing. If the loops stay forever you could attach a JTAG-2 and see what the state of the USB
registers was and maybe get an idea what went wrong!

Speaking of USB issues... I was seeing some weird behavior on the virtual COM port, which may be indicative
of similar bad behavior on the CDC-ECM-DATA interfaces. It is most visible when I turn on IPv4 traffic on
the port so that I can see the "Packet is not IPv6, dropping" error messages:

> eth2low: Packet is not IPv6, dro33�eth2low: Packet is not IPv6, dropping
> eth2low: Packet is�x����O����eth2low: Packet is not IPv6, dropping
> eth2low: Packet is not IP��x��eth2low: Packet is not IPv6, dropping
> eth2low: Packet is not IP�eth2low: Packet is not IPv6, dropping
> eth2low: Packet is not IPv6, dropping
> eth2low: Packet is not IPv6, dropping
> eth2low: Packet is not IPv6, dro33�eth2low: Packet is not IPv6, dropping
> eth2low: Packet is not IPv6, dropping
> eth2low: Packet is not IPv6, dro33�eth2low: Packet is not IPv6, dropping
> eth2low: Packet is not IPv6, dro33�eth2low: Packet is not IPv6, dropping

Any idea what might be causing this weird corruption? I've looked over the code a few times, and nothing
stands out to me that might be the cause of this. I'm worried that similar corruption may be happening to
ethernet packets as well, although I don't believe I have seen this in practice.

__________________
Robert Quattlebaum
Jabber: darco <at> deepdarc.com
eMail:  darco <at> deepdarc.com
www:    http://www.deepdarc.com/

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Contiki-developers mailing list
Contiki-developers <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/contiki-developers
Permalink | Reply | 2 comments |
headers
Robert Quattlebaum | 1 Sep 2010 23:52
Gravatar

Re: Latest CDC-ECM Jackdaw


On Sep 1, 2010, at 2:35 AM, Bernd Walter wrote:

I noticed only one USB side problem so far.
My device disconnected once unexpectedly.
FreeBSD didn't like it, but that's a FreeBSD problem.
Since this is not a clean environment it is difficult to say if the
disconnect was the fault of the device or anything else.
There is also a major chain of USB hubs and other devices on my test
system.
I didn't send much traffic either because communication with the device
doesn't work completely for likely different reasons.

I implemented the watchdog timer for the AVR CPU (Which was so easy to add that I was rather surprised it wasn't implemented already) and started using it in my CDC-ECM branches. If the stick locks up for more than 500ms, it will automatically reset. This is likely what you experienced.

As a result of adding the watchdog code, I've also updated a lot of the USB busy-wait-loops to time out after a brief period so that it won't lock up (and subsequently reset) if the USB port gets into a weird state. There may be a few more busy-wait-loops that I missed, however. 

I have seen the watchdog kick in a few times, but I haven't figured out where it is getting tripped up yet. It seems to happen when there is lots of traffic.


------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Contiki-developers mailing list
Contiki-developers@...
https://lists.sourceforge.net/lists/listinfo/contiki-developers
Permalink | Reply | 7 comments |
headers
Colin O'Flynn | 2 Sep 2010 00:11
Favicon

Re: Latest CDC-ECM Jackdaw

It may be the buffer somewhere higher up in the stack. As in when writing debug data out, it just overwrites
its own buffer.

By comparison the USB-Ethernet side is very much more "lock-step". So instead of seeing packet corruption
you are more likely to see the stick just drops 802.15.4 frames as it had no space to write them when they were received.

  -Colin

-----Original Message-----
From: Robert Quattlebaum [mailto:darco <at> deepdarc.com] 
Sent: September 1, 2010 11:10 PM
To: Colin O'Flynn
Cc: ticso <at> cicely.de; 'Wouter Horré'; 'David Kopf'; 'Bernd Walter'; 'Contiki developer mailing list'
Subject: Re: Latest CDC-ECM Jackdaw

On Sep 1, 2010, at 2:56 PM, Colin O'Flynn wrote:

> Hi Robert,
>  
>> I've also updated a lot of the USB busy-wait-loops to time out after a brief period so that it won't lock up
>> 
>  
> This was partially kept like that for “debugging reasons”. Basically if those loops fail to clear, it
would often mean the USB bus had something go wrong. The current code didn’t do a lot of error handling so
in reality it should have probably detected something else happened that is resulting in the transaction
not finishing. If the loops stay forever you could attach a JTAG-2 and see what the state of the USB
registers was and maybe get an idea what went wrong!

Speaking of USB issues... I was seeing some weird behavior on the virtual COM port, which may be indicative
of similar bad behavior on the CDC-ECM-DATA interfaces. It is most visible when I turn on IPv4 traffic on
the port so that I can see the "Packet is not IPv6, dropping" error messages:

> eth2low: Packet is not IPv6, dro33�eth2low: Packet is not IPv6, dropping
> eth2low: Packet is�x����O����eth2low: Packet is not IPv6, dropping
> eth2low: Packet is not IP��x��eth2low: Packet is not IPv6, dropping
> eth2low: Packet is not IP�eth2low: Packet is not IPv6, dropping
> eth2low: Packet is not IPv6, dropping
> eth2low: Packet is not IPv6, dropping
> eth2low: Packet is not IPv6, dro33�eth2low: Packet is not IPv6, dropping
> eth2low: Packet is not IPv6, dropping
> eth2low: Packet is not IPv6, dro33�eth2low: Packet is not IPv6, dropping
> eth2low: Packet is not IPv6, dro33�eth2low: Packet is not IPv6, dropping

Any idea what might be causing this weird corruption? I've looked over the code a few times, and nothing
stands out to me that might be the cause of this. I'm worried that similar corruption may be happening to
ethernet packets as well, although I don't believe I have seen this in practice.

__________________
Robert Quattlebaum
Jabber: darco <at> deepdarc.com
eMail:  darco <at> deepdarc.com
www:    http://www.deepdarc.com/

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Contiki-developers mailing list
Contiki-developers <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/contiki-developers
Permalink | Reply | 1 comment |

Gmane