Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won

  1. Simultaneous SPI and SPI1

    Simultaneous SPI and SPI1 works! I've an SD card on SPI and a ADC breakout board on SPI1. I've a small code to stream data from the ADC to the SD card and all looks good.
  2. Simultaneous SPI and SPI1

    Thanks for the patch. SPI1 now works standalone. I'll try simultaneously SPI and SPI1 next.
  3. Simultaneous SPI and SPI1

    Thanks for the patch. SPI1 now works standalone. I'll try simultaneously SPI and SPI1 next.
  4. Simultaneous SPI and SPI1

    Just a quick thought to fix the SPI1 issue, maybe in SPI.begin something like if spiModule==0 params.transferCallbackFxn = spiTransferCallback0; else params.transferCallbackFxn = spiTransferCallback1; and then just have two transfer callback functions. .I hate having to modify the core libraries, but I could see something like this working.
  5. Simultaneous SPI and SPI1

    I'm trying to get access to the second SPI bus/module in order to use both bus 0 and 1 at the same time on a MSP432 (Energia 18 / Code Composer) and ran into an issue with the best way to achieve this. Just to give a little background, I've got an SD card on bus 0 (Mode 0 SPI) and I'd like to put a ADC breakout on bus 1 (Mode 1 SPI) such that I don't need to worry the SD card clogging up the SPI lines when the 512 byte buffer gets written. I am able to use: SPI.setModule(1) to get access to the second SPI bus just fine...Should I be putting a set module command before the chunks of code which talk to SD or ADC drivers? This didn't seem very elegant, but I think it might work. Something like: loop { SPI.setModule(0) Write to SD Card SPI.setModule(1) Get ADC conversion } What I was hoping to do is use "SPI." (set to use bus 0) for the SD card libraries and "SPI1.*" (set to use bus 1) for the ADC libraries, however, SPI1 doesn't work. What seems to be the problem with SPI1 is the following code in SPI.cpp: /* C type function */ void spiTransferCallback(SPI_Handle spi, SPI_Transaction * transaction) { SPI.transferComplete = 1; } Note how this code refers to "SPI.*" regardless of whether I'm using SPI.* or SPI1.* What seems to be needed is some logic that executes SPI.transferComplete if the module is 0 and SPI1.transferComplete if the module is 1. I tried changing this code to run SPI1.transferComplete, then atleast the SPI1.* stuff works...although I'm guessing SPI.* won't work at this point. Is there a way to get this callback access to the value of spiModule? any advice would be appreciated, jrd PS I'll also note that I'm using the original energia libraries (black), but the new boards (red).
  6. MSP432 ADC14 Clock

    So I think I understand the SD problem. I amusing a non-ti-rtos way of accessing my SD card. My guess would be that the more ti-rtos-centric way of implementing things in the msp432 emt red libraries is conflicting with my non-ti-rtos sd card library. I was able to successfully install/compile the ti-rtos/fatsd example, so I know it's not a ccs/board/wiring/etc. issue. However, it's not entirely clear which direction I should head now. Should I try and get the fatsd example working under energia?, or does someone have an energia ti-rtos SD library already working with the msp432 emt red stuff?
  7. MSP432 ADC14 Clock

    And another issue, my SD card is no longer able to be initialized. I created a new MSP432 sketch (not a red mspp one), copied my code over and the SD card initializes fine.
  8. MSP432 ADC14 Clock

    One thing I'll mention though, is that the level of noise I'm seeing looks to be about double of what it was before. That is, for a "constant" voltage, I was seeing about 20 ADC units of RMS noise, while now I'm seeing 40 for my particular circuit with no other wiring/setup changes.
  9. MSP432 ADC14 Clock

    OK, I went through all the steps and it still didn't work. The "wiring_analog.c" error is gone, but now its complaining about the random functions. I undid your step 2 (uncommented them again)....and now it seems ok.
  10. MSP432 ADC14 Clock

    Yup, already found the ADC resolution stuff and have set it up as 14 bit. Is there any sort of guide anywhere on transitioning from the msp432 to msp432r emt red libraries? (in particular, I'm using CCSv71 on a Win10 machine) I've spent about 3-4 hours already trying to get my code to compile using the red version and haven't gotten anywhere. I've re-installed energia, re-installed the boards, wiped our my ccs workspace, etc. and am now upgrading to CCSv7.2. With everything cleaned out and new (except CCS 7.2), when I go to create a new energia sketch, it immediately tells me "wiring_analog.c already exists"...Then, if I make a simple wifi-enabled sketch (even an empty sketch won't compile), it won't compile. It brings in the _core and _WiFi libraries, but neither compile. Both give various errors relating to not being able to find SPI. If I build the _core and _WiFi libraries standalone (not through my sketch, but by themselves), they do compile. However, if I then try and build my simple sketch, CCS tries to re-build _core and _WiFi then they no longer compile. I assume something is wonky with my CCS, hence my current attempt at upgrading CCS.
  11. MSP432 ADC14 Clock

    Yeah, sorry for being a little vague, I was trying not to be too specific because I'm still not exactly clear as to where my problems lie. I'm designing some IOT-based sensors for water level/waves. We've tested the pressure sensor and it's associated electronics and it seems to be functioning correctly. The pressure sensor itself is supposedly 0.05% accurate (which we can confirm by using a volt meter directly), but our calibrations (based on the ADC results out of the MSP432) are coming in at 2-3% accurate. The ADC "oddness" I've seen...some of which I've figured out answers to (e.g. blown boards) and some not...has manifested itself in a variety of ways: 0) ADC values which differ based on ADC clock used 1) Hysteresis of ADC results. ADC/Volts for increasing voltages (calibration of a pressure sensor) don't equal ADC/Volts for decreasing voltages 2) Bi-modal gaussian-looking distributions ADC values for a "constant" voltage..so a mean I calculate ends up being a value that isn't measured often. 3) For a "constant" voltage, distribution of ADC values which look Gausian, however, some ADC values within that shape are never recorded. For example, say I have a mean value of 1000. Then if I analyze a histogram of ADC values, I'd see something like: 2-996 values, 5,-997 values, 13-998 values, no-999, values, 200-1000 values, etc. 4) For a "constant" voltage, ADC means varying over time (tens of seconds to minutes) for a "constant" voltage 5) Peculiar oscillations of values. For example,for a specific "constant" voltage input, some (but not all) of the values go back and forth between 1650 and 1677. 1650 = b0110 0111 0010 1677 = b0110 1000 1101 what's weird is that the last 8-bits are exactly the opposite. I also have other combinations of numbers which seem to have their bits be exactly opposite. Maybe this is just a quirk, but it seemed strange. 6) ADC values which bounce back and forth between two values...with almost no values in-between recorded...so it kind of looks like a digital signal. I'm using external voltage references and I'm pretty sure I've blown out a few boards because of that. Some of blown boards which I can explain (taking samples with internal Vref configured but with external connected) and some I cannot. For example, my Verefs now are drawing 30 ma and I know that's wrong, but I'm definately setting up my analogRead's using external references by default now. So some of these issues kind of feel like I've blown out some bits on my ADC and some kind of feel like ADC clock/sample timing issues...hence when I was delving into the code to figure out how that stuff works at a low level. (I know I have more to learn in that regard and I'm by no means sure that my wiring, analog/sample filtering, grounding, etc. are completely correct yet so take this all with a grain of salt...) I started with the black, but pretty much am only using the red now....and you pointed out a good issue, I am using the MSP432 stuff, not MSP432 EMT RED. I don't think I ever noticed there were two different ones in the board manager. I know the board manager is new, I forget what I was doing for v17. I'll get that switched over ASAP and let you know if that helps. I've had some other kind of weird errors pop up every now then...maybe this will help with those issues too
  12. MSP432 ADC14 Clock

    I'm trying to figuring out some oddness in the ADC conversions of my MSP432 Launchpad and I ran into something I don't quite understand. In Energina18 wiring_analog.c initializes ADC14 on the MSP432 with the following driverlib command: MAP_ADC14_initModule(ADC_CLOCKSOURCE_MCLK, ADC_PREDIVIDER_1, ADC_DIVIDER_1, 0); As expected, CS_getMCLK() is reporting that MCLK is running at 48 MHZ. So the clock being provided to the ADC14 is 48/1/1 or 48 MHz. However, my reading of the ADC14 datasheet/documentation states that ADC14 clock source is limited to 25 MHz (which, in theory, will give 1 Msps).. To see if this clock source was causing my original "oddness", I tried the following combinations of clocks and dividers: ADCOSC/1/1, MCLK/1/1, MCLK/1/2, MCLK/1/4, and MCLK/1/8. For a "constant" voltage to be converted, ADCOSC/1/1 (25 Mhz, I believe), MCLK/1/2 (24 MHz), MCLK/1/4 (12 MHz)and MCLK/1/8 (6 MHz) gave basically the same ADC value...while MCLK/1/1 gave something about 7.5% higher. Anyone run into this before? It seems like the clock might need to be divided by atleast 2...but maybe I'm missing something... jrd PS I'll also note that if I look at the examples in the ADC14 msp432 driverlib (3_21_00_05), five use MCLK/1/1 and two use MCLK/1/4.
  13. driverlib crc32 problem

    Discovered a bug in my code, so for completeness, below are the updating timing numbers: 9 byte string 9 byte array 64 byte structure pyCrc 13us 13us 57us** driverlib software Crc* 11us 10us 49us rom Crc 15us 15us 79us *driverlib software includes a 1us delay to ensure enough time to process results. ** this is the value which was wrong in previous post....pyCyc isn't twice the speed of the driverlib version. they are actually comparable.
  14. driverlib crc32 problem

    OK, I think I get it now. I new the rom_map.h header selected the hardware or software version, but I really didn't look into what it was doing. I was assuming it determined whether or not my rom could support it. Turns out, one must include the rom header before the rom_map header. If I do that (or replace MAP_ with ROM_), I don't need any delays to get it to work correctly....So I think Clavier is spot on. The flip side is that the rom version is significantly slower than the software versions. So I guess the price one is paying for a reduced code size, is speed? I guess I get that. 9/10 bytes 66 bytes pyCrc 13us 13us driverlib software Crc 11us 27us rom Crc 16us 74us