SloMusti

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?

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 ha

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, jumpi

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.

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.

@@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.

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

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.

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 need

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.

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.radio

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.

Github, SHA c131089310980a1e6d799858e2700b866e832107, the latest there.

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.

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.