• Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by Fmilburn

  1. Seveal instances of this are scattered over 43oh. Maybe add it to this porting libraries link:
  2. Hi @Alice12789 I don't think that boosterpack is available any more. A readily implemented alternative is to buy a breakout board, e.g I haven't used that particular one, also note there are also others available.
  3. Project Closure Here are the original objectives along with closure notes that may be of interest to some... cost - unit cost for the receiver of $10 or less - The project came in at less than $10 for each receiver, even in small quantities. technology - common off the shelf components, MSP430G2553 - The G2553 was more than adequate for the project. Also used the TSOP38238 for infrared and the SK2812 for LEDs which are readily available and inexpensive. construction - standard double sided PCB spec, keep SMD parts large enough to be hand soldered - I used OSH Park for the PCBs and 0805 components for the jelly bean parts. Everything was hand soldered. I did find it a bit difficult to hand solder the SK2812 and had to go back and retouch a number of them up. Not sure why, the part is relatively large. power - CR2032 (rated 3V and 225 mAH) - Worked well, even with the SK2812 which have a higher voltage on the datasheet and despite drawing 10 mA or more. life - needs to run at least half an hour on fresh batteries - Battery life is easily an hour or more the way I am using it. Current is on the order of 10 mA as noted above. reception - 10m with clear line of sight, update at least every 100 ms - This is easily done provide there is line of sight and IR LEDs with sufficient beam width are chosen. As noted in the thread above, multiple transmitters can be used which can help meet this requirement. transmission - desirable but not required - I chose not to make the receivers capable of transmission. size - 40mm/1.6" diameter for receiver - Easily done, see photos below. programming - Energia desirable - The receivers were programmed in Energia as noted in the thread above. The transmitter was programmed with CCS but I ended up using UART to communicate with it. Accordingly, any computer or microcontroller with UART can be used to direct the transmitter. This was actually one of the more interesting parts of the project and I may write a tutorial on the method at some point in future. schedule - 6 month completion - It ended up taking 7 1/2 months but could have been done in half the time without my usual side tracks and procrastination. Here are some shots of the finished parts... Each receiver has a SK6812 soldered to it - it is lit red in the photo. The onboard SK6812 is not used in this project, instead a string of SK61812s is soldered on the 0.1 inch pitch header on the right side of the board (Dout, GND, and 3V3). The IR receiver is soldered to Pin 3, GND, and 3V3. Other pins, labelled with Energia pin numbers, are also available to the user. Programming access is at the top and I usually use Pogo pins although a male or female 0.1" pitch header could be soldered in. The 2032 battery is inserted from the bottom. On earlier versions I used WS2812 LEDs already soldered to PCBs for the string that is hot glued into the tiaras but ended up making my own and soldering SK2812 LEDs to them for the final project. The pins are "breadboard friendly". SK2812s are essentially the same as WS2812s and "Neopixels".
  4. This project is an offshoot of an earlier investigation of wireless wearables using the MSP430G2553: The concept has been successfully tested and is described below. I plan regular updates as the project progresses. The objective is to develop a wearable powered by a coin cell that can be controlled remotely. It could be used, as an example, in the tiara below or on a costume worn by dancers in a performance and controlled from offstage. In the photo an earlier MSP430G2553 coin cell powered wearable is attached to the tiara and driving 3 WS2812 LEDs. The constraints are: cost - unit cost for the receiver of $10 or less technology - common off the shelf components, MSP430G2553 construction - standard double sided PCB spec, keep SMD parts large enough to be hand soldered power - CR2032 (rated 3V and 225 mAH) life - needs to run at least half an hour on fresh batteries reception - 10m with clear line of sight, update at least every 100 ms transmission - desirable but not required size - 40mm/1.6" diameter for receiver programming - Energia desirable schedule - 6 month completion The transmitter will probably be placed on a "Booster Pack" for a LaunchPad running Energia. Multiple LEDs will be driven to gain extra distance, and if required multiple transmitters could be set up from different angles to assure good reception. A display would be helpful as on the FR6989 shown below with an IR LED. The initial Energia transmission sketch to test the concept is located here: The sketch was developed in Energia V17 using a MSP430G2553 LaunchPad and a 940 nm infrared LED. It loops from 0 to 255 and sends a single byte with the count via infrared to the receiver when a button is pushed. The packets for sending bytes do not follow an existing protocol. It is specific to this application and developed with the goal of getting a byte transmitted at least every 100 ms. The receiver will be a custom MSP430G2553 board powered by a coin cell with a TSOP38238 IR receiver. There will LEDs on the PCB and it will also have the capability to drive LEDs off board. The preliminary receiver code was written in C using CCS and direct register access: . The framework for the code is based on a post by RobG here on 43oh. The receiver takes transmissions from the Energia sketch linked above and outputs the current byte on eight LEDs in binary form. When the last byte is received it clears the LEDs and outputs the number of bytes received in error out of the expected 255. This allows analysis of reception at different distances and conditions. Shown below is the preliminary testing setup. In the foreground is the G2553 receiver with a TSOP38238 and output LEDs on a breadboard. Middle ground is a G2553 with the infrared LED sending bytes. Background is output from the receiver being monitored on an oscilloscope. The output of the TSOP38238 is quite clean and no errors were seen with the transmitter and receiver this close together. Transmission is at approximately 1000 bytes per minute or 16+ bytes/sec which is within the desired range. I subsequently modified the test setup to run off batteries so I could do some preliminary distance testing. With clear line of sight reception I saw no errors up to 5 meters with one transmission LED aimed directly at the receiver. Errors crept in after that, especially if the transmission is off to one side, not pointed directly at the receiver, or at a greater distance. Near term activities: increase the number of transmission LEDs evaluate the impact of off-center transmission further test in an environment that doesn't have reflective surfaces add WS2812 driver capability and investigating the impact of TSOP38238 interrupts on the WS2812 driver evaluate 2032 battery life further
  5. I have always used the reference page in Energia: Googling something like "vary time potentiometer arduino" will likely turn up code close to what you want. I don't see where you reset the time in your code, i.e. timer1 and timer0. One section of code is repeated and I assume that is not your intention. I would do something like this: /* * Varies the flashing period of the onboard red LED using a potentiometer * attached to a MSP430G2553. Tested with Energia V17. */ const int potPin = 7; const int minTime = 500; const int maxTime = 10000; unsigned long waitTime = 0; unsigned long startTime = 0; int ledState = HIGH; void setup() { Serial.begin(9600); pinMode(RED_LED, OUTPUT); startTime = millis(); digitalWrite(RED_LED, ledState); } void loop() { waitTime = map(analogRead(potPin), 0, 1023, minTime, maxTime); if ((startTime + waitTime) <= millis()) { Serial.println(waitTime); ledState = !ledState; startTime = millis(); digitalWrite(RED_LED, ledState); } }
  6. MSP430 Energia uses a lower power mode with delay() than Arduino but it still blocks other code from running. interrupts are another possible solution.
  7. if (delay == bad){ // and delay is to be avoided ! use delay } Set up a variable that records the start of the period - e.g. startTime = millis() Set another variable to hold the end of the period - e.g. finishTime = startTime + sensorTime Keep the loop going without a delay Keep reading values At the top of the loop check millis() to see if finishTime has been reached, if so take appropriate action Also check to see if the pot has changed more than some predetermined amount - if so, make desired changes There are quite a few tutorials around about how to avoid using delay(), e.g. this one turned up when I googled: There are some traps to avoid when using this method - e.g. use unsigned long, overflow, etc. The tutorials should touch on this.
  8. Once you start down the rabbit hole there is no end of unexpected things I believe the ones I have are for TV remotes or something like that where the user aims the controller at the device and tight focus is desirable. For example, here is the Everlight IR333A - my crude measurements show something similar: My idea for angling would be to make the PCB something like this for the desired angles and bend the legs of the LED 90 degrees to point them in the right direction: This would not be a good solution if the goal is SMD and simplified manufacture of course. Plus, it wouldn't fit neatly into a off the shelf enclosure. Other LEDs can be purchased that have a wider beam. For example there is a Kingbright SMD 0605 LED that is good for 50 mA and has 50% relative radiant intensity out to 120 degrees. Note that the example about had 50% relative radiant intensity only out to 20 degrees. I would need a lot more of them but they should be easier to assemble than bending leads and through hole soldering. It is also possible to get single LEDs rated at 1 Watt which might do the trick. Another idea to reduce parts is to use resistor arrays instead of individual resistors.
  9. Hi @indirtwetrust and welcome to 43oh. It always helps to post a simplified version of your code that demonstrates the issue so that others can replicate it. Perhaps you did not set the pins low before setting them to outputs? If not, I suspect the default is for Energia is to immediately set output to high. See the code below where I set pins low first: /* Test output state on powerup and reset * G2553 LaunchPad without crystal * Energia V17 */ void setup() { pinMode(PUSH2, INPUT_PULLUP); digitalWrite(6, LOW); pinMode(6, OUTPUT); digitalWrite(7, LOW); pinMode(7, OUTPUT); digitalWrite(8, LOW); pinMode(8, OUTPUT); digitalWrite(9, LOW); pinMode(9, OUTPUT); digitalWrite(10, LOW); pinMode(10, OUTPUT); } void loop() { if (digitalRead(PUSH2) == LOW){ digitalWrite(6, HIGH); digitalWrite(7, HIGH); digitalWrite(8, HIGH); digitalWrite(9, HIGH); digitalWrite(10, HIGH); } else{ digitalWrite(6, LOW); digitalWrite(7, LOW); digitalWrite(8, LOW); digitalWrite(9, LOW); digitalWrite(10, LOW); } } The logic analyzer in the screen shot below is set to capture for 5 seconds. When I start it, the LaunchPad is running and I am pushing the user button on P1_3, PUSH1, every second or so. As expected when P1_3 goes low, the output pins go high. In the next screen shot I wait about a second into the run to plug in the LaunchPad. As can be seen, everything is low to start and then P1_3 goes high as soon as it is reached in setup(). The rest stay low. It takes a while to start up because I don't have the crystal installed on this LaunchPad and Energia tries for a while to start it before giving up. The same thing if I do a reset - the output pins don't start out high.
  10. I will give you my relatively uneducated opinion for what it is worth... I don't think many professional C/C++ programmers (which I am not) would choose to use Energia in a commercial product and most commercial products do not use it. The same applies to Arduino. The reasons are many but there are exceptions of course. The most obvious exceptions are where the product is intended for Energia/Arduino users or it is a relatively simple application that fits Energia and the programmers skills well. I worked on a small project that used Energia and sold in very small quantity. See for example: You can discuss this with the PCB board assembler as some have this capability. In any event, if you can do it, you can find someone else who will do it for the right price. If you are going to build several hundred of these you might discuss your questions with a TI sales representative.
  11. New IR Transmitter Prototype Assembled I have not received the new PCBs yet but I did get the IR LEDs so I put together a "boosterpack" transmitter and a separate module to test coverage and range. They can be used together with crossed beams for coverage from two sides. The IR LED array on the left is lit, but since it looks to be off, it is apparent that my iPhone has an IR filter on it. Total current when on is on the order of 400 mA per bank and is controlled by a TIP120 Darlington Transistor which is all I had on hand that could carry the current. The TIP120 on the left has a heat sink on it but I found that wasn't necessary and the one on the right is bare. The LEDs are capable of 100 mA continuous each but are seeing less than 50 mA at peak here. If you look closely at the bottom row on the booster pack you can see the 0805 SMD resistors that are in series with each LED. Power is coming from a 1200 mAh lipo beneath the LaunchPad which seems sufficient for the task. This thing puts out a lot of photons compared to what I was using before. Indoors with white walls it even bounces around corners. I learned the following which will need to be incorporated into the next iteration: The beam is too narrow. I discovered this by testing outdoors with no walls to bounce off of. The LEDs I bought were from China and did not have a complete datasheet. Possible solutions are wider beam LED(s), angling them in such a way as to spread the beam, possibly reflect them with an umbrella as is sometimes done with a photographic flash. Use more SMD components. I would like to reduce the hand soldering. Looking for a SMD enhancement MOSFET that can handle 1A at 3.3V and not overheat in a small enclosure plus IR LEDs that fit the spec. Find an off the shelf enclosure and design around it. The receiver PCBs and WS2812 PCBs should come in next week.
  12. If you are referring to a setting in CCS then it can be done like this: 1) Select the register tab and then the register you are interested in while in debug mode 2) Right click on the number of interest int the value column and then number format 3) Select Binary I agree with the others. If you are serious, then get a logic analyzer even if it is a cheap 24 MHz one off of eBay. Also, take advantage of the TI training videos, e.g. training&tisearch=Search-EN-Everything composer studio training&tisearch=Search-EN-Everything
  13. Tiara Prototype Assembled I assembled one of the tiaras in more or less final form last week and while everything is working, and it meets the original criteria, I am working on additional modifications to improve ease of fabrication. Here is what it looks like at the moment: The fabrication problems are mostly around the wiring between the PCB and the LEDs. Soldering to the WS2812s is fussy and the wiring isn't too attractive as seen in this photo from the back: In addition, I've hot glued a pin header to the PCB and wired to that. All very unprofessional looking. There was also a potential problem with shorts when inserting and removing the battery. So, I've modified the PCB as follows and put them on order: This will allow soldering in a pin header or in the case of the TSOP 38 direct soldering. The three LEDs on the old receiver PCB have been replaced by a four pin 5050 SMD version of the WS2812. In addition, I am switching to the same LED for external lights and designed a small PCB to make attachment easier - they are a bit more than 11 mm in diameter: There was a recent blog on Hackaday about cables and I am thinking about ordering some custom ones to tidy up the wiring: Of course this will require yet another spin of the PCBs to accommodate the new cables but in the end it is all easier to assemble and neater. Meanwhile, the prototype I built for the transmitter looks crummy and I am still waiting on some parts. Plus, it was suggested that I needed to simplify the programming by the user further and perhaps have an automatic mode that would somehow work without programming on behalf of the user. So, I've ordered some MSGEQ7 Band Graphic Equalizer chips with the idea of using that plus volume to create some kind of automatic light show (feature creep alert). I will probably switch to a Raspberry Pi for the transmitter.
  14. I plan on going ahead and fitting it all together - it is the quickest way for me to put something together that won't fall apart and demonstrate the concept.
  15. Receiver Prototype Working After some stop and start I am back on this project and making progress. Here is the latest iteration: The wearable IR receiver and WS2812 controller at bottom runs off of a single 2032 battery. With only one LED lit at a time it is capable of easily running for an hour since current is down in the 10-15 mA range. It also transmits and receives with high reliability at 10 meters with two IR LEDs as shown. The transmitter is battery driven at the moment. I have a large number of IR LEDs on order so as to build a transmitter with a larger array of LEDs. It uses 2400 Baud UART for transmission. The transmitter code was written with CCS and is done in software with two timers. One timer maintains 2400 baud. To transmit a 1 bit the second timer is turned on and outputs a 38 KHz square wave over the IR LEDs until time for the next bit. For a 0 bit nothing is transmitted. The LEDs are rated for 100 mA each continuous but are being driven here at about 70 mA each with a NPN transistor hidden behind the jumper wires on the breadboard. On the receiver side the IR receiver turns the transmission into input that can be directly input into the UART peripheral on the MSP430G2553. A single byte is used to select the color and display mode of the WS2812 LEDs. The driver for the WS2812s uses the SPI method which I have posted elsewhere. There are some areas for improvement in the receiver PCB which I will incorporate in the next board spin but everything is working. A feature of this approach is that the receiver uses Energia with no tricks and even works on an Arduino Uno without modification other than pin changes. For the transmitter, I am still thinking about how best to implement. One approach would be to continue using a microcontroller such as the MSP430F5529 I am currently using with a keypad and display. Something like this mock-up: Alternatively, I could use something like a Raspberry Pi 3 and use Python to give Bluetooth LE access control over a phone.
  16. Nick Gammon published an interesting post on using SPI on 16 MHz Arduinos to run WS2812 LEDs (aka neopixels) at: He also provides a link with a lot of information about the NRZ protocol used by the WS2812 and tolerances: The tolerances are actually quite a bit looser than what I previously believed. So, I set out to do something similar with Energia and LaunchPads running at different speeds. Spoiler alert: It works. The previously linked articles provide all the background so minimal information is repeated here. NRZ is a one wire protocol that transfers information to the LEDs by varying the length of the signal when high. A longer pulse is used for a 1, and a shorter one for a 0. The timing, with tolerances, is shown in the figure below. The length between pulses cannot exceed about 5 us and most everything else is pretty loose. The protocol is implemented using SPI which I find pretty clever. A byte is sent out with the SPI module with the proper length to represent the desired bit for the protocol. The following must be determined and set to do this: Set proper SPI clock speed using SPI.setClockDivider() in Energia Determine the proper byte to send by SPI.transfer() in Energia to represent a 0 or 1 bit For example, using the MSP430F5529: Clock speed is 25.6 MHz Setting the SPI clock divider to 4 gives a SPI clock of 6.4 MHz and since the SPI block executes in one cycle (Arduino executes in 2), each bit in the byte is equivalent to 156.25 ns. Therefore, to send a pulse indicating a "1", a byte equal to 0b1111000 could be used which gives 4x156.25 = 625 ns. This is in the acceptable range of 550 to 850 ns. Similarly, for a 0 an acceptable byte would be 0b11000000 or 312.5 ns. A similar process can be used to determine acceptable values for the MSP430G2553. The sketch below is a simplification of the library presented by Nick which and includes the modifications described above to run on both the G2553 and F5529. The preprocessor is used to set appropriate values for the clock divider and long and short bytes. The functions are very nearly the same as posted by Nick. Note that interrupts must be disabled before sending data and then reenabled manually after. /* * WS2812 display using SPI on various TI LaunchPads with Energia * * Connections: * LaunchPad LED Strip * --------- --------- * 3V3 5VDC * Pin 15 (MOSI) DIN * GND GND * * How to use: * ledsetup (); - Get ready to send. * Call once at the beginning of the program. * sendPixel (r, g, ; - Send a single pixel to the string. * Call this once for each pixel in a frame. * Each colour is in the range 0 to 255. Turn off * interrupts before use and turn on after all pixels * have been programmed. * show (); - Latch the recently sent pixels onto the LEDs . * Call once per frame. * showColor (count, r, g, ; - Set the entire string of count Neopixels * to this one colour. Turn off interrupts before use * and remember to turn on afterwards. * * Derived from NeoPixel display library by Nick Gammon * * With ideas from: * * Released for public use under the Creative Commons Attribution 3.0 Australia License * * * F Milburn November 2016 * Tested with Energia V17 and WS2812 8 pixel strip on launchpads shown below. */ #include <SPI.h> #if defined(__MSP430G2553) #define SPIDIV SPI_CLOCK_DIV2 // 16 MHz/2 gives 125 ns for each on bit in byte #define SPILONG 0b11111100 // 750 ns (acceptable "on" range 550 to 850 ns) #define SPISHORT 0b11100000 // 375 ns (acceptable "on" range 200 to 500 ns) #elif defined(__MSP430F5529) #define SPIDIV SPI_CLOCK_DIV4 // 25.6 MHz/4 gives 156.25 ns for each on bit in byte #define SPILONG 0b11110000 // 625 ns (acceptable "on" range 550 to 850 ns) #define SPISHORT 0b11000000 // 312.5 ns (acceptable "on" range 200 to 500 ns) #else #error This microcontroller is not supported #endif const unsigned int PIXELS = 8; // Pixels in the strip void setup (){ ledsetup(); } void loop (){ // Show a solid color across the strip noInterrupts(); // no interrupts while sending data showColor (PIXELS, 0xBB, 0x22, 0x22); // single color on entire strip interrupts(); // interrupts are OK now delay(1000); // hold it for a second // Show a different color on every pixel noInterrupts(); // no interrupts while sending data sendPixel(0xBB, 0x00, 0x00); // red sendPixel(0x00, 0xBB, 0x00); // green sendPixel(0x00, 0x00, 0xBB); // blue sendPixel(0xBB, 0xBB, 0xBB); // white sendPixel(0xBB, 0x22, 0x22); // pinkish sendPixel(0x22, 0xBB, 0x22); // light green sendPixel(0x22, 0x22, 0xBB); // purplish blue sendPixel(0x00, 0x00, 0x00); // pixel off interrupts(); // interrupts are OK now delay(1000); // hold it for a second } // Sends one byte to the LED strip by SPI. void sendByte (unsigned char { for (unsigned char bit = 0; bit < 8; bit++){ if (b & 0x80) // is high-order bit set? SPI.transfer (SPILONG); // long on bit (~700 ns) defined for each clock speed else SPI.transfer (SPISHORT); // short on bit (~350 ns) defined for each clock speed b <<= 1; // shift next bit into high-order position } // end of for each bit } // end of sendByte // Set up SPI void ledsetup(){ SPI.begin (); SPI.setClockDivider (SPIDIV); // defined for each clock speed SPI.setBitOrder (MSBFIRST); SPI.setDataMode (SPI_MODE1); // MOSI normally low. show (); // in case MOSI went high, latch in whatever-we-sent sendPixel (0, 0, 0); // now change back to black show (); // and latch that } // end of ledsetup // Send a single pixel worth of information. Turn interrupts off while using. void sendPixel (unsigned char r, unsigned char g, unsigned char { sendByte (g); // NeoPixel wants colors in green-then-red-then-blue order sendByte (r); sendByte (; } // end of sendPixel // Wait long enough without sending any bits to allow the pixels to latch and // display the last sent frame void show(){ delayMicroseconds (9); } // end of show // Display a single color on the whole string. Turn interrupts off while using. void showColor (unsigned int count, unsigned char r , unsigned char g , unsigned char { noInterrupts (); for (unsigned int pixel = 0; pixel < count; pixel++) sendPixel (r, g, ; interrupts (); show (); // latch the colours } // end of showColor The timing, when checked on a logic analyzer, checks out with the calculations above (hooray for math). The "gaps" between pulses are within tolerance and largely set by code overhead as well as the byte being sent. And here it is showing the strip lit up in one color. I tried this on several other LaunchPads I had handy and here is a summary: FR6989 - I had never noticed, but Energia defaults to 8 MHz. Doing the math, there isn't a good match to the WS2812 requirements without changing processor speed (which I did not try). MSP432 - there was behavior I couldn't explain, probably due to RTOS and I didn't pursue this for long. In summary, the method works although I did limited experimentation. It would be even easier to implement outside of Energia with full access to clocks. It was an interesting exercise but alternative methods have been posted here on 43oh with tuned assembler and having used those successfully in the past, I will probably continue to preferentially use them in the future.
  17. Mine is Rev 1.6 but I should point out that RX,TX only ceased working when I accidently applied 5 volts to a pin - it worked fine before that. I have several F5529 LaunchPads and all were working on receipt Why use a F5529? The LaunchPad itself Costs $3 more but it is faster, has more memory, more and better peripherals (eg faster UART and higher resolution ADC), has USB, etc. It is easy to use if you are familiar with the G2553 and need the features.
  18. A while back I damaged two pins on this board and dutifully marked it on the back. Unfortunately it was only visible from the back. Some time later I picked it up and was trying to use it unsuccessfully. After tearing my hair out for a while I eventually turned it over and noticed the markings. Now it is marked front and back.
  19. PUSH is not a variable in the example / library that I suggested above so you must not be following the suggestion. In your first post it is not defined. It needs something like #define PUSH xxx where xxx is a pin number / designation. Doing a search for "DHT does not name a type" on the internet will give multiple hits and solutions to the problem so you apparently did not do the search as suggested. The library is probably installed incorrectly.
  20. As stated above, I tried the library that I linked above with a TM4C123 / DHT22 the same day I made the post and it worked. Use the example code that comes with the library. I was probably using Energia V17. Do a search with google with the error message text if you want to understand what it means.
  21. @Rickta59 I would not have caught that It works for me in V17 but not in V18. When I move it in V18, it works. What is happening?
  22. @energia I just tried compiling the nRF24L01 library in V18 and got the following error: In file included from C:\Users\Frank\Documents\Energia\MSP-EXP430F5529\Enrf24_RXdemo\Enrf24_RXdemo.ino:16:0: C:\Users\Frank\Documents\Energia\libraries\Enrf24/Enrf24.h:32:17: fatal error: SPI.h: No such file or directory compilation terminated. exit status 1 Error compiling for board MSP-EXP430G2553LP. @ghjkl67 You should not have to add SPI. Try using Energia V17 as I suggested above. You will find it here under previous releases: Energia V18 still seems to have some bugs. I just flashed the sample code on two G2553s with nRF24L01s using Energia V17 and they are working fine. EDIT: I would remove the old versions of Energia before loading a new V17.
  23. How do you know it works as a receiver if you don't have anything working as a transmitter - what are you receiving without a transmission? Have you gone back and double checked that one of my suggestions isn't the cause? I can assure you that the library works when connected properly with the nRF24L01+ modules I have and a G2553 LaunchPad. The datasheet for the nRF24L01+ has all the details and can be found with a google search - it uses SPI. SPI keeps the chip select pin high until it is ready to transmit and then pulls it low. It then returns to high following transmission. The code for the library is in Enrf24.cpp. Look inside at the code, e.g. void Enrf24::_writeReg(uint8_t addr, uint8_t val) { digitalWrite(_csnPin, LOW); rf_status = SPI.transfer(RF24_W_REGISTER | addr); SPI.transfer(val); digitalWrite(_csnPin, HIGH); } It pulls it low before transmitting then returns to high. One more suggestion - if you do a search on the internet you will find various people have found this helps: I include a decoupling capacitor in my designs and normally power the radio from a battery. Nonetheless, I have also had success powering off of the LaunchPad.
  24. I have used this library with both custom MSP430G2553 boards and the LaunchPad. Hardware setup is the same whether receiver or transmitter. Among the possible problems and solutions are the following: Bad nRF24 - the very first one I bought was bad damaged pin on MSP430 - don't apply 5V to a pin - this is a 3V3 device nRF24 wired wrong or wrong pin in software - easy to do poor transmission between modules - too far apart, object in between, or even too close together. modules set on different channel or other incompatibility in way software is set up In general though, I have found the library easy to use and reliable. I suggest you concentrate on getting the examples working first without any modification. I haven't tried it with Energia V18, you might try Energia V17. The following are the pins I normally use: nRF pin pin# Std color F5529LP pin G2553 pin ------- ---- --------- ----------- --------- Vcc 1 Red 3V3 3V3 GND 20 Black GND GND CSN 9 Yellow P4.2 P2_1 CE 8 Green P2.7 P2_0 MOSI 15 White P3.0 P1_7 SCK 7 Orange P3.2 P1_5 IRQ 10 Brown P4.1 P2_2 MISO 14 Purple P3.1 P1_6 I use the same wire color every time to ease checking that the connection is correct. If CE is not going high then try setting up a simple pin toggling program (e.g. the "hello world" pin wiggling and check with multimeter) to see if it works without the library. This will tell you if the CE pin on the MSP430 has been damaged. If so, changing to a different pin will fix it until you get a new $2 chip. EDIT: Some multimeters can be quite slow to update. When toggling pins to see if they are reaching a full on state, keep the toggling frequency to 1 Hz so the meter can keep up. For monitoring an application like the one above an oscilloscope or logic analyzer is a better tool.
  25. You haven't provided enough information to get help.... Most importantly you have not stated what about the code is not working. Is it failing to compile? Is it giving bad results? Is it failing to print? You haven't stated which library you are using, etc... So, anyone attempting to answer your problem would just be guessing. Try using the Adafruit library without changing anything and have it print directly to the serial monitor: Use pin 2 (PB5) on the LaunchPad. I just tried it on my TM4C123 and it worked. Once that is working, try adding in the code for the LCD.