Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by bobnova

  1. 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
  2. Any thoughts on the FR6989? It adds LCD and ESI over the 5969 and I have one I'm trying to work with
  3. 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
  4. 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.
  5. 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
  6. 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 totalFirin
  7. 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
  8. That userguide is not my friend.
  9. 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.
  10. 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 a
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. Got mine too. Also a new job. Would like to get started this weekend, we'll see how it goes.
  16. I desperately want to build a laser cutter, so this might end up being something I want too. I'll definitely be keeping an eye on this. Laser etching pcbs would be glorious!
  17. @@abecedarian I've been wondering what to do about that too. So far it hasn't become an issue for me, but I could see it being a problem very easily.
  18. It seemed high to me too, it's on the high end of normal, but within the normal range. Under ~30PSI is frowned on, most systems aim for 40-60. There's some more data here: http://www.cpuc.ca.gov/NR/rdonlyres/A172EAE5-8520-468E-85D8-67E9BA3FC984/0/WaterSupplyRequirements.pdf page 7 gives some example numbers. If the generator is on the nozzle side of the valves rather than the mains side of the valves you're absolutely correct, it'll never see anything close. I was thinking of using it on the mains side of the valves, not sure why.
  19. Using CCS type calls for the second interface might be the easiest, which isn't saying much. You'd be writing a second interface for it parallel to the Energia interface. Best bet might be to modify Energia to use setModule on the lower grade MCUs and the submitting it to the github to see if it makes it in. Bit of a pain in the rear.
  20. Check your water pressure first, it says it's rated for ~79PSI maximum and ~65PSI normal operating. That may be plenty, but my house is in the lowlands and runs 68-73PSI, pretty close to the maximum. Other than that it looks perfect, tons of current, plenty of volts.
  21. I would love to see an energy harvesting smart shoe! That'd be awesome. Even more so with wireless communication. I'll definitely be keeping an eye on this.
  22. Minor update, did some very preliminary work on getting a FRx9x9 (currently, 5969) set up and timers running for pulse width counting / display update intervals / etc. These things are far more complicated internally than the 2553s, that's for sure. It's been a bit of a headache, but I'm making headway. It doesn't help that I've been almost entirely using Energia up to this point. Using CCS-level code inside Energia is all well and good, but Energia still takes care of all the basic setup, so I've had to figure out how to get all that going. I think I've gotten most of it at least. I st
  23. Very very cool. I'm glad to see Energia supporting deeper sleep modes. That was something I was missing. I'd worked around it by repurposing the WDT, sleeping, then setting the WDT back to how it was, but that does bad things to millis and such. Thanks for the features and the heads up!
  24. Cool project. I've been eyeballing water consumption monitoring as a project I want to try sometime, so I'll definitely be watching this! On the electrical side there will probably be enough space and free processing power on the MCU that sits in the electrical box (or on the wiring) with the sensors to chew on the data and spit out either a hall effect style "tick" every X watt/seconds (watt/minutes, watt/hours, whatever your units end up being), or send a packet every X seconds saying that Y watt/whatevers have been used. That would leave the ESI bits on the base station free to deal wit
  25. Well that's awkward. TI's combined datasheet/user guides frustrate me for this reason. I'll check that. Thanks! The MAP sensor is definitely on the list of possibles as well, as you mentioned it's a lovely load indicator, more specific to engine load than the TPS. Honda typically runs the fuel pressure at 38-44 PSI over intake pressure, so I'd need to measure that and find out exactly where it is with regards to intake pressure. After that it's essentially static as far as fuel flow goes. What you're talking about is pretty much exactly my thought process. I know the MPGduino already e
  • Create New...