NickTompkins 4 Posted June 19, 2014 Share Posted June 19, 2014 Has anyone done anything with the SPI on this launchpad? Perhaps an example? Quote Link to post Share on other sites
NickTompkins 4 Posted June 19, 2014 Author Share Posted June 19, 2014 The Barometric Example isn't working it seems on TM4C129. Quote Link to post Share on other sites
energia 485 Posted June 19, 2014 Share Posted June 19, 2014 Any idea where it gets stuck? Any additional info would help. Quote Link to post Share on other sites
xujianningkp1426459997 0 Posted June 20, 2014 Share Posted June 20, 2014 Any idea where it gets stuck? Any additional info would help. I also tried that example with the SCP1000 Barometric Pressure Sensor on my connected launchpad. The code loaded to the launchpad without any error. It just can't get any data from the sensor. Also, I tried to add the SPI.setModule(0,1,2...), but none of these ports were working. Quote Link to post Share on other sites
bobnova 59 Posted June 20, 2014 Share Posted June 20, 2014 Spent some time playing with SPI. It appears that the documentation picture has SPI #1 MISO and MOSI backwards. I swapped the SO and SI connections on the 4142 digipot I have, and it started working. I have not convinced it to read yet, but I'm not positive I'm going about it correctly for this digipot. I checked the 4142 against an Arduino (known MISO/MOSI pins) and SI is definitely SI. I looked at the TM4C129 datasheet to see if it said which was which, and it's an absolute nightmare. Haven't figured it out yet. Quote Link to post Share on other sites
igor 163 Posted June 20, 2014 Share Posted June 20, 2014 Spent some time playing with SPI. It appears that the documentation picture has SPI #1 MISO and MOSI backwards. I swapped the SO and SI connections on the 4142 digipot I have, and it started working. I have not convinced it to read yet, but I'm not positive I'm going about it correctly for this digipot. I checked the 4142 against an Arduino (known MISO/MOSI pins) and SI is definitely SI. I looked at the TM4C129 datasheet to see if it said which was which, and it's an absolute nightmare. Haven't figured it out yet. I think this was fixed on the most recent copy of the picture, but unfortunately the energia.nu site does not have the most recent versions (it is still back at version 1.0, the MISO/MOSI swap was fixed in version 1.2 I think.) See this thread http://forum.stellarisiti.com/topic/1918-pin-names-connected-launchpad/#entry6925 You might try sending the energia.nu web site maintainers a request to update the diagrams. (I did a while ago, nothing happened so far, but if they get more requests might increase liklihood of action). Quote Link to post Share on other sites
Rei Vilo 695 Posted June 22, 2014 Share Posted June 22, 2014 The updated pins maps fix the MOSI/MISO pins. Look for front, rear and X11 maps version 1.2 at http://embeddedcomputing.weebly.com/connected-launchpad-tiva-c-tm4c129-pins-maps.html Quote Link to post Share on other sites
xujianningkp1426459997 0 Posted June 23, 2014 Share Posted June 23, 2014 The SPI is finally working on the connected launchpad with MOSI/MISO pin swapped. Thank you for the help from all of you. But I haven't figured out the I2C problem yet... Quote Link to post Share on other sites
DrLou 0 Posted June 8, 2017 Share Posted June 8, 2017 I'm encouraged that you guys have gotten this working! But, following guidance here to the letter, I'm still seeing messages below: .../Energia/libraries/rfid/src/MFRC522.h:333:43: error: 'SPISettings' does not name a type .../Energia/libraries/rfid/src/MFRC522.h:333:116: error: ISO C++ forbids declaration of 'spiSettings' with no type [-fpermissive] Have I missed something obvious? Quote Link to post Share on other sites
LiviuM 43 Posted June 8, 2017 Share Posted June 8, 2017 Hi, it seems, the Arduino's SPI library has an SPISettings class and Energia's SPI library not. Some older version of the mfr522 library (version=1.1.8, for example) don't use the SPISettings class and compiles for TivaC. class SPISettings { public: SPISettings(uint32_t clock, uint8_t bitOrder, uint8_t dataMode) { if (__builtin_constant_p(clock)) { init_AlwaysInline(clock, bitOrder, dataMode); } else { init_MightInline(clock, bitOrder, dataMode); } } SPISettings() { init_AlwaysInline(4000000, MSBFIRST, SPI_MODE0); } private: void init_MightInline(uint32_t clock, uint8_t bitOrder, uint8_t dataMode) { init_AlwaysInline(clock, bitOrder, dataMode); } void init_AlwaysInline(uint32_t clock, uint8_t bitOrder, uint8_t dataMode) __attribute__((__always_inline__)) { // Clock settings are defined as follows. Note that this shows SPI2X ... DrLou 1 Quote Link to post Share on other sites
DrLou 0 Posted June 8, 2017 Share Posted June 8, 2017 Well, I've managed to get a little bit further - testing on the MSP-430FR5969, but only get output of: Card detected 100110 , 100000 (repeatedly, in loop) even though there's no card anywhere in proximity! Did this by carefully adhering to pins_energia.h pin mappins for this specific card, in the IDE hardware section. Now, the big question: Even though the IDE recognizes the EK-TM4C129 - I've installed support for it - where is the corresponding pins_header file for this card? The TM4C129 is the ultimate target here anyway. And thanks for your feedback. Quote Link to post Share on other sites
LiviuM 43 Posted June 8, 2017 Share Posted June 8, 2017 On my linux machine, the "extra" boards are installed under /home/liviu/.energia15/packages/energia/hardware/... No idea how it looks under Windows/mac. Quote Link to post Share on other sites
DrLou 0 Posted June 8, 2017 Share Posted June 8, 2017 Found it in /Users/drlou/Library/Energia15 - tks for getting me on track. OK, now the work begins! Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.