Jump to content


  • Content Count

  • Joined

  • Last visited

  1. SloMusti

    MSP430G2955 Launchpad Development

    Any ideas why Energia would say P2_6 undefined for Spirillis launchpad. In both chip package types it is present on pin 3, any reasons why not available in Energia?
  2. SloMusti

    MSP430G2955 Launchpad Development

    I have used stock energia 13 and applied spirillis patch for the G2955 support, uploaded through F5529 launchpad. When sprinting through serial port, the following occurs, stdin error is printed along with the correct message: Testing the communication stdin:1: '=' expected near 'the' > Testing the communication stdin:1: '=' expected near 'the' > Testing the communication Testing the communication stdin:1: '=' expected near 'the' > Testing the communication stdin:1: '=' expected near 'the' > Testing the communication The problem is related with Serial.println(), and does not happen with Serial.print(). When the string is empty, the response is ">", when printing Serial.println("a") single character, the following occurs: a stdin:2: '=' expected near 'a' > a Manually writing return characters does not change anything. Any ideas?
  3. I have come across a possible bug or some function clash with Scheduler on Tiva TM4C launchpad. Using CCSv6 for debugging this leads to scheduler causing a fault condition resorting in an infinite loop static void FaultISR(void). The flow is as follows: One scheduler loop and the main loop. The program goes through setup, jumps to the main loop and comes to a delay in it., that in turn then calls yield(), passing command over to Scheduler, calling coopDoYield(cur), then static CoopTask* __attribute__((noinline)) coopSchedule(char taskDied), confirming that the task has not died, jumping to the next task, back to coopDoYield(cur) and failing to FaultISR(void). From this we I guess that the pointer to the next task is wrong or something similar. Any ideas? I have not yet managed to find a workaround.
  4. I have made this simplified code to easily enable continuous reading of a single DS18B20 sensor. It reads the value and starts a fresh conversion so you can just periodically (greater then 1s period) call the function to get temperature. // TM4C1294XL One-Wire - One sensor continuous // Have used arrays to hold retrieved information, so that it can be easily addressed by your code // This sketch plus StellarisDS18B20.h will run as is on 430 & Stellaris LaunchPads // Do a reset to view the One Wire ROM addresses. Have Fun. // Grant Forest 29 Jan 2013. // Had confusion with library names. Lib now called GFDS18B20 // GF 6 Feb 2913 cleaned up a bit of code. // JM 8 Apr 2014 modified for TM4C1294XL LaunchPad // Musti 14 June 2014 derived for simpel continuos reading of a single sesnsor #include <TM4C_DS18B20.h> #define OWPIN PE_3 // 1-wire signal with 4.7K pullup on pin X8-12 (PE-3), 5V on X8-2, GND on X8-4 byte addr[8] ; DS18B20 ds(OWPIN); // currently on PIN 11 void setup(void) { Serial.begin(115200); ds.InitGPIO(); ds.search(addr); //start conversion ds.reset(); ds.write_byte(0xcc); // was ds.select(work); so request all OW's to do next command ds.write_byte(0x44); // start conversion, with parasite power on at the end } void loop(void) { Serial.print("OW"); Serial.print(" = "); Serial.print(measure_DS18bB20()); Serial.println(" degC"); delay(1000); } float measure_DS18bB20(){ byte data[12]; float result; //read ds.reset(); ds.select(addr); ds.write_byte(0xBE); // Read Scratchpad for ( char i = 0; i < 9; i++) { // need 9 bytes data[i] = ds.read_byte(); } result = (int32_t)((data[1] << 8) | data[0]); result*=0.0625; //start next conversion ds.reset(); ds.write_byte(0xcc); ds.write_byte(0x44); //check if received data is invalid, return 0 if(data[0]==0xFF & data[1]==0xFF){ result=0; return result; } return result; }
  5. Makes sense, I have it implemented outside at the moment and works ok. I have implemented an UART parser, that spawns task when commands come. The problem arises when the task has not yet finished and the two instances run concurrently. Should this be something handled by the scheduler? As a workaround I am implementing a safety flag for it.
  6. @@vladn would it be possible to add a statistical output per thread that shows the maximum observed execution time, would be rather helpful when designing a system for threads not to be too long and/or detect unwanted blocking.
  7. I am trying to use this library on Tiva C launchpad with Energia 0012 and SSD1289 display from http://www.ledsee.com/index.php/lcd-display/3-2-inch-tft-lcd-240-320-touch-screen-on-pcb-detail . However I am unable to get the display working, I have used the default pinout with an https://github.com/jscrane/UTFT-Energia/tree/master/examples/lm4f/UTFT_Demo_320x240 example sketch. Have checked the connections with a multimeter and verified data is send down them with an oscilloscope. Everything appears to be ok, the only anomaly sppotted is that some data lines DB5-7 have signals rising only to 2.5V, while all others go norlayy to 3.3V. Not sure what could be causing this, but it should not cause this problems. Does anyone have some pointers how to go about debugging this?
  8. Follow the tutorial you have posted, just repeat the connections on the second launchpad., Load one with TX demo and the other with RX demo that comes with this library.
  9. Edit: Probably misunderstood your question. You would like to put two transceivers on a single Launchpad? Then read below There are probably two options. Having both transceivers on the same SPI bus and assigning different CSN, CE and IRQ pins to them. To do this, you need to create two radio objects, for example: Enrf24 radio1(CE_1,CSN_1, IRQ_1); Enrf24 radio2(CE_2,CSN_2, IRQ_2); Then you repeat the begin and configuration code for both. I havent tested this yet myseld, but should work in theory. The second option is to use two different SPI buses, for that the Enrf24 library needs to be adapted, to support SPI argument as well. Again, writing this without testing: Enrf24.h must have the constructor fixed and an include added. #include <SPI.h> Enrf24(SPIClass *mySPI, uint8_t cePin, uint8_t csnPin, uint8_t irqPin); SPIClass *_mySPI; Enrf24.cpp must have the constructor fixed and all instances of "SPI." changed by "_mySPI->" /* Constructor */ Enrf24::Enrf24(SPIClass *mySPI,uint8_t cePin, uint8_t csnPin, uint8_t irqPin) { _mySPI = mySPI; _cePin = cePin; _csnPin = csnPin; _irqPin = irqPin; rf_status = 0; rf_addr_width = 5; txbuf_len = 0; readpending = 0; } Then in your main code you call this fixed library by: //radio Enrf24 radio(&SPI, ENRF24L_CE, ENRF24L_CSN, ENRF24L_IRQ); where SPI can be SPI0 for channel 0, SPI1 for channel 1, SPI for channel 2 (default), SPI3 for channel 3. This should work in theory, but needs to be tested. There could be a neater solution though.
  10. Great job, thanks! Some debugging advice: - if TX demo reports Actively transmitting, check CE pin. - if on the RX side you only see periodic text about received data, but not the castual string, check IRQ pin. - when using the communication with custom data, mind using print and write, the first converts your data into ASCII I have my use case happily running, will prepare an example for sending a packet with various data in a single packet shortly.
  11. As it turns out, this wild goose chase has been created by a series of problems as follows: - CE on one of the test setups had stray resistance to another pin, due to the error on the PCB - solving this problem led to small changes in the library which broke the system further - I have skipped as step of freshly updating the library at some point Both old and GIT versions work with Tiva C Launchpad. I suggest the following fixes. TX demo suggests radio.print(str_on); radio.flush(); // Force transmit (don't wait for any more data) dump_radio_status_to_serialport(radio.radioState()); // Should report IDLE However the serial output states: Sending packet: ON Enrf24 radio transceiver status: Actively Transmitting Sending packet: OFF Enrf24 radio transceiver status: Actively Transmitting Why the state reported is different from the one suggested in the demo? Following up on this to the library with a possible failure on CE pin will results in TX buffer overflowing and the sketch crashing due to: if (reg & BIT5) { // RF24_TX_FULL #define is BIT0, which is not the correct bit for FIFO_STATUS. return; // Should never happen, but nonetheless a precaution to take. } Before returning this should probably do: txbuf_len = 0; // Reset TX ring buffer preventing the problem like this. Spirilis, thank you very much for your responses, they lead me to finding the problem, hopefully this run helps improve the library as well.
  12. The same setup as described in my previous posts works out-of-the-box with ZIP library http://forum.43oh.com/topic/3237-energia-library-nordic-nrf24l01-library/page-7#entry38488 ZIP version is of an older date then github, so there must have been some bugs introduced in the github version.
  13. Github, SHA c131089310980a1e6d799858e2700b866e832107, the latest there.
  14. I have eliminated the electrical issues with the following method: Used a brand new, fresh Launchpad Tiva C and NRF24L01+ module. Applied the previously posted sketch. Repeated the procedure with two more Tiva C Launchpads and some more nrf modules. Checked nfr modules win MSP430 launchpads, working as they should with the same library. Only remaining thing that comes to my ming is some buffer owerflow, screwing things up like this. This being only a Stellaris issue though.
  15. I believe it is genuine nRF24L01+, green board, 10pin connector. Chip markings state NRF 0 24L01+ (1423CC date?). Increasing the delay to any time, or even removing the digitalWrite(_cePin, LOW) does not make a change. Even permanently changing all of the CE writes to HIGH does nothing. So I have investigated further and something strange is going on. Chooring a random pin for CE does not change anything, say PE_2. Setting pin PD_0 to output and HIGH prevents the module to be found. So this part of the problem may have nothing to do with the library as such.