Subject: Re: SPI and MSP430 - msg#00017

Previous Message by Date:

Re: Porting contiki to ZX Spectrum

On Tue, 2007-08-07 at 11:42 +0200, Groepaz wrote: > infact, the new buildsystem is what stopped me from proceeding with the c64 > port of 2.x ... it heavily relies on gnumake, and also certain properties of > the gcc preprocessor. with just cc65 its not possible to build it cleanly > (you'd have to use the preprocessor from gcc atleast, which i didnt want to). > and i strongly doubt you'd have much fun with sdcc either (which i guess you > would be using for a speccy port?). The build system isn't a problem for me since I wrote my own make-files. My goal isn't to make a proper port, but to see if I just can get something to work. I had a few issues with SDCC, but all where easy to fix and at least one makes GCC also complain if using -pedantic ( extra semicolons). I will probably propose a few patches to fix those soon. > > so uhm yes, go for 1.x ... check the gameboy port on cvs, it should atleast > contain some necessary tweaks for sdcc :) in theory all you need to do is > write a conio style lib (which is just a handful functions) and link the > stuff together =P > What would be needed for 2.x besides the networking that's mostly working already and conio to get the webbrowser working? Has the networking API changed a lot between 1.x and 2.x ? simon ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/

Next Message by Date:

Re: SPI and MSP430

Scheers Bart wrote: > So maybe I can rephrase my question. How can you speed up the MSP430 to 8MHz > without influencing the code (Contiki, aodv,..). others will know contiki, and perhaps the MSP430 better then I. I don't think Adam (the guy behind contiki) would in effect allow a design flaw to be present like that. BUT - Before you go far - Did you do as I suggested before? Measure - with a scope - create an actual time line of events. Is it really the SPI clock rate? I have been in situations with various protocols where people blindly say in a design review and say "all you need to do is speed the baud rate up" and try to look like a hero. If you have not sat in _that_ meeting, I have learned from years of experience to watch for that sort of comment. that said, one would need to look at the following things: (1) Any piece of code that operates in bit-bang mode. Some MCUs - bit bang I2C, or SPI - some do not. One must look carefully at that code to see how it is accomplished. DO NOT ASSUME that if the Hardware has SPI the hardware is used... I speak from personal experience walking into other (non-contiki designs) There are of course 2 types of timing loops. Instruction loops, counting loops, they may be implemented "in line" with hard coded values often you find "count to 158" is 1mSec... Often an unskilled and unseasoned programmer writes code that works in DEBUG mode, but fails to operate in RELEASE (optimize) mode. Sometimes - in resource constrained places, it is the only way Hopefully if you have that type of timing loop there is a core macro or #define you must redefine. Again - look for bit-bang protocol loops. (2) Of course there is perhaps a periodic timer or a watch dog timer that is programed. Either they are programed with a precomputed hard-coded number, or - there is some function like "hertz_2_clk_reg_val()" Look for things like the UART setup and config. Are they programing a hard coded number? Or a macro? Or something else. Contiki uses a hardware timer, in your config how exactly is that programed? (3) Smoke test. Change it and see what happens. Perhaps you'll be happy and surprised. -Duane. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/

Previous Message by Thread:

2.x build system (was Porting contiki to ZX Spectrum)

> BTW: One additional reason not mentioned before is that the 2.x build > system much more complicated / harder to understand than the 1.x one. I was thinking a lot as to how it can be improved. I'm starting to think the ideal would be to typically compile the main task / kernel in to a single .o file. None of the usual reasons why processes are broken down into multiple .o's are valid : * The compiler can handle it because it runs on a much larger host system. * The time saved by not having to recompile the complete system after a small change is insignificant. * Similarly replacing a driver by linking with a different is no longer possible. But it can still be done by recompiling with a different -D option, which is only slightly slower. The benefits are : * Smaller code and less stack space on compilers supporting "inline" keyword. * Smaller code and less stack space whenever #define macros make sense. * A single place to specify depencancies i.e. in the main application file, hence a simpler build system. To demonstrate how the concept, let's suppose you want to do PPP on the second UART : #include <seconduartdriver.h> #define PPP_DEVICE SECOND_UART_DRIVER #include <ppp-service.h> main () { start_ppp_service (); } Inside *uartdriver.h there'll be #ifdefs to cater for all the different platforms and platforms with only one UART will generate an error. If you want PPP on multiple UARTS, a lot / all of the PPP code will be duplicated, depending on how much effort has gone into ppp-service. But there'll always be tradeoffs and a point where you'll have to go for a larger CPU. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/

Next Message by Thread:

Re: SPI and MSP430

Scheers Bart wrote: > So maybe I can rephrase my question. How can you speed up the MSP430 to 8MHz > without influencing the code (Contiki, aodv,..). others will know contiki, and perhaps the MSP430 better then I. I don't think Adam (the guy behind contiki) would in effect allow a design flaw to be present like that. BUT - Before you go far - Did you do as I suggested before? Measure - with a scope - create an actual time line of events. Is it really the SPI clock rate? I have been in situations with various protocols where people blindly say in a design review and say "all you need to do is speed the baud rate up" and try to look like a hero. If you have not sat in _that_ meeting, I have learned from years of experience to watch for that sort of comment. that said, one would need to look at the following things: (1) Any piece of code that operates in bit-bang mode. Some MCUs - bit bang I2C, or SPI - some do not. One must look carefully at that code to see how it is accomplished. DO NOT ASSUME that if the Hardware has SPI the hardware is used... I speak from personal experience walking into other (non-contiki designs) There are of course 2 types of timing loops. Instruction loops, counting loops, they may be implemented "in line" with hard coded values often you find "count to 158" is 1mSec... Often an unskilled and unseasoned programmer writes code that works in DEBUG mode, but fails to operate in RELEASE (optimize) mode. Sometimes - in resource constrained places, it is the only way Hopefully if you have that type of timing loop there is a core macro or #define you must redefine. Again - look for bit-bang protocol loops. (2) Of course there is perhaps a periodic timer or a watch dog timer that is programed. Either they are programed with a precomputed hard-coded number, or - there is some function like "hertz_2_clk_reg_val()" Look for things like the UART setup and config. Are they programing a hard coded number? Or a macro? Or something else. Contiki uses a hardware timer, in your config how exactly is that programed? (3) Smoke test. Change it and see what happens. Perhaps you'll be happy and surprised. -Duane. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/