Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Reputation Activity

  1. Like
    abecedarian reacted to bobnova in Free PCBs for OSHW projects   
    Might want to check out Dangerous Prototype's "Dirty PCBs" too. 8-12 10cm x 10cm PCBs for $25. 8-12 5 x 5 boards is $14.
  2. Like
    abecedarian reacted to bobnova in How fast does this execute?   
    I definitely recommend laying your hands on an oscilloscope of some sort. It doesn't have to be an expensive, "good", one. A $65ish DSO201 handheld thing is fine, or a similarly priced USB scope. It may not be especially accurate, but it'll be decently consistent and that's good enough for a lot of work.
    Another alternative is to buy a used standalone scope, mine came from the university of washington and appears to have last been calibrated in 1977. Despite that, it works great and is surprisingly accurate and precise. It was $35 + $35 of shipping.
    I've never used the sound card method, but I've heard they're not bad at all. I would grab a cheap sound card of some sort to abuse rather than using your motherboard's on board card or an expensive "nice" card, just because it would be unfortunate to blow up something you cared about.
    I've used mine for an incredible variety of things, I can't imagine not having one now.
    (EDIT: On consistent vs accurate in my mind. When I say accurate I am thinking: A 5.0000v signal is read as 5.0000+/- a small amount. When I think consistent I am thinking: A 5.0000v signal is read as 4.8588 (or something else not 5.0000), but it's read that way every single time. Accurate to itself, essentially)
  3. Like
    abecedarian reacted to bluehash in Scan Interface Applications - Five Members Win A Target Board And An MSP-FET   
    Contest time!
    Five winners get a MSP-TS430PZ100($89) target board along with an MSP-FET($115). Five!
    This contest is in partnership with TI. They are looking for ideas and applications that could make use of their Extended Scan Interface(pg 744) or ESI. One of the biggest markets of the MSP430 is flow metering which is where this module is widely used.
    1. Come up with an application using the MSP430FR6989 chip ESI.
    2. Write it down below.
    3. If you win, you implement your idea with your kit and get featured on TI's MSP430 Blog.
    1. You have to have at-least 5 reputation points.
    2. Keep a small project log in the Projects section. This is so that it can be published later on TI's Blog.
    Contest begins August 15th, 2014. Contest ends August 30th, 2014. Winners will be announced first week of September.

    abecedarian -: Water supply usage
    chicken -------: Resistive touchscreen pattern detector
    Fred -----------: Laser cutter coolant and temperature monitor
    greeeg --------: Fitness monitor
    bobnova -------:Digital tachometer, speedometer, and intelligent shift light.
    Automate ------:Single-Point Sensing of Whole-Home Water Activity
    pjkim ------------: Speed Controller
    rampadc, your entry was been withdrawn as per your request. 5 will be selected, 5 get goodies. 1 goes to TI's blog. I'm sure the other's will get special mentions.
  4. Like
    abecedarian got a reaction from bluehash in well this sucks- can't download CCS from TI   
    Problem solved- took ti.com out of IE's 'compatibility list' and it works now.
    Go figure?
    Had to put it in the list so it would work, and now had to take it off the list for it to work.
  5. Like
    abecedarian reacted to spirilis in Hercules engine control   
    Meh, it's a niche chip, I say if you think it's perfect for the job keep pushing... ask E2E forum questions about the Hercules peripherals that seem undocumented...
  6. Like
    abecedarian reacted to igor in How fast does this execute?   
    If you are still interested in ideas about how to measure the speed - if you have access to a computer with a sound input, have you considered connecting the LP output to sound input and using the sound card as an oscilloscope/measurement device?
    You can record and analyze waveforms with something like Audacity, or there are various programs which give an oscilloscope like interface for a sound card.  (Sorry, I haven't used any of them to recommend one in particular.)
    Since your frequencies fall in audible range that seems like a simple way to do it.
    Of course you have to investigate how accurate such devices are, but at least audiophiles care about things like jitter, and accurately reproducing frequencies, so should be able to find specs. to estimate how far off such measurements might be. 
    For a rough measure, hook your launchpad to a speaker and use a synthesizer to play a 5KHz (or whatever tone) and listen for beat frequencies (interference when the two tones are not quite the same).  Like the way a musician tunes an instrument.
    (May have to make the signal pulses wider for this?)
    As far as pulsein - you might consider this library for the Stellaris/Tiva lp
    which uses the timer as a counter.  (I haven't used it yet, or tested the limits, but seems like it should be a lot more capable
    than the built in library).
  7. Like
    abecedarian reacted to chicken in How fast does this execute?   
    Throwing in an idea, not sure whether it's practical, but here you go.
    Build a jig that runs at the speed (rpm) you target (DC motor?). Use a sensor to detect when it completes one rotation (hall effect, light barrier?). Fix an LED to it and turn it on/off at the start/end of your loop, or when the MCU is supposed to do control something. Basically a persistence of vision setup.
    You will be able to see how much of the time budget your code uses, jitter and other parameters by looking at the LED trace (how much of the circle is it on? does it stay put or wiggle around?). It will also help to simulate other aspects of your motor control, e.g. synchronization with rotation.
  8. Like
    abecedarian reacted to veryalive in How fast does this execute?   
    good to know about pulseIn    !
    i didn't use it at that narrow a pulse width (200 uS)
       glad to hear that you checked the source code as a bonus
    ---->>   as an alternative,  perhaps the Energia   'microcseconds' function   micros(),   with a call at the rising edge, a second call at the falling edge, then a subtraction.
  9. Like
    abecedarian reacted to David Bender in How fast does this execute?   
    This sure is a rapid prototype, but the signal he's trying to measure goes down to about 200us in period.
    So using pulseIn is going to have wildly inaccurate results at his top end.
    Looking at the source code for pulseIn almost made me vomit.
    Ignores this thing called TimerA, susceptible to interrupts, etc.
    pulseIn may be OK for measuring human reaction time, but certainly nothing faster.
  10. Like
    abecedarian reacted to veryalive in How fast does this execute?   
    .... i'll throw my hat into the ring here ....
    if the question still is     :    'how fast does this execute' 
         ------>  and additionally:
          - you'd like it to be easy to set up
          - you have an additional Launchpad and serial port (or spare LCD) available
          - you are satisfied with +- 10 / 20 uSec resolutions
          - you don't want / need a scope or logic analyzer
    then, in the spirit of 'rapid prototyping', here's an idea.
    please note I haven't done this, but i've used these energia routines myself.
    I use Energia and a bunch of handy, jumperized, IO devices for quickie measurement projects.
    your existing LP#1 is your 'simulator', already described.     The LP#2 just measures and displays a pulse width.
    LAUNCHPAD#1          -------> PULSE OUT PER LOOP  --->     LAUNCHPAD#2
    TO BE TIMED                    (2 wires)                   MEASURING  ----> DISPLAY
    (SW added to toggle a pin                                  THE PULSE        (SERIAL or LCD)
    a pulse at top of loop)
    - for the loop timing to be measured (ie: how fast does this execute)  LP#1 has a spare IO bit set for output which
    toggles at the top of the loop (XOR). The resulting high pulse is wired over to LP#2 to be measured and displayed by a
    quick-'n-dirty Energia script.
    LP#1     - you know how to do this.    and you've wired 1 output bit + ground to LP#2 input bit of your choice.
    LP#2     - i think you've worked with Energia. Key is the pulseIn() function.  So here's some example code:
    int pin = 7;
    unsigned long duration;
    void setup()
      pinMode(pin, INPUT);
    void loop()
      duration = pulseIn(pin, HIGH);
    -------------------------------->    then display 'duration' to the device of your choice
  11. Like
    abecedarian reacted to bobnova in How fast does this execute?   
    If my reading of datasheets and energia device files is correct you can solder the optional 32.something kHz crystal onto the launchpad and use that as a clock source for one of the timers to use with PWM. At that point you could have anything down to a 0.5Hz PWM output, I think. Maybe even less if you feed it through a /8 divider first.
    Low speed PWM shouldn't be an issue.
    I'm not especially well versed in this business yet, so I may be way off base.
  12. Like
    abecedarian reacted to David Bender in How fast does this execute?   
    OK so far so good. (The following may be obvious but I think I'm learning something here...)
    As you keep specifying your simulation requirements in frequency, I am assuming you want a UNIFORM frequency resolution.
    I may be wrong, but you in general cannot linearly specify frequency, only period (there is 1 exception)*.
    Frequency changes asymptotically WRT to period, so you end up with a linear region only a fraction of your whole range.
    Higher frequencies will have much less resolution than lower frequencies.
    So for the crank, 107Hz is approximately 10000us and 6000Hz is approximately 166us.
    A PWM peripheral running at 1 MHz would have a TACCR0 at 10000 at the slowest, and 166 at the fastest (36Hz worst res).
    A PWM peripheral running at 4 MHz would have a TACCR0 at 40000 at the slowest, and 666 at the fastest (2Hz worst res).
    (note these are off by 1, since TA0R starts at 0)
    The exception is you can linearly control the DCO, which is basically a linear (5) bit mixer between two frequencies, giving you an extra 1/32 resolution.
    VCC will also affect your effective frequency, so make sure it does not change.
    If you use a synchronous protocol like SPI or I2C, you could turn one of your G2553s into a slave square wave generator with fairly precise control (UART would not work since it is clock dependent).
  13. Like
    abecedarian got a reaction from David Bender in How fast does this execute?   
    900ms sounds a bit shy of the target I'm hoping for.
    Re-reading things here, allow me to apologize for the confusion, and maybe rephrase / restate the intentions. I got a little ahead of myself.
    Goal(s)- simulate various sensors as would be installed on the engine including manifold pressure and temperature, coolant temperature, throttle position and the (a) crankshaft and ( camshaft trigger signals. Analog sensors like temp and pressure can probably be done with linear pots; I'm fine with that. The crankshaft signals will come at a rate of 32 pulses per crankshaft revolution, with approximately 50% duty, as far as I can tell. Crank trigger setup-

    *note I am only going to use one of the two VR sensors- this is a modified stock CX/GL pickup setup, but I'm trying to avoid modifying anything mechanical on this or similar bikes if possible.
    The camshaft is similar, but with only a single tooth and two pickups, again of which I'm only using one.
    The 11.25 number came about because 360 degrees divided across 32 teeth is 11.25 degrees from tooth to tooth. That was my mistake for including that since the ECU will be responsible for decoding and calculating when things should fire. I'll delve into what I think should happen there, if anyone is interested.
    So back on topic: it seems that to simulate 200 RPM, I'd need to generate (200/60*32) pulses per second, or ~107 Hz, for the crank, and ~3 Hz for the cam; sounds more realistic. At 11000 RPM, that's ~5867 & 184 PPS for crank and cam, respectively. Using PWM for the signal seems logical in retrospect since they are continuous, repetitive signals, but isn't around 250Hz the lower end of what's possible? Actually, 200 RPM is probably low even, and I could probably get away with 500- but I'm trying to account for worse-case possible engine start speeds... and 200 RPM is probably a dead battery anyways so....
    Crankshaft trigger duty cycle will not change and it's likely 50% will work fine- ~1mm wide tooth face & ~1mm wide valley between teeth. I'll have to figure out what the cam should be since it has a similar tooth profile to the crank sensor, but has only one tooth and rotates 1/2 crank speed... maybe turn on with one crank tooth then turn off with the next. I also still have to determine the cam sensor's absolute placement / relation with regards to the teeth on the crank sensor, as in does it exactly coincide with a tip or valley on the crank sensor, or somewhere in between (mostly relevant to the ECU's operation, not this).
    To add, I've no issue dedicating a Stellaris or Tiva Launchpad for this if either is more appropriate.
    I'm babbling, yet again.
  14. Like
    abecedarian reacted to oPossum in State of I2C in MSP430 based devices. (MSP430F5529)   
    2.2k is a reasonable value for 3.3V IIC. Both SDA and SCL require resistors because they are both open drain (pulled low only). The SCL line is open drain to allow a slave to do clock stretching - a rarely used feature.
  15. Like
    abecedarian reacted to bobnova in How fast does this execute?   
    As a note, I've found that generally "if" is an expensive thing to say if (heh) you're looking at time consumption.
    Same for "for". Haven't checked "while", but it probably is too.
    How expensive it is depends on the chip and the variables you're comparing of course. If you're comparing bytes on a 16bit chip that ought to be faster than comparing longs on said 16bit chip, but may not be on a 32bit chip.
    That said, writing code that doesn't say "if" is a good trick.
    Oh and I tested the code (modified to work on a launchpad without extra stuff attached) on a scope, and got ~900ms/loop also.
  16. Like
    abecedarian reacted to David Bender in How fast does this execute?   
    If you want to see how fast the loop is going then refer to the UART DCO Calibrator timer interrupt; it is recording the time between pulses. If you run at 16MHz, those pulses will be DCO clock counts. If you output those pulses to the UART (at 115200 you should be able to keep up) then you'll know the period between pulses.
    As for the other stuff I apologize I still lost about whether you are generating crank/cam pulses or cylinder firing (code seems to be cylinder but your explanation was about crank/cam?) I don't understand why you chose your units to be degrees when you are counting gear tooth pulses, why not base everying on gear teeth?
  17. Like
    abecedarian reacted to simpleavr in How fast does this execute?   
    Ultimately you will want to go direct 'c' (ccs / gcc) to get accurate timing. You cannot rely on your loop w/ Energia. It has this built-in timer WDT interrupt that would throw your own counting off.
    The current code is not working as (1) you need to also multiply 100 to your t2 value (orginal 440), but then in the loop it will never reach 44000 as your angle value / degree is incrementing by 1125. I changed it to the closest value of 43875.
    I make use of the Energia function "micros()" to see how long it takes for a 720 degree loop. The code changes are as follows;
    I had changed some of the led pins as I run it on a bare LP, but timing should not be affected.
    const uint16_t t1 = 0;  //  right cylinder baseline spark //const uint16_t t2 = 440; // left cylinder baseline spark relative right cylinder //const uint16_t t2 = 44000; // also no good, not divisible by 1125 const uint16_t t2 = 43875; // this is the closest  const uint8_t cam = 0; // camshaft trigger relative right cylinder TDC const uint8_t AMBER_LED = 5;  // LP pin indicating camshaft trigger signal occurrence // I am using existing RED_LED, GREEN_LED for right and left cylinder TDC indicators uint32_t degree = 0; // counter for crankshaft rotation in degrees void setup() {   pinMode(RED_LED, OUTPUT);   pinMode(GREEN_LED,OUTPUT);   pinMode(AMBER_LED, OUTPUT); } void loop() {     digitalWrite(GREEN_LED, 0);   uint32_t elapsed = micros();   while (1) {   for (degree = 0; degree < 72000; degree+= 1125)  { // 11.25 = spacing between tooth centers on a 32 tooth wheel // changed to 1125 to get rid of decimals and work without floats // Camshaft:     digitalWrite(AMBER_LED,degree == cam); // Right cylinder:     digitalWrite(RED_LED, degree == t1); // Left cylinder:     digitalWrite(AMBER_LED, degree == t2);   }   //if ((micros() - elapsed) < 1120) {   // my test show that the "loop" spend 1120 micro sec.. i.e. max is 892Hz.   // for elapsed between the cylinders, it would be about 440/720*1120 or about 1.46khz   if ((micros() - elapsed) < 200) {       // elapsed time less then 0.002 sec, i.e faster than 5khz for a 720 degree complete loop, which did not happen     digitalWrite(GREEN_LED, 1);   }//if   }//for } The finding is that for a full loop (? your engine cycle?) it takes 1120 uSecs to run. That would make it 892Hz.
    I think a lot of cycles are wasted by setting the various LEDs off when it is not necessary to do so. We could just reset them in a outer loop and turn them on only when triggered (although you may need to a some delays for your pulse width requirement, etc).
    void loop() {     digitalWrite(GREEN_LED, 0);     digitalWrite(AMBER_LED, 0);  // set all leds off     digitalWrite(RED_LED, 0);   uint32_t elapsed = micros();   while (1) {   for (degree = 0; degree < 72000; degree+= 1125)  { // 11.25 = spacing between tooth centers on a 32 tooth wheel // changed to 1125 to get rid of decimals and work without floats // Camshaft: if (degree == cam) {     digitalWrite(AMBER_LED,1); // pulse when value equals, do nothing otherwise     digitalWrite(AMBER_LED,0); // pulse when value equals, do nothing otherwise } // Right cylinder: if (degree == t1) {     digitalWrite(RED_LED, 1);     digitalWrite(RED_LED, 0); } // Left cylinder: if (degree == t2) {     digitalWrite(AMBER_LED, 1);     digitalWrite(AMBER_LED, 0); }   }   //if ((micros() - elapsed) < 200) {       // elapsed time less then 0.002 sec, i.e faster than 5khz for a 720 degree complete loop, which did not happen   if ((micros() - elapsed) < 225) {  // max = 4.444khz     digitalWrite(GREEN_LED, 1);   }//if   }//for } So this ends up just shy of 5Khz. If 5Khz is all you need, you can try change the logic into a sequence machine so that you do need to test all three time values all the time.   I.e. (not tested)   int elapsed = micros(); while (1) { righ_spark_pulse(); while ((micros()-elapsed) <= 440*FACTOR) __asm("nop"); left_spark_pulse(); while ((micros()-elapsed) <= 720*FACTOR) __asm("nop"); // done }//while 1 engine cycle      
  18. Like
    abecedarian reacted to rockets4kids in How fast does this execute?   
    The *simplest* way to do this is to just put your scope on the output and measure the signals.
  19. Like
    abecedarian reacted to oPossum in How fast does this execute?   
    Those old 8 bit ECUs have support chips that help with all the timing critical stuff. With a G2553 you have a faster CPU, but only wo very basic timers. Each can only do two full featured compare outputs, so your need for three outputs is just beyond what it can easily do. The F5529 has a timer A with five outputs, and a timer B with 7 outputs, so it is much better able to do what you need.
  20. Like
    abecedarian reacted to David Bender in How fast does this execute?   
    Oh OK, I didn't realize this was a simulator (duh, you said so). I see what you are doing now; the important thing is to have these impulses at the proper phase from each other.
    Since you have a bunch of G2553 chips, devote one to just the simulated crankshaft.
    The reason being is you should simulate the "speed" of your crankshaft by changing the speed of the DCO.
    You can scale the DCO speed/up down, refer to  https://github.com/analog10/UART_DCO_Calibrator
    As long as your signals are in the proper phase for 1 frequency, this should work for all frequencies
  21. Like
    abecedarian reacted to zeke in Airdog Airleash - How does this even work?   
    Now that sounds like a story filled with intrigue.
    Care to enlighten us about those 'certain' compasses?
  22. Like
    abecedarian reacted to enl in Well... crap.   
    Only one I have is doing something right now (display is on temp/humidity monitor... cat is on lightning bug) or I would offer. Unfortunately, gravity happens.
  23. Like
    abecedarian reacted to jpnorair in Well... crap.   
    Good luck with that!
    Vodka sounds like a better plan.  Na zdorovya.
  24. Like
    abecedarian got a reaction from tripwire in Airdog Airleash - How does this even work?   
    I've used 'certain' compasses on transmission line towers to orient cell site antennae without issues- never more than 2 degrees off, relative true North.
  25. Like
    abecedarian reacted to bobnova in Energia COM port help   
    I've found that I have COM port issues if I have the serial monitor open when I plug a launchpad in.
    That's guaranteed failure, like the above.
    The solution for me is to unplug the launchpad, close the serial monitor, and re-plug the launchpad.
    That's the only similar thing I've run into.
  • Create New...