bobnova

Thread is a little old I realize, but the current library works great on Tiva/Stellaris boards. I've used it on the following launchpads: 2553 5969 Stellaris Tiva-C 123 Tiva-C 129. You have to change the pin assignments to match the launchpad pins and play some games with where the SPI library resides on your computer, but other than that it works great. Right now I have it communicating with an Arduino running the RF24 (http://tmrh20.github.io/RF24/) library. The two libraries use reversed orders for addresses and have very different default settings for the radio, but work once you get those straightened out.

Any thoughts on the FR6989? It adds LCD and ESI over the 5969 and I have one I'm trying to work with

I wasn't able to get a NRF24 working with a MSP430G2452, let alone a 2231. Not really sure what the 2452's problem was, easiest guess is RAM of course, as I don't know how much the library consumes. I did a quick count and it seemed like enough, and went through the library a bit looking for references to HW at the 2452 doesn't have, but never really found much. Doesn't surprise me much that it won't fit a 2231, those things are tiny as I recall. As a note, when the library says that the NRF24 is in low power mode it really means it. I have one outside right now running off a AA Power Board from Jeelabs (boosts >0.9v to 3.3v), connected to a 2553. It checks temp and light and battery level then sends out a packet containing that plus a count plus an ID number every ten seconds and sleeps the rest of the time. I hacked things up a bit to allow LPM3 in energia and set a timer running to wake it back up every ten seconds. I put it outside in a plastic bag (rainy season) with an alkaline AA I found lying around that had ~1.32v unloaded. After about eight weeks or so (more?) it's still running and the battery has gone down by about 30mV according to the node. Very happy with the library am I.

Must be the touchscreen inductance or the transistor switching itself then. I'm surprised more of it wasn't breadboard related. Those spikes look much more reasonable though, glad it helped.

Breadboard/long wire related inductance is the majority of it I'd guess. You get some of that just from the transistor(s) itself too. A very small cap between the blue trace and VCC or GND (doesn't matter as long as they're both clean. I'd probably use GND) will eat a lot of that spike without slowing the rise/fall times too much. My experience has been that even 10nF is enough to damp down spikes like those if there is some resistance in series with the incoming voltage (there is in this case, inside the touchscreen). That may even be too much, it's worth playing with. You mileage may vary of course. It's hard to say how long the spikes last on that scope setting.\ If they're the sub-microsecond-duration sort I'm thinking of they are very easy to kill with small caps. The longer they last the harder they are to kill.

It's all good. Hard to get tone/mannerisms in text so I try to assume the least offensive interpretation is true. What I'm planning on doing is having a (big) variable with the total ms (or maybe tenths of a ms) of fuel injected into one cylinder, so each time the injector fires the firing time is counted (if I can get a sensitive enough scope in there to measure how long it takes to open, I'll subtract that from the open time) and added to that running variable. A probably-won't-compile-and-definitely-won't-work semi-pseudocode/semi-energia/semi-ccs example: unsigned long totalFiringTime; unsigned char thisFiringTime; boolean injectorFired = false; while(1){ thisFiringTime = 0; // It's being zero'd constantly so that it'll be zero when the injector fires. while(injector == firing){ // delayMicroseconds(100); // wait 100 microseconds. thisFiringTime++; // mark off that 100microseconds. } totalFiringTime += thisFiringTime; } It'll need Awesome Features like a way to report the collected data and track/report other things too of course, but that's the basic idea. So at 800RPM for a minute with a 2ms injector pulse it'll report ~800ms of fuel injected, while a minute of 5000rpm and 2ms injector pulses will report 5000ms of fuel. (One pulse every other RPM in this theoretical motor. Real world may well be different, but it'll be the same across all four cylinders at a given moment of time so that's OK I think). What units I use will depend on testing. I just ran some numbers through calc.exe and it looks like if I assume my civic has 240cc/min injectors (I think it's somewhere around there) a full tank of fuel is ~189 minutes or 11356 seconds. Given that I have four injectors running but am only tracking one, it'd take ~2839 seconds to empty my fuel tank. If I pretend an unsigned long is 4 billion exactly that suggests that I should use a unit of 0.00000070975 seconds for best accuracy, or ~701ns. That seems overly exact, I could see going for microsecond accuracy, should be easy enough to feed the ESI timer a 1MHz clock to count with. That'd give me enough exactitude to take the injector opening time out without mucking with the fuel pulse too much. Using microsecond accuracy justifies the ESI though, so that's nice! It's all lovely and theoretical still of course. I haven't had time and the required brainpower available to actually muck with it since the failed attempt at UART functionality. Loving the new job, but having spent much of the day figuring things out makes it harder to get into the swing of it at home! The more I think about this theoretical project the more I want to have it though.

To be fair, the information is all there, but the organization confuses the hell out of me and the examples are pretty much all in assembly. Thank you, by the way, for de-mystifying the ESI state table. I've managed to mostly wrap my head around how that table works at least. Assuming of course that you're right about it and not just lucky. On the plus side for me even if it was luck, I'm more likely to be using quadrature than 3 sensor LC

That userguide is not my friend.

That makes sense. Probably worth testing to make sure you can get 0 and 1023. It can be trickier than you'd think, the difference between 0 and 1 at the 3.6v the launchpads typically run at is only 0.0035 volts. I noticed the OR largely because I've been in that trap in almost exactly that situation and driven myself nuts trying to work out what was wrong. It can be very helpful to take out a calculator and notepad and manually test a program. Takes a bit, but it turns things like that up.

if(value >= (oldValue-sensitivity) || value <= (oldValue+sensitivity)) This will always return true. This method will do what you want if you switch things around a little bit. You want to check to see if the new number is less than X - sensitivity or more than X + sensitivity, and if it is then you run your code. If it isn't then you return false as the number is still within the sensitivity range. [code]if(value <= (oldValue-sensitivity) || value >= (oldValue+sensitivity)){ doStuff(); return true; } else{ return false; } Just as an example. Please do note that the above has not actually been compiled/run. Or do what abec. suggested, the end result is the same. I'm not sure you need to check for 0 and 1023 specifically. If the last read was 1023 and the next read is also 1023 that will fall within the sensitivity range and be ignored. Maybe I'm missing something there. If you have time, do a few more samples with a bit of time between them. If I can I like to sample decently often over a ~17ms time period to get rid of the 60Hz background EMI. A running average can be a nice tool for this sort of thing too. Take value and add the last-read value then divide by 2. Very low memory usage, with decent long term averaging. A small cap between the ADC input pin and GND or VCC can go a long way too, especially if it's a high resistance slow changing (relatively) input.

Even less time! Amazing! Did figure out exactly what I want to do with the ESI bits though. I'm thinking that their ability to start/stop a timer to measure a pulse width is going to be used to collect ON time of a fuel injector. For the early going I'll just measure fuel in seconds of flow per distance, or seconds of flow per trip. It won't be something that can be converted to MPG, but it'll be easy to see the difference driving style/etc. makes. Having the ESI do the timer running means not having to use CPU cycles to do it but still getting a good solid time on it, which I like. Spent some time trying to get the UART transmitting for debuging. Didn't manage to. I need to pry the setup out of the Energia FR5969 setup bits and try that.

No spam seen here. Maybe yahoo is filtering it or something. Or gmail, or whatever I used for that. I think the drawing was going to be on the 9th or so.

Haven't had a ton of time, but I did have a chance to open up the TI packages last week, and had some time to sit down with the dev board and programmer today. I like both of them. LED on P1_0 is happily blinking away, energy trace is still awesome.

If you have the time/energy for it your best bet is probably to set up a timer to do your timing for you. At that point you'll know exactly what its operating parameters are and it won't throw as many surprises at you as delayMicroseconds() and micros() will.

Got mine too. Also a new job. Would like to get started this weekend, we'll see how it goes.