Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Reputation Activity

  1. Like
    abecedarian got a reaction from L.R.A in MSP432 + Energia + Code composer studio   
    MSP432 doesn't appear to be on the CCS supported list, whether trying to make a new project or importing one.
    I only get LM4F and MSP430 targets available, even if I'm trying to import an Energia example from the Multitasking branch.

    *edit= this is CCS 6.1.00104 on my end.
  2. Like
    abecedarian reacted to spirilis in My time with the Renesas RX   
    After playing with C++ templates in e2studio and GNURX, I ended up tracking down a nasty bug in the compiler that turned out not to be a compiler bug, but rather, an idiotic set of defaults in the GNURX project generator's default linker script configuration.  Learned quite a bit with that wild goose chase...
    (Or as a coworker software developer told me, "It's every programmer's favorite pastime to blame the compiler!")
    e2studio (Eclipse) has a graphical interface for configuring the ld sections, and one option you can do per section category is "KEEP" .... in reality GNU ld linker scripts allow freeform use of KEEP() for individual sub-sections included within a section, but the Eclipse GUI-ified ld configuration tool only lets you apply KEEP to the whole section.  Looking at a genuine RedHat Newlib ldscript is helpful in figuring out what should be forcibly "kept".
    As it turns out, in order to use C++ properly with inheritance and virtual functions, the C++ compiler uses something called "Virtual Tables" to perform at-runtime indirection of function calls (so that a pointer of a parent class type pointing to a subclass's memory contents will correctly run the subclass version of a function, rather than the parent class's version of a function, without necessarily knowing what the subclass type is at compile-time).  This requires a few pieces of plumbing- the virtual table itself (often starting with _ZTV in the verbose mangled symbol name) and the init function that loads the correct vtable addresses into each static instance of a class, typically called _GLOBAL_sub_I_<objectname>.
    The _ZTV virtual table symbol and type information is typically part of the .rodata section, i.e. .rodata._ZTVMyTemplateASDF or whatever, whereas the _GLOBAL_sub_I_<objectname> is part of the .init_array section.  However neither of these are necessarily referenced explicitly from the C init runtime routines (the GLOBAL initializer has a pointer loaded inside the __init_array section), so the linker (with -Wl,--gc-sections) will gladly garbage-collect them from the binary*, resulting in C++ objects that aren't correctly initialized (VPTR's stored as a hidden class member in the bss-initialized space which is all 0x00's) and with the vtable being used to look up function addresses, the CPU will go off into lala land (PC branching to 0x00000000 at the beginning of SRAM) when you execute an overridden subclass function.
    * - Something about this explanation doesn't quite feel right, as I would imagine with the GLOBAL init function's pointer present in __init_array it shouldn't see any reason to garbage collect it, but this is what I've seen with the GNURX toolchain builds.  Perhaps the problem is that this array is only referenced via some ldscript-provided pointers during the C init runtime routines.
    To alleviate this, .init, .fini and .rodata should have KEEP() around their symbols (or certain ones of them in the case of .rodata but I just have the whole section wrapped in KEEP) to ensure they aren't garbage-collected.
    Strange quirk, you can tell not many Renesas customers use C++ since this was never caught before.  I recall a video of a Renesas DevCon talk doing a call of hands of who uses C++ .... maybe 1 hand in the crowd went up.  Wouldn't be shocked if they never bothered with virtual functions either.
    I happen to think these 32-bit chips are perfect for this kind of work, as I previously stated, so I'm all about fixing the bugs if they're not too heinous.
    So here's my current "checklist" on starting a C++ application with Renesas e2studio + KPIT GNURX:
    Open Project Preferences > C/C++ build
    1. Compiler Miscellaneous options - enable -fdata-sections and -ffunction-sections
    2. Compiler user-defined: Add -fno-exceptions and -fno-rtti
    3. Library Generator user-defined compiler settings: Add -fno-exceptions and -fno-rtti
    4. Include paths - add the src folder of the project itself so I can reference my .h files with <> and not just ""
    5. Linker Sections - for .init, .fini and .rodata, expand the "Advanced" section on the right side and check the KEEP option
      ** after doing this and hitting "Apply", go back into the project settings and make sure these actually got set; seen many projects misbehave b/c the setting didn't "stick" for some reason... maybe hitting "Ok" without hitting "Apply" inside the linker settings section isn't good enough
    6. Linker Miscellaneous - enable -Wl,--gc-sections
    7. Library Generator > Other Options - set Optimization type to "Code size optimization" (-Os) or whatever else
    8. Compiler > Object - set Optimization level to "Code size optimization" (-Os) or whatever else
  3. Like
    abecedarian reacted to Fmilburn in Windows 10 failure   
    I have been using Energia 16 and Windows 10 without a problem.  In fact, certain things like selecting a new board and changing the serial port happen faster compared to Windows 8.1.
  4. Like
    abecedarian reacted to spirilis in My time with the Renesas RX   
    Must be the fall weather (no, it's been hot), or maybe some gripes I've seen with TI's msp430-elf-gcc lately, but I'm taking a fresh look at the Renesas RX stuff.  First a sniff test...
    Current release of GNURX (v15.01-SP1) seemed to ship without libstdc++ for the no-fpu-libs variant of newlib, which is problematic for running C++ on any RX100 or RX200 series.  However, opening a ticket at kpitgnutools.com - they responded overnight that they reproduced the problem and a fix is forthcoming soon.  That's good to know the support is responsive for the free compiler.  The previous GNURX v14.03 release has libstdc++ in no-fpu-libs so I can compile with that for now.
    RX chips seem to be quite available at DigiKey, although prices are a bit high.  Avnetexpress has fewer chips in stock than I ever saw before, but that might simply mean that more customers use DigiKey now, as evidenced by the multitude of chips digikey actually have in stock.
    Renesas' e2studio IDE has come along, up to version 4 now.  No surprises there.
    Newer chips released since my last jaunt with the architecture include the RX100 series, now with 3 generations - RX110, RX111, RX113.  These would compete roughly with the MSP432 I guess (32-bit ULP 1.8-3.6V).
    RX200 seemed like an ugly duckling of the line but they do have an RX23T line for motor control... and the existing RX210 parts have newer generations (e.g. "revision C" vs "A").
    RX600 has a new RX64M which I don't know much about... and there's the newer RX700 with an "RXv2" arch which I know nothing about yet.  Parts look to be available but expensive for those newer parts.  Any MCU > $10 starts to bug me for some reason...
    For the RX210, there's a 0.65mm pitch 80-pin part available at digikey and orderable through avnet, the R5F52108CDFF which looks promising for large hobby type projects.  That's a non-FPU, 50MHz, 512K flash/64K SRAM part.  The nice thing about RX200 series is the 1.62-5.5V voltage range supported, so this can support 5V projects powered directly by a USB charger sans regulator, and work with 5V LCD hardware too.  OTOH, they don't include any CAN, which bugs me.  Only 1 SPI and 1 I2C port seems out of proportion relative to the pin count of the chip too.
    RX631 has a 48-pin LQFP part (R5F5631PCDFL $5.47 @ avnet no stock sans CAN, R5F5631PDDFL $8.44 in stock @ avnet with CAN) which is promising for non-battery powered (say, USB charger w/ regulator or buck) IoT type of crap.  RX63N is available with native Ethernet of course, but I suspect nowadays built-in Ethernet MAC isn't the bees knees as much; using smaller chips communicating with a WiFi transceiver over SPI or UART is in vogue.  Even using a smaller chip with a Wiznet W5500 or similar as an Ethernet co-processor would be easier to integrate from the software standpoint IMO than working out an install of lwip or uip or whatever into a 63N.
    Anyway, this is just a 1 day revisit for now... I am probably going to do more with my RX210 board soon for fun including porting a project I've called "AbstractWiring" over to it so I can use Arduino libs with the chip.  I think these RX chips, similar to ARM, are perfect for ambitious C++ based projects.
    Also very thankful I dumped all the information I did into this thread, and it's still around... useful info to have (e.g. the YRPBRX210 board schematics which I couldn't find at first)
  5. Like
    abecedarian got a reaction from OzGrant in 5529 sets an output before setup()   
    "CODE" tags- the button in the advanced editor ("More Reply Options") with "<>" on it, or manually type in [ CODE] and [ /CODE], without any space after the opening brace.
    const char Sketch[]="AjonFlash20 "; const String BTADDR1="+ADDR:2013:9:11"; // this is BT #3 //From bildr article: http://bildr.org/201...ncoder-arduino/ #define intest 0 // no test //#define intest 1 // in test #define test 0 // no test //#define test 1 // Serial.print state and choice #include "MspFlash.h" #include "IRremote.h" #include "LiquidCrystal.h" #include "rgb_lcd.h" #include <Wire.h> #include <FRAMX.h> //#include <SoftwareSerial.h> //#define BT_TX 39 //#define BT_RX 40 //#define BT_KEY 38 //boolean GFuseold=true; #define bannerLength 72 #define MAXIR 22 // number of buttons on IR controller #define MAXTEXT 6 //number of inputs requiring Text #define MAXDEFINES 9 // now includes balance(Left/Right)Offset and mmStatus. Defines used in FRAM stating at 0x10 #define USESMALL true // true for SMALL vero card //#define USESMALL false for LARGE vero card #define greenLED 12 //6apr2015 P2_7 //was P7_4 //=17 // was 9 moved to allow link #define blueLED P2_6 //=13 // was 8 #define output1 P1_4 //apr15 WAS #define output1 P3_5 #define output2 P1_5 //apr15 WAS #define output2 P3_6 #define output3 P4_0 #define output4 P8_2 #define output5 P7_0 #define output6 P2_4 //apr15 WAS #define output6 P3_7 #define power P2_5 //apr15 WAS #define power P3_2 //P6_6 // was P3_7 #define mute P8_1 //apr2015 was P6_6 #define fetPin P1_3 #define linkOut P7_4 #define linkIn P1_4 #define pinMM P2_6 #define LEDRATE 400 #define w 0 //white #define r 1 //red #define g 2 //green #define b 3 //blue #define p 4 //pale blue #define y 5 //yellow #define v 6 //violet #if USESMALL // SMALL vero #define encoderPin1 19 //was 2; #define encoderPin2 18 //was 3; //6apr2015 #define encoderSwitchPin 8 //6apr2015 WAS P2_3 //12 //push button switch #define RECV_PIN P1_6 //was 6 #else //BIG vero #endif boolean mytest=true; boolean doingBalance=false; boolean mmStatus=true; boolean muteState=true; String sData; //SoftwareSerial BTSerial(BT_RX,BT_TX); //Bluetooth RX | TX //Initialize the FRAM and use the default FRAM address that's provided FRAMX fram(FRAMX::FRAMX_I2C_DEFAULT_ADDRESS); unsigned char bytes_read; //Initialize to known data so we can tell if transactions are actually having the desired effect static unsigned char read_buffer[10] ={0xDE,0xAD,0xBE,0xEF,0xDE,0xAD,0xBE,0xEF,0xAA,0xAA}; static unsigned char write_buffer[10]={0xDE,0xAD,0xBE,0xEF,0xDE,0xAD,0xBE,0xEF,0xAA,0xAA}; unsigned char start_address = 0; unsigned char bytes_to_transfer = 1; // do not exceed the length of your read and write buffer unsigned long readcodes[16]; unsigned long FetMute; uint32_t framIr[MAXIR]; //IR codes from FRAM0 0x20 uint8_t framChr[MAXIR]; //IR Chr code from FRAM 0x20 String framText[6]; // Text from FRAM 0xB0 uint8_t framDefines[MAXDEFINES]; //Defines from Fram 0x10 int16_t countLast=0; int16_t countNow=0; uint8_t aBalance=0, bBalance=0; uint8_t balanceRightOffset=0; uint8_t balanceLeftOffset=0; uint16_t balanceDefault=0x3F; String sVersion; String EEwrite; String sTemp; char cTemp; int8_t iTemp; int8_t jTemp; char cArray[]={" "}; uint8_t i; uint8_t j; char cmdNum; int inByte = 0; // incoming serial byte #define sMenu0 "Grant 0422179043" // was const char sMenu0[]={"Grant 0422179043"}; #define blankLine " " char sInputSelect0[]={"Input Select "}; char sInputSelect1[]={"123456 "}; char work; unsigned int state = 0; char inputIs = 0; volatile int lastEncoded = 3; volatile long encoderValue = 0; long lastValue; unsigned int encoderSteps = 16; //used for altering LCD back light long startTime = 0; long lastencoderValue = 0; long l; unsigned int encoderPWM; unsigned int encoderVolume; boolean ledState = true; boolean redState = 1; // Led Off boolean greenState = 1; // Led Off boolean blueState = 1; // Led Off boolean pollEncoder =false; int lastMSB = 0; int lastLSB = 0; long previousMillis = 0; long currentMillis; boolean doPrint=false; int8_t choice=-1; boolean LedState=false; //int RECV_PIN = 6; //11; unsigned long myvalue; IRrecv irrecv(RECV_PIN); decode_results results; boolean IRcommand =false; byte IRgot; boolean doText =false; //construct words unsigned int mycount=0; rgb_lcd lcd; unsigned int mode =0; boolean haveData=false; boolean haveData4=false; int EEinputs=6; //=5; int EEsteps=2; //=3; int EEstepsTest=1; //EEsteps=EEstepsTest; //6apr2015 WAS uint16_t EElight=80; uint8_t EEvolume[6] ; //={10,20,30,40,50}; unsigned long EEscale[9] ; uint8_t EElastInput=0; uint8_t EEpwm=0xFF; byte square[8] = { // make some custom characters: 0b00000, 0b00000, 0b11111, 0b11111, 0b11111, 0b11111, 0b00000, 0b00000 }; byte filler[8] = { // make some custom characters: 0b00000, 0b00000, 0b00000, 0b10101, 0b10101, 0b00000, 0b00000, 0b00000 }; char lastDecode; boolean doOnce; boolean powerUp = true; boolean allowIRcommands; unsigned int redPWM = 255; unsigned int greenPWM= 255; unsigned int bluePWM = 255; boolean doOnceMute=false; boolean lcdSleep=false; unsigned long lcdPreviousMillis; unsigned long lcdTimeout; boolean doLCDsleepTest = true; uint8_t EEtimeout; int LCDred; int LCDgreen; int LCDblue; //6apr2015 boolean sleepingNew = false; int ii; int EEstepsTemp; int EEstepsOrg; char irDirect = ' '; boolean copyToIrFram = false; boolean copyToTextFram = false; boolean copyToDefinesFram= false; boolean dimIt = false; boolean doTimeOutTest; // if false never turn off LCD boolean linkTest = false; ///////////////////////////////////////////////////////////////////
  6. Like
    abecedarian got a reaction from Fmilburn in 5529 sets an output before setup()   
    It's not an Energia thing, but more an MSP thing, and is relatively common with any MCU.
    Pin state on power up is indeterminate: they may come up in any one of three states- low, high or floating between.
    If you need to have an absolute known state when powering up, consider adding pull up or down resistors to the circuit / pins. These may be relatively high values such as 10-100K ohm or so, so that the pin can override the pull up/down resistor easily.
  7. Like
    abecedarian got a reaction from dubnet in Auto Pond Filler Project, Request for Code Guidance/Help   
    While the liquid level sensor would probably make things relatively easy, it seems like overkill when all you really need to know is when the pond if low and full. So, I wonder if you could use capsense connected to a group of brass electrodes in the pond to detect the pond needing water or being full? When all electrodes detect water, the pond is full, when none detect water it's time to fill? When filling, it can periodically wake up, every 15 seconds maybe, and check if it's filled. Once it's filled, it can wake up once a day to see if it needs water.
    And a tangent or three of sorts- they make toilet floats where the float slides vertically along the overflow tube making for a rather compact configuration, usually less than 5" diameter: here's one at Home Depot. One of these could easily be hidden within some decoration complementing a koi pond, such as a pagoda and pier off to one side of the pool, with a little rock garden on the beach adjacent to it. Also, if the float idea doesn't appeal to you, it might be cool to have the water come down a sluice onto a water wheel next to a pagoda and pier, and the rotating wheel might be able to recoup some electricity for you to power the device / charge a battery. Or, they make little hydroelectric generators that might be usable to get some power from the water supply... or all of the above. Like I said- tangents.
  8. Like
    abecedarian got a reaction from bluehash in Noritake VFD SCK-3900-512X32H-01   
    CN1|GPIO is IRISO IMSA-9023B-14P
    CN2|Serial is JST B7B-XH-A
    CN5|Parallel is IRISO IMSA-9023B-16P
    CN6|Power is JST B5B-XH-A
    - note these are the connectors on the display, not the mating connector.
  9. Like
    abecedarian got a reaction from SteveR in Noritake VFD SCK-3900-512X32H-01   
    CN1|GPIO is IRISO IMSA-9023B-14P
    CN2|Serial is JST B7B-XH-A
    CN5|Parallel is IRISO IMSA-9023B-16P
    CN6|Power is JST B5B-XH-A
    - note these are the connectors on the display, not the mating connector.
  10. Like
    abecedarian got a reaction from Rei Vilo in [Energia Library] RTOS Libraries for MSP432 on Energia MT   
    At risk of coming across as presumptuous, we have "LaunchPad" and "BoosterPack"... so with RTOS support, "Orbital" tickles my fancy.
    I do jest, and do appreciate your efforts.
  11. Like
    abecedarian reacted to Rei Vilo in [Energia Library] RTOS Libraries for MSP432 on Energia MT   
    I've bundled all the libraries in a single package, called Galaxia.
    GitHub repository https://github.com/rei-vilo/GalaxiaLibrary Reference page http://embeddedcomputing.weebly.com/exploring-rtos-with-galaxia.html  
    Why the Galaxia name? With LaunchPad, BoosterPack and Energia, let's stay in space and explore new galaxies!
  12. Like
    abecedarian reacted to KatiePier in Combined PWM with interrupt not interrupting   
    In addition to @@oPossum 's awesome advice, the final point that always confuses people is that each Timer has TWO different ISRs. One (TIMER0_A0_VECTOR) is a special higher priority one just for TA0CCR0, and its interrupt flag is cleared automatically by entering the ISR at all. The other one (TIMER0_A1_VECTOR) is for all of the other TA0CCRx interrupts and TAIE - this is the one that uses TAIV - its highest-priority pending flag is cleared by reading TAIV.
    This code example uses both of them, so you can see: http://dev.ti.com/tirex/#/?link=MSPWare%2FDevices%2FMSP430%2FMSP430G2XX%2FMSP430G2553%2FExamples%2FC%2Fmsp430g2xx3_ta_07.c
    It's a common point that trips people up. 
    If you currently have no ISR defined for TIMER0_A1_VECTOR but have TAIE enabled, if you use CCS for example it defines a trap ISR for all undefined ISRs for just this case (so part doesn't jump off into some random location), so your part is probably hanging out there. 
  13. Like
    abecedarian reacted to L.R.A in New i2c application note for the TM4C1294   
    Amit as written a very good application note for the TM4C1294 i2c, which might I say was really needing it. Not only he made a awesome app note but he also added 5 new examples for the various features of the module and the examples apply small but important techniques that all the current examples miss and that he kept "preaching" on the forum (can you find them?)
    Show some support and give your feedback for improvements as we need more notes like this and to thank Amit for his awesome work:
  14. Like
    abecedarian got a reaction from KatiePier in Concurrently debugging multiple boards   
    If you have one "workspace" for one board, and another "workspace" for the other board, you could start two instances of CCS with one instance tied to one workspace and the other tied to the other.
    Whether this accomplishes your goal, I do not know.
  15. Like
    abecedarian reacted to Lgbeno in New MSP430 Wireless Sensor Node   
    I've wanted to create a batteries included, very low cost wireless sensor kit for quite a long time now.  I've made some attempts in the past but up until this point they were either too expensive to produce and too limited in expandability.  I think that I've finally struck the balance that I'm going to be pleased with.

    The device is a little larger than a single AA battery, that is what it is powered off of.  It has an NCP1400 Boost converter to bump up the voltage to 3.3V.  The processor is MSP430G2553IRHB (32QFN) and it is attached to a HopeRF RF75 radio.  There are 15 GPIO available through a 0.1in female header that is sandwiched between the battery holder and the circuit board.  It plugs into a Launchpad for programming.  Footprints are available to solder on a Si7020 temp sensor, a 32kHz crystal and two LEDs.
    I have the pins_energia ready and now looking at what it takes to make the @@spirilis enrf24 library work with it.  I'll also create my own library with some analog.io tie ins as well as a special surprise.
    My goal is to sell these for $9.99 after I can get them debugged.  Would anyone be interested in one?
  16. Like
    abecedarian got a reaction from anry in Using MSP430FR6989 built-in LCD in Energia   
    @@Rei Vilo
    Link is 404?
    *edit- link has extra characters at the end. Try:
  17. Like
    abecedarian reacted to Druzyek in What are you doing right now..?   
    Porting my RPN Calculator code from MSP430 to LPC1114. Added keystroke programming and a Vfd screen.

  18. Like
    abecedarian reacted to Fmilburn in DIY Rain Gauge   
    I made this sensor a while back as a prototype and put it outside earlier in the year and it still seems to be working OK.  It has been a dry spring and summer here in Seattle though and it really hasn't had much of a workout.  It was my first project with the MSP430G2.

    It is pretty simple.  The funnel catches rain from a known area where it falls into two "buckets" that tip back and forth.  Adjustment screws are used to calibrate the bucket volume.  A hall sensor detects each tip of known volume and sends a signal to the microcontroller which timestamps and stores/transmits the data.  Collected rain falls out the bottom through weep holes once it is measured.
    It was cheap to make, here is a bill of materials:
    Hall sensor - less than $2 Funnel: 1$ for three at the dollar store Magnets: I think I paid a couple of dollars for a tube of them Empty plastic nut container bottom of a coffee can to make the tip bucket mechanism Scrap wood Miscellaneous wire, nut, bolts, and nail I had around I stole shamelessly from this guy and he has a good write-up so I won't repeat that here:  http://www.instructables.com/id/Arduino-Weather-Station-Part3-Rain/
    These device have been around a long time.  When I was an undergraduate engineering student I worked one summer in a lab associated with the university where they needed to digitize rainfall data over a long period from several locales.  This was in the days of mainframes, well before PCs, microcontrollers, and spreadsheets.  The rainfall data was recorded on 24 hour charts that were attached to a clock driven drum and changed out daily.  Each time the bucket tipped on the rainfall gauge it would make a tick on the chart.  My job was to go through years of data (it had been stored on microfiche by the time it got to me), write it down and then later punch cards that were read into the mainframe.  This project was more fun, but I appreciated the money at the time
  19. Like
    abecedarian reacted to Fmilburn in Mailbag   
    This came today - I wanted it more than I needed it but I'm figuring it out and having fun.

  20. Like
    abecedarian reacted to Rei Vilo in Using MSP430FR6989 built-in LCD in Energia   
    I've opened the ticket FR4133 and FR6989: Provide Library for 6-Digit 16-Segment LCD #660 at https://github.com/energia/Energia/issues/660.
  21. Like
    abecedarian reacted to Rei Vilo in Using MSP430FR6989 built-in LCD in Energia   
    I've opened the ticket FR4133 and FR6989: Provide Library for 6-Digit 16-Segment LCD #660 at https://github.com/energia/Energia/issues/660.
  22. Like
    abecedarian reacted to Fred in Geeky Tattoo   
    @@bluehash The NFC implant (in the fleshy bit between my left thumb and forefinger) is fine. It's not given me any problems. I've not got round to doing too much with it yet as I've been busy with other things.
    The most useful thing is to unlock my PC at work. It's just a F5299 acting as a HID device to type in my password and a TRF7970A NFC reader. Currently it's a LaunchPad and booster pack combo but a custom PCB is in progress.
  23. Like
    abecedarian got a reaction from bluehash in Stuck   
    Try keeping track of where the servo is supposed to go when you press the button.
    And using "code" tags is considered good etiquette... that's the button above with "<>" on it.
  24. Like
    abecedarian got a reaction from bluehash in ESI Project: Water Usage Monitoring   
    Still in limbo on the sensors. Seller hasn't shipped them and every contact turns into a "I do you good thing and send extra." thing. Have opened a case with both eBay and PayPal so we'll see. By the way, avoid eBay seller "tinxi-clothes" if you have the option. They're rated 98.8% but these are the people screwing me around for about $3 USD.
  25. Like
    abecedarian reacted to spirilis in Need help with MSP430 Project...   
    I gotcha ... In that case, with GSM (typically uses a serial port IIRC), a device with two USCI_A is mandatory, so ditch the G2553 and consider either the FR[56]xxx series mentioned above or MSP432, with MSP432 being potentially nicer as it has 64KB SRAM (as opposed to, say, the FR5969's 2KB SRAM + 64KB FRAM) and 256KB Flash, plus Energia on that one happens to be based on a real-time operating system so you can run multiple "sketches" in a threaded manner.  Might be handy depending on how complex your firmware gets.  MSP432 has four USCI_A ports (Serial and potentially SPI) and four USCI_B (SPI or I2C) ports so it's well connected.
  • Create New...