• Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by Fmilburn

  1. Hi @ChikamaYan I haven't used Energia in a while but I noticed there is a new version 1.0.2 available from the Boards Manager in Energia V18. I just tried it with the following on a Windows 10 machine and it worked as expected. void setup(){ Serial.begin(9600); Serial.println("Starting..."); } void loop(){ float test = 1.0; Serial.println(test); } When I copied your code I got a message about an extraneous character. Use the <> code insertion feature in 43oh when you insert code and it will end up like what I posted above. I notice the G2452 is available again also. Took a quick look at github and it looks like the FR2433 is being implemented in Energia as well. I have been fooling around with the FR2411 in CCS and like it - should be a good replacement for the G2553 but I wish it was available in TSSOP package.
  2. Hi @GhostArm Try this: RE: porting - do a search as there are a number of posts on 43oh
  3. Sometimes it is easier to use a separate MSP430 LaunchPad with eZ-FET to flash the G2. I have a MSP430F5529 set up with jumpers to do this and use it on custom boards and the G2 LaunchPad alike. The emulator on the G2 LaunchPad is just flaky at times.
  4. I do not know why it is not there - it is in the Reference section of the Energia documentation. Probably an oversight that was corrected in V18. However, see this link for an implementation using a macro:
  5. I have only used the NRF24L01 between MSP430s and not with an Arduino - however, did you read through the Wiki? Regarding pipes, see this:
  6. I put together a prototype Booster Pack that attaches to the CC3200 and has a RFID-RC522 card (sometimes called a MIFARE module), two buttons, and two LEDs. The CC3200 is connected to the cloud using Temboo. Currently it sends an email to me with information on the card used when accessed but it would be easy to modify to record time of access, card used, etc and put it into say a spreadsheet. This was a one afternoon plus an evening project for both hardware and software using Energia - very easy to do. The cards have security holes but I am pretty sure they pose too high a technical challenge for my local hooligans. I'm more afraid they might rip it apart and take my CC3200 than anything else. This is the Booster Pack, top view. Here it is attached to an upside down CC3200. In this photo it has been mounted in an enclosure and is reporting a successful read and transmission with the green LED. And if you are really interested, here is the schematic. I am using the RFID library located here. And if you aren't familiar with Temboo, find it here.
  7. I don't have a working CC3200 and have not tried using one with CCS. You might try starting a new thread here in 43oh or in E2E that fully explains the problem you are trying to solve and the things you have tried so far.
  8. Hard to say with the information you have given... The two sides of the RXD/TXD must be connected of course.
  9. There are two hardware UARTs on the F5529. See the Energia pin diagram here. Note that P3_4 and P3_3 are designated as RX(1) and TX(1) respectively. RXD and TXD are connected to P4_5 and P4_4 on the header with the jumpers. When you specify Serial in Energia it is using P4_5 and P4_4. Quoting from the Energia reference on the Serial Library: To use pins P3_4 and P3_3, specify Serial1 instead of Serial.
  10. You could use attachInterrupt() to detect when the pin of interest has changed (e.g. in your example when the sequence changes from xx0x to xx1x). At that point you could use digitalRead() to determine the status of the other pins. However, digitalRead() is relatively slow. If you are willing to give up compatibility with other processors then the register containing the input values for the port can be read quickly and directly. For example, the following reads and prints the input register for port 1 and then masks out and prints G2 LaunchPad pin 5 (P1.3) which is attached to switch S2 on the G2 LaunchPad. void setup() { Serial.begin(9600); pinMode(5, INPUT_PULLUP); // G2 LaunchPad push button } void loop() { Serial.println(P1IN); // Input register port 1 Serial.println(P1IN & BIT3); // Pin 5 is P1.3 delay(100); } The GPIO registers are described in the Family User Guides for TI microcontrollers - see SLAU144J for the x2xx family. It might be cleaner just to do this in CCS without using Energia.
  11. Hi @nirbar11 and welcome to 43oh I am not sure I understand your objectives but here is something to get you started... Don't use pin names of the form P1_x in Energia as this has been deprecated Don't put print statements (or other slow to execute code) inside of interrupts - flag the interrupt and handle it elsewhere You will probably want to avoid using delay() in your code Note that if using a G2 LaunchPad that P1.0 and P1.6 are attached to LEDs via jumpers that can be pulled Here is some example code that detects buttons being pushed (no debouncing). volatile bool pin5Pushed = false; volatile bool pin6Pushed = false; volatile bool pin7Pushed = false; volatile bool pin8Pushed = false; void setup() { Serial.begin(9600); pinMode(5, INPUT_PULLUP); pinMode(6, INPUT_PULLUP); pinMode(7, INPUT_PULLUP); pinMode(8, INPUT_PULLUP); attachInterrupt(5,interrupt5,FALLING); attachInterrupt(6,interrupt6,FALLING); attachInterrupt(7,interrupt7,FALLING); attachInterrupt(8,interrupt8,FALLING); } void loop() { if (pin5Pushed == true){ Serial.println("Pin 5 pushed"); pin5Pushed = false; } if (pin6Pushed == true){ Serial.println("Pin 6 pushed"); pin6Pushed = false; } if (pin7Pushed == true){ Serial.println("Pin 7 pushed"); pin7Pushed = false; } if (pin8Pushed == true){ Serial.println("Pin 8 pushed"); pin8Pushed = false; } } void interrupt5(){ pin5Pushed = true; } void interrupt6(){ pin6Pushed = true; } void interrupt7(){ pin7Pushed = true; } void interrupt8(){ pin8Pushed = true; } And finally, avoid double posting.
  12. Seveal instances of this are scattered over 43oh. Maybe add it to this porting libraries link:
  13. 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.
  14. 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".
  15. 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
  16. 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); } }
  17. MSP430 Energia uses a lower power mode with delay() than Arduino but it still blocks other code from running. interrupts are another possible solution.
  18. 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.
  19. 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.
  20. 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.
  21. 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.
  22. 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.
  23. 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
  24. 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.
  25. 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.