B@tto

rfBSL Update: Okay, so I've written a Python app (based partial on ChronosTool.py and the iHEX to TI-TXT script [memory.py) from OpenChronos) that takes a .hex file as an input and uploads it over rfBSL. I then used pyInstaller to "compile" the script into a fully self-contained executable for Windows, Linux and OS X. This way the user doesn't need Python (or any additional libraries) installed and we don't have to include the bulky jython (Java Python) interpreter.
 
Each executable weighs in at about 5MB and could be included in the Windows, Linux and Mac specific tools folder of Energia.
 
Once I do some more testing I'll post a copy of the files, but I welcome any feedback on this method.

Never that everything you do, even if it's written in decimal, hexadecimal ... Is always managed as binary. You would write :
Serial.write(sensorValue&255); or 
Serial.write(sensorValue&0b11111111); instead of 
Serial.write(sensorValue&0xFF); It would exactly the same
 
If your connection is not saturated, I recommand to you to send 255 two times before a new transmission, to ensure that on computer side a new transmission is arriving. Because if for a reason or another, the LSB transmission is lost (it could happen, it's rare but ...) your program will be desynchronised : MSB interpreted as LSB and vice versa.

The wireless dongle included in the eZ430-Chronos kit will work just fine for rfBSL updating. (Both the Black PCB CC1111 and White PCB MSP430F5509 + CC1101 dongles will work.)
 
For non-Chronos CC430 options, you could use the above dongles, or as @@B@tto mentioned, a CC110L hooked to an Arduino or MSP430 and connected to your computer over USB.
 
@@B@tto Yeah, HEX to TI-TXT conversion is easy, there's a ton of tools out there that will do it for you, most of them lightweight. I think the best course of action would be for me to write a simple little CLI app that directly takes a HEX file and then internally converts it to TI-TXT and uploads it via rfBSL. I can then cross-compile the program for Mac, Windows and Linux.

As I said, G2553 can support even much higher than 115200, so the G2553 is not a problem at all in your case. The problem comes from the conversion from uart out of the g2553 to your computer. So if you want to use BT, the limitation will come from your BT module.
 
Some tricks to improve speed : firstly, do not use texte like you did. You wasted a lot of bandwitch Serial.print("sensor = " ). Secondly use binary transmission. If you want to send your analogRead() value you can use a routine like this :
Measure = analogRead(Sensor); Serial.write(Measure>>8); Serial.write(Mesure&0xFF); And on the computer side, just read the serial buffer as binary, not ASCII, do the invert bitwise and you may get your analog reading
And it takes only two bytes of data so :
 
9600/10 = 960 <=> 960 / 2 = 490 hz , even in 9600 bauds

It does not mean that's it's the best for your usage
 
 
 
+1
 
It was my idea when I asked for the code.
 
~30 bytes are sended each loop + 9600 baud <=> 9600/10 = 960 bytes/s <=> 960/30 => ~30 S/s max
 
So your low speed is normal. If you want to have a better acquisition speed, you may store it in an array during an acquisition period, and then send it by serial after.
 
Another way is to only send significant value : if you are studying a PWM signal, only transition are significant, so no need to send value if the precedent was the same

Hi,
 
Can you post your code ? G2553 datasheet allowed 200 kS/s, even if Energia "eat" some cycles, I don't think your low sample frequency comes from Energia, but from your code.

The problem just comes from the UART debugger interface. If you use another usb<->serial converter, you will be able to rise much higher than 115200 baud

Hi everyone,
 
I built a library to drive RTC_A feature of some MSP430/CC430.
 
It's available here : https://github.com/battosai30/RTC_A
 
Feel free to test and comment
 
Remark : I haven't tested part about counter mode and I will upload an example soon, but it's very simple to use. Tested calendar mode on my eZ430 chronos and everything seems to go well.

Hi everyone,
 
I built a library to drive RTC_A feature of some MSP430/CC430.
 
It's available here : https://github.com/battosai30/RTC_A
 
Feel free to test and comment
 
Remark : I haven't tested part about counter mode and I will upload an example soon, but it's very simple to use. Tested calendar mode on my eZ430 chronos and everything seems to go well.

Another good news : after a week of fight, I've build a beta library which allowed radio communication between my ez430 Chronos and a CC1101 connected to a Launchpad
 
The library is cross platform compatible : Energia & Arduino. As I used high level Arduino core functionnalities, it will work on all platforms. I just meet troubles on Energia because of that http://forum.43oh.com/topic/5362-conflict-between-digitalread-and-spi/  If no modification is done directly in Energia core, I'll have to make a configuration for each

Some good news :
 

 
With this simple code :
 
#include <display.h> char str[]="    ENERGIA    "; void setup() {   lcd_init();   display_symbol(LCD_ICON_HEART ,SEG_ON);   display_chars(LCD_SEG_L2_5_0," ROCKS",SEG_ON_BLINK_ON);  } void loop() {      for(int i =0;i<12;i++) {      display_char(LCD_SEG_L1_3,str[i],SEG_ON);      display_char(LCD_SEG_L1_2,str[i+1],SEG_ON);      display_char(LCD_SEG_L1_1,str[i+2],SEG_ON);      display_char(LCD_SEG_L1_0,str[i+3],SEG_ON);      delay(400);   } } I have to clean the library : I just made a bulk transfer from TI firmware and it's not very clean as I haven't understand everything yet.
 
It was an important step for me because serial debuging is not possible (I have to solder wires to do that and I don't want to for now).
 
I looked RTC_A peripheral and it seems a piece of cake to get it working (strangely, TI don't use it in his firmware and use classic timer ).
 
Finally everything I could tried like analogRead() digitalRead() and digitalWrite() worked. I have to test PWM, i2c and SPI now

Hi everyone,
 
I'm working on Energia CC430 support. It's the first time I do this kind of work, it allowed me to understand a lot of things but not everything of course So I have a lot of questions !
 
So for now where I am : I'm working on a eZ430 - Chronos 433 mhz (==> CC430F6137). I program it with the ez430 USB stick (I will see later for upload using radio BSL). 
 
For now I just tried to get something working, I made a pin_energia.h creating a new MSP430 variant. I edited the board.h and I had to modify wiring.c to get the clock system working  :
 
Original line 168 :
 
#if defined(__MSP430_HAS_UCS__)
 
Modified to :
 
#if defined(__MSP430_HAS_UCS__) || defined(__MSP430_HAS_UCS_RF__)
 
I used some function from the eZChronos firmware provided by TI to test if the system was running, here is the code : 
https://github.com/battosai30/CC430_EnergiaSupport/blob/master/Test/Heart.cpp
 
Upload using Energia integrated in CCS v6 ==> IT WORKS the heart on the LCD is beating !
 
Now I am trying to understand if my modification of wiring.c is enought, and if other Energia features are OK.
 
All files are here : https://github.com/battosai30/CC430_EnergiaSupport
 
Now my questions :
 
1) What is interesting me the most is the radio core. TI provides some interesting low level libraries I can re-use, but I don't know how to integrate it directly in the core. I plans to work on others features like LCD_B, AES ... I think it would be better to directly integrate it and to do not have to add a library each time.
 
2) I found some defines in msp430's pins_energia.h :
 
#define TWISDA_SET_MODE  (PORT_SELECTION0 | PORT_SELECTION1 /* | INPUT_PULLUP*/) /* do not enable the pull ups for this device */ #define TWISCL_SET_MODE  (PORT_SELECTION0 | PORT_SELECTION1 /* | INPUT_PULLUP*/) #define DEBUG_UARTRXD_SET_MODE (PORT_SELECTION0 | PORT_SELECTION1 | INPUT) #define DEBUG_UARTTXD_SET_MODE (PORT_SELECTION0 | PORT_SELECTION1 | OUTPUT) #define SPISCK_SET_MODE (PORT_SELECTION0 | PORT_SELECTION1) #define SPIMOSI_SET_MODE (PORT_SELECTION0 | PORT_SELECTION1) #define SPIMISO_SET_MODE (PORT_SELECTION0 | PORT_SELECTION1) #define DEBUG_UART_MODULE_OFFSET 0x0 I don't really understand what they mean ...
 
3) How the PMAP is used in Energia ? I found a PMAP maping in fraunchpad pins_energia.h but I did not found where it's used.
 
4) I just need a confirmation : function "const uint8_t digital_pin_to_timer[]" is used to define pins PWM compatible ?
 
5) In wiring.c init() :
 
/* Clear P2.6 and P2.7 bits to default to GPIO */ #ifdef P2SEL2 P2SEL &= ~(BIT6|BIT7); #endif Why this lines ? Thanks !
 

Hi and thanks everyone for your help.
 
So, I did some test this morning and here are my conclusions : grahamf72 you're right, there was on cast and on interrupt, using yours suggestions it works fine as you. But I still surprised : why my interrupt syntax doesn't work here ? I mean I use this code to put my MSP into sleep mode in another sketch and it works :
 
 
#pragma vector=(WDT_VECTOR) __interrupt void watchdog_timer(void) {   _BIC_SR_IRQ(LPM3_bits); } Why here I have to use legacymsp430.h ?
 
About cast problem, I think it's a problem of IDE. If you use that :
 
 
 Serial.println(RTC.RTC_sec,DEC); It works too. The library use char type so when you use print command it print it as a char, note as a byte. I tried to change variable types to byte or uint8_t but the compilation failed.
 

Hi all,
 
First sorry for my english, I'm french ...
 
So, trying to play with SPI and a nRF24L01, I met a lot of issues, nothing worked. After several days I was desperate and looking at pin mapping in the datasheet of the MSP430G2553 I found a difference with the schema displayed on energia's wiki : USCI_B0 CS pin is not on pin 2.0, but on pin 1.4 !
 
Unfortunately I chose this pin in order to command the CS of my nRF, and I don't know why exactly but SPI refused to work. I changed to another pin and ooowwwww miracle it works