Jump to content


  • Content Count

  • Joined

  • Last visited

About JasonP

  • Rank

Contact Methods

  • Website URL

Profile Information

  • Location
    Idaho Falls, ID
  1. Posted new issue MSP432 Serial baud rates. #946
  2. @@Fmilburn, @@energia, I think this is officially an Energia issue. I have probed both Rx and Tx pins of Serial1 port with a logic analyzer and see no activity below 4800 baud. Note that I did try 2400, 1200, 300.
  3. @@Fmilburn, @@chillyjee, @@energia I have updated to Version 18 because I was having issues with various Baud Rates on Serial and Serial1. After the update I was able to use baud rates 4800 and above. However I can not get baud rates below 4800 to work. I really need a 1200 baud rate to work on Serial1 as the sensor I need to communicate with has a set baud rate of 1200. Can either of you verify that this does not work please. void setup() { Serial.begin(1200); Serial1.begin(1200); Serial.println("Starting..."); } void loop() { Serial1.write('A'); if (Serial1.available()) { int inByte = Serial1.read(); Serial.write(inByte); } delay(1000); }
  4. I am on Mac Osx, MSP432 LaunchPad. If this has been mentioned previously, I apologize. I wondered where folks were clicking the "update" button because I never saw it in ENERGIA 18. I tried downloading the terminal/dfu utilities from TI but was unable to update the emulator. I kept getting "command not found" errors even though I was in the correct directory. I gave up. I found the easy fix was to use TI's Cloud Tools which includes an cloud based version of CCS found here: https://dev.ti.com/. I ran a sample Energia program with the board plugged in. I got the same error as in Energia Error connecting to the target: (Error -1040 @ 0x0) A firmware update is required for the debug probe. Click the "Update" button to update the firmware and connect to the debug target. DO NOT UNPLUG THE DEBUG PROBE DURING THE UPDATE. After which, the "update" button appeared. I clicked the update button and now it works in Energia. It does seem to be a little flaky however. Sometimes it won't upload giving me a "can't connect to target" error. Side note: Can anyone run Serial or Serial1 at different baud rates than 9600? This was the reason I updated everything and it still doesn't seem to work in ENERGIA 18
  5. @@Fmilburn, Yeah I saw that initially so I went out to Energia's github page and grabbed the SoftwareSerial library. (Which is apparently not the correct library for MSP - boards). Makes sense now that I see the AVR libraries included in the SoftwareSerial.cpp file. Thanks.
  6. Really I only need two serial ports for this project. I can use the hardware defined serial ports. However, I only see one UART port on the pin map for the MSP-432. @@Rickta59, do you know which pins Serial1 would be on? Thanks guys!
  7. I'm using Energia V17 and will be compiling for an MSP-432 launchpad. @@Rickta59, Is there a version of Software Serial that will work for me? I guess I'm confused why the AVR only version is in the Energia Repository? Thanks guys.
  8. Hello, I am having problems compiling a sketch that utilizes Software Serial. I'm sure I am simply missing a library somewhere, just not sure what it is. I have attached an image of the errors I am seeing from the compiler window. #include <SoftwareSerial.h> void setup() { // put your setup code here, to run once: } void loop() { // put your main code here, to run repeatedly: } Can someone verify that Software Serial is working in Energia and perhaps tell me what I am doing wrong? Thanks! -Jason
  9. @@abecedarian, Ha ha I was just writing to say thank you to everyone that has pitched in and helped me, especially you! Honestly I don't see a better workaround for the time being and things are actually working flawless. Spitting the two interrupts into two is actually nice as each interrupt is much simpler. Thanks again. ////////////////////////////////////////////////////////////////////////////////////////////// ///////////////////////////////// I N T E R R U P T //////////////////////////////////// ////////////////////////////////////////////////////////////////////////////////////////////// void risingA(){ // Must be a low-to-high on channel A Ahigh = true; // The pin must be high to get here. // check channel B to see which way encoder is turning if (!Bhigh) { encoder0Pos++; // CW direction = 1; } else { encoder0Pos--; // CCW direction = 2; } } ////////////////////////////////////////////////////////////////////////////////////////////// ///////////////////////////////// I N T E R R U P T //////////////////////////////////// ////////////////////////////////////////////////////////////////////////////////////////////// void fallingA(){ // must be a high-to-low edge on channel A Ahigh = false; // check channel B to see which way encoder is turning if (Bhigh) { encoder0Pos++; // CW direction = 1; } else { encoder0Pos--; // CCW direction = 2; } } ////////////////////////////////////////////////////////////////////////////////////////////// ///////////////////////////////// I N T E R R U P T //////////////////////////////////// ////////////////////////////////////////////////////////////////////////////////////////////// void risingB(){ // Must be a low-to-high on channel B Bhigh = true; // check channel A to see which way encoder is turning if (Ahigh) { encoder0Pos++; // CW direction = 1; } else { encoder0Pos--; // CCW direction = 2; } } ////////////////////////////////////////////////////////////////////////////////////////////// ///////////////////////////////// I N T E R R U P T //////////////////////////////////// ////////////////////////////////////////////////////////////////////////////////////////////// void fallingB(){ Bhigh = false; // must be a high-to-low on channel B sensblast = false; // check channel B to see which way encoder is turning if (!Ahigh) { encoder0Pos++; // CW direction = 1; } else { encoder0Pos--; // CCW direction = 2; } }
  10. @@abecedarian, Thanks for the Idea of using two pins for the interrupt rising and falling. This actually would solve most of my issues as I would then truly know the state of the pin.... I think. Also thanks for this little sample sketch I will try running it later today.. HA I was going to ask if you tried different delays since 100mS vs 200mS might be hard to tell, but I see in your edit you did that The GPIO thing isn't really an issue for us. Thanks again.
  11. @@chicken, Your'e right. It doesn't really solve the problem. I posted a followup over there after I pulled my head out and realized that is not an actual workaround. Re-establishing the interrupt within the interrupt might work. I know detaching and reattaching inside an interrupt does work on my arduino. I might have to try that. I really didn't want to have to refresh on C but maybe I will have to... Or revert back to arduino.
  12. @@energia, @@Fmilburn Ryan Brown over at TI has given a workaround for the digitalRead(). It is found here: https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/506515/1838064#1838064 I'm not quite sure how this works but it does seem to.
  13. That's good to hear. Iv'e also done that a couple times
  14. @@Fmilburn, Thanks for mentioning that. That explains what I have been seeing but I did not pick up on that. I was going insane here trying to figure out why my arduino based code that has worked flawlessly isn't working at all. I hope these issues can get resolved soon. @@energia, Has an issue been created for the attachInterrupt(CHANGE) problem that @@Fmilburn just mentioned?
  15. Robert, I have created the new issue found here: https://github.com/energia/Energia/issues/873 Also I was wondering if you can think of a workaround in the meantime? We are trying to have a working prototype by next week. Thank You.
  • Create New...