Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Reputation Activity

  1. Like
    tripwire reacted to GeorgeIoak in "#112-D statement is unreachable" warning   
    I figured out that the compiler warnings are happening because once you enter the while(1) loop you'll be stuck in it and can never reach the statements outside of the loop.
    The other "error" I received this response over on the TI e2e forums:
  2. Like
    tripwire reacted to chicken in How to protect your free code from companies predating on it ?   
    Not sure if the controversy on Stack Exchange is comparable. There the main cause of conflict seems to be practicability of attribution and other license terms in the context of an educational resource (e.g. exemplary code snippets). As one of the commenters put it: Would you use a foreign language phrase book when it would require attribution? ("Wie komme ich zum Bahnhof? Source: Chicken's Pocket Phrasebook, distribution of this phrase must include the license terms, which are ....")
    Publishing a complete library under a license and expecting people that use the library to comply with its terms seems more practical. Though even that can become unwieldy for large projects that draw from multiple sources with often conflicting terms.
    IMHO many open source licenses are becoming as relevant (and questionable) as the despised EULA.
  3. Like
    tripwire reacted to RobG in SensorTag, practical use   
    SensorTag can be used not only for development
    I had to find the exact location when fixing problem with my subfloor, so I attached small magnet under the floor and used ST to locate it.

  4. Like
    tripwire reacted to Fred in 43oh wins TI Community Highlight Award   
    Too shy to tell us yourself, @@bluehash? Well, I'll have to do it then!
    It looks like 43oh has won TI's Community Highlight Award. Definitely well deserved. This place has always been a great source of help and inspiration. Probably the reason why I use TI stuff rather than anyone else's.
    Well done.
  5. Like
    tripwire reacted to enl in Very accurate timer   
    This device will not directly drive a high freq crystal, but there are a number of options as an external source can be used for internal timing:
    a) Use an external oscillator or clock generator module. Benefit: a programmable module will give you exactly the frequency you want (within error limit) Drawback: additional components
    calibrate the SCO to the 32KHz crystal. This will remain stable for a reasonable time, and the recalibration can be done periodically if needed. The DCO is rated at about 6% over the operating range of the device, but is quite stable over moderate term as long as temp and power supply are also fairly stable. In many cases, the calibration is more than stable enough for long term use.
    c) Use the 32KHz clock for the beat timing, and use the DCO for serial, deriving the serial parameters by comparison against the crystal.
    d) if you can count on the other device to talk first, use the crystal for beat timing, use the DCO for serial timing, and sync the serial to the other devices bitrate. This only works if you know you can count on the timing from the other end and you can force the other device to transmit first. I don't recall if the 2553 supports this in hardware, but it is pretty easy to set up in software.
    Of these, I would probably use © as a low cost, easy choice. The serial clock can be tuned quite tightly (fraction of a clock cycle), and the calibration is pretty straightforward in software. I think one or another of the application notes deals with this, but if not, and you need a hand on this, many people here can outline methods.
    That said, I have used the factory calibration values for the DCO with good success for serial timing. 8-bit serial needs stability of approx 3% to avoid losing bit frame registration (3% in opposing directions at opposite ends of a link is 6% total, which is about where the last bit frame will be out of timing bounds), which is reasonable for the DCO over most of the qualified operating range, though it is risky.
  6. Like
    tripwire reacted to chicken in SHARP Memory Display Booster Pack   
    Toggling VCOM in hardware (part 3)

    As suggested by @@greeeg I tested the VCOM circuit with EnergyTrace.

    I compared two BoosterPacks. One with the TPL5100 based VCOM circuit, and one without. To maximize the impact, I display a static image while the MSP430G2553 is in LPM3. There's no software VCOM update in both scenarios.

    Theoretically that should give us something in the range of 2.5uA (2uA for the display, .5uA for the MSP430). EnergyTrace shows a mean current of 2.9uA (0.0029mA) for both scenarios, which seems close enough. The impact of the TPL5111 (37.4nA as measured previously) is smaller than the least significant digit that EnergyTrace displays (100nA resolution).

    EnergyTrace can compare a measurement to a previously saved profile. Here Reference was recorded with VCOM circuit, and Live is without:

    Results varied a bit over several runs, but the differences for total energy and battery life was always a negative impact of the VCOM circuit of 1.5% to 2.5%. Again pretty close to the theoretical impact of 2%.

    Displaying a static image for more than 8 years on a coin cell battery sounds pretty cool

    One last question remains: How do we know the hardware VCOM actually works?

    An interesting property of the SHARP displays is, that its circuit is visible on the glass and changes from light to dark gray based on voltage. Here three video i recorded with a USB microscope:

    1) VCOM toggling in software

    2) VCOM toggling in hardware

    3) No VCOM toggling

    I think we can declare this a win.
  7. Like
    tripwire reacted to chicken in SHARP Memory Display Booster Pack   
    Toggling VCOM in hardware (part 2b)
    A quick belated update: @@greeeg was right that omitting the DONE signal saves a lot of power as there's no charge current for the RC circuit.
    I tested this by removing R3. I left C4 in place, as a bit of decoupling won't hurt and might even be a good idea. (edit: actually, tying DONE to GND might be the better idea)
    Here's the modified circuit:

    As expected, the wave form is now 860ms high, 50ms low. I haven't tested yet what the display thinks about the inverted pulse width, but as observed by greeeg, if you follow the datasheet by the letter it shouldn't matter.
    Idle current measures exactly the same 37.4nA as above. The peak seems much shallower, the ammeter briefly jumps by about 0.6nA to 38nA or so. As suggested above, I will have to do some measurements with Energy Trace to find the actual peak profile.
    I think it's save to say that with this approach the average power consumption of the VCOM circuit is now below 38nA.
    With this we'd be at 2% of the display's static current (2uA), i.e. 5x lower current than the original goal of 10%. And it's less than 10% of a G2553 in LPM3 (500nA). I'd call that negligible in pretty much any real world scenario.
    Edit: added schematic
  8. Like
    tripwire reacted to energia in how to set maximum clock frequency of 120 MHz in TM4C1294 connected launchpad   
    As @L.R.A mentions, the default CPU frequency is set to 120 MHz. This is done in wiring.c line 64.
    There is some overhead in analogRead() that will most likely not get you to 40KHz. If you would like to get the max out of the ADC then I would advice to use the driverlib API's and base the implementation on interrupts rather then polling.
    You can use driverlib calls in Energia directly. Below is a code snip demonstrating how:
    #include <stdint.h> #include "driverlib/adc.h" #include "driverlib/sysctl.h" void setup() { SysCtlPeripheralEnable(SYSCTL_PERIPH_ADC0); } void loop() { }
  9. Like
    tripwire reacted to L.R.A in how to set maximum clock frequency of 120 MHz in TM4C1294 connected launchpad   
    In Energia the default frequency is 120Mhz.
    To change that you don't have any Energia functions.

    The maximum with 1 ADC is just 1 msps - you get 2msps if you use both ADCs with advanced techniques.
    Not sure on the max speed in Energia. I would say 40Khz is a bit pushing it, maybe you can just about reach it. 
  10. Like
    tripwire reacted to maelli01 in Christmas tree blinky thing   
    Last year my daughter (she was almost 7 back then) got interesting in soldering.
    So I let het solder stuff together, no function whatsoever. It did not last long, until she wanted to solder something that "does something". 
    So I took the challenge and designed this christmas tree.
    - FR2 board, copper artwork by me, other side by my daughter. (cheap FR2 is better for using felt tip pens.. almost like paper)
    - G2553, all 16pins to simple LEDs, various colours
    - simple discrete regulator (another led+ transistor) for more or less 3V
    - powered by USB
    - mostly through-hole (soldered by a 7 year old), some SMD (where I helped)
    - programmed in Energia
    merry christmas!

  11. Like
    tripwire reacted to L.R.A in How many channels of analog to digital conversion can the MSP430G2553 handle?   
    The MSP430G2553 does not have a 12 bit ADC, it's just 10bit.

    If you check this pinout you can see how many ADC channels the MSP430G2553 has and it appears to have 8.

    Of course that-s 8 channels but just 1 ADC - you can only sample 1 at a time. Meaning 4 signals take 4x longer than just 1 - you would need a sample speed of 1 every 0.25ms to get the 4 signals every 1ms. That's 4Ksps
    The max sample rate is about 200Ksps, at least it seems so. So your required sample rate should be easily attainable 

    I don't quite get what you are referring with the timers.

  12. Like
    tripwire reacted to chicken in [POTM] dAISy - A Simple AIS Receiver   
    One of the most interesting aspects of selling your widget is seeing how other people use your product and what their requirements are.
    dAISy was originally built for ship-geeks that are entertained for hours with MarineTraffic (like myself). I also broke out a few pins for tinkerers that want to connect dAISy to other widgets (again, like myself). Turns out, the majority of my customers are boat owners (unlike myself).
    Boaters use dAISy to keep track of ships around them for navigation purposes, i.e. avoiding collisions. Free software called OpenCPN turns a laptop (or a RaspBerry Pi for the more geeky faction) into a chartplotter, a device that typically costs $500+. dAISy is connected via USB and provides real-time information about nearby ships. However, many boaters already have a traditional chartplotter and want to connect these with dAISy for AIS input.
    Most chartplotters talk NMEA 0183, a serial standard compatible with RS-422. Unfortunately, that's not the same as the UART serial output of dAISy. Which leads to NMEA output as the 2nd most requested feature for dAISy (right after native WiFi*).
    Electronic tinkerers can convert dAISy's TX output into a signal that works with some (most?) NMEA 0183 consumers using an NPN transistor and two resistors:

    Exact resistor values don't matter that much, as their purpose is mostly to limit current. Slightly higher values should work as well.
    Besides not being really NMEA/RS-422 compliant, requiring to solder obviously is a non-starter for the majority of my customers. So I decided to look for an integrated, more polished solution.
    First step is implementing proper RS-422 driven from dAISy's serial output (TX). Luckily there's a chip for that. Well, there are many, but I settled for the TI UA9638.

    As I didn't want to change dAISy's main PCB (NRE, the bane of mass production), I designed a PCB that screws to the backside of the existing enclosure. On the inside of the PCB is the RS-422 driver and a connector for a cable to the main PCB. The cable is soldered to existing breakout pads for TX, 5V and GND. Still on the inside, I also added a DC/DC converter so that dAISy optionally can be powered from the boat's 12V power system instead of USB. On the outside of the PCB is a beefy screw terminal to connect NMEA 0183 and 12V wiring.
    Here is a picture of the first iteration I built today. The PCB on the left shows the inside, with DC/DC converter and related passives still unpopulated.

    The NMEA 0183 output works as expected. I'm not sure yet about including the DC/DC converter in the final design. I'm worried that having a switching power supply inside the enclosure will introduce noise and interfere with the radio's performance.
    I plan to add this or a similar design to my Tindie store early next year. In the meantime, any volunteers that have a chartplotter and dAISy and want to test the add-on should contact me.
    *Besides being wireless, WiFi is popular because it's the only way to get real-time NMEA data to the iPad. Unfortunately, iOS devices do not support USB or Bluetooth from devices not approved by Apple. Today, dAISy either requires a Raspberry Pi (running Kplex or similar) or some tinkering with an ESP8266. Once it has native NMEA output, dAISy will also work with NMEA routers, some of which include WiFi.
  13. Like
    tripwire reacted to maelli01 in Products using MSP430   
    Bike light follow-up: reverse engineering time!
    here is my almost complete circuit diagram.
    IC1 is a voltage regulator: 2.5V, exact type I could not find out. Only the MSP runs on the regulated voltage, all the rest runs from the raw battery voltage.
    Voltage divider R2 1M / R3 330K measure the battery voltage (some microamps get lost here)
    LED2 and 3 are indicator (red/green)
    LED1 is the power led
    PWM is 20kHz, coming from pin 11 of the MSP.
    Main switch is a Si4562, N and P channel 20V 5A mosfet. Inductor is 100uH.
    Instead of using only the upper fet, they alternately switch on the upper / lower FET, avoiding one diode voltage drop, increasing effiency.
    The circuitry around IC3 (a weird CMOS 4572) creates a small dead time (less than a microsecond) to avoid cross-conduction.
    Note the resistors in the signal path ;-) 
    They managed to regulate the LED current without a shunt resistor. Took me some time to find out how:
    The voltage across the inductor is low-pass filtered, R14 390k / C4 0.1u, then fed into the MSP. Of course the DC-part of the inductor voltage depends on the current flow.
    Pretty clever. The regulation is rather slow (ramp-up of current is so slow it is actually visible).
    The circuitry around Q8 and Q9 takes care of the battery charge turn on/off. Input is from a wall-wart adaptor which is 500mA constant current type.
    R10/R11 tell the MSP that external voltage is present.

  14. Like
    tripwire reacted to maelli01 in input protection diodes, interesting video on eevblog   
    power an msp430 without power pins ;-)
  15. Like
    tripwire reacted to greeeg in input protection diodes, interesting video on eevblog   
    @@maelli01 This is how I powered my '6 pin MSP430'.
  16. Like
    tripwire reacted to greeeg in SHARP Memory Display Booster Pack   
    I'm interested in the design decision to add the RC feedback into done. From the sharp memory LCD I can see that they show pulses into EXTCOMIN, however since it appears that it's the rising edge that cases the VCOM inversion. They also don't specify a maximum pulse length...
    The TPL5111, according to the datasheet will automatically de-assert the DRVn pin after 50ms. When in continuous mode. I can see that your RC circuit reduces this down by orders of magnitude, but also consumes a comparatively large amount of current.
    If the system will work with a 50ms pulse length won't the current be reduced from an estimated 235nA back down to a constant 35nA?
  17. Like
    tripwire reacted to chicken in SHARP Memory Display Booster Pack   
    Toggling VCOM in hardware (part 2)
    So much for "more tomorrow"
    This week turned out busier than expected. So a warning in advance: I didn't test this circuit in combination with the display yet.
    With that out of the way, here's the circuit I came up with (2nd try, I first tried the TPL5010):

    To power the TPL5111 I use the DISP signal, which is pulled high by the MCU to enable the display. This way the TPL5111 is only generating pulses when the display is in use. The MCU pin driving DISP should have more than enough grunt to provide the less than 1mA of current. I added a 0-ohm resistor for convenience to break the connection if needed, e.g. to measure current.
    The 4.3K resistor R2 connected to DLY programs the timer interval. I picked the resistor value based on a table in the datasheet, going for an interval under 1 second (4K = 900ms according to the datasheet).
    So now the DRVn line goes high after a bit more than 900ms. To turn off DRVn and therefore complete the pulse, we need to acknowledge by pulling DONE high. As the display's datasheet specifies a pulse width of at least 2us, this has to happen with a bit of delay.
    That's what R3 and C4 are doing. When DRVn goes high, the capacitor C4 is "slowly" charged through resistor R3. When the voltage reaches the trigger for a logical high (at least 0.7 * VDD according to the TPL5111 datasheet, so about 2.3V at 3.3V supply voltage).
    I already use 4.3K for R2 and 0.1uF somewhere else on the BoosterPack. Putting these numbers into a RC time constant calculator, I get 430 microseconds. By the definition of the time constant, this is the time it takes to charge to about 63%, which should get us close to 0.7 * VDD.
    430us is way above the minimum pulse length of 2us, but good enough to for testing:

    This test is done without connecting the display or an MCU. I connected DISP directly to regulated 3.3V.
    The yellow trace is DRVn. The maximum voltage is only about 3.1V. The TPL5111 datasheet tells us on page 5, that the output DRVn can be up to 0.3V lower than VDD when driving 100uA of current. 3.1V through 4.3K of resistance draws about 720uA, so we're lucky with a drop of just 0.2V. What you can't see is, that the pulses occur at 1.1Hz, i.e. every 0.91 second.
    The blue trace is the voltage on DONE. As expected it starts creeping upwards when DRVn turns on. When DONE reaches about 1.5V, DRVn turns off. This is quite a bit lower than expected (0.7 * 3.1V would be 2.2V). I guess the minimum spec in the datasheet means, that a 1 will be registered at 2.2V the latest. Anyways, the effective pulse width of DRVn is 250us, which is still plenty for our purpose.
    To measure power consumption of this circuit, we have to look at two elements:
    current while waiting current during the pulse To measure the current while waiting I dug out my Keithley 480 Picoammeter, which measured 37.4nA (0.037uA). Surprisingly close to the typical supply current of 35 nA as specified in the TPL5111 datasheet.
    Unfortunately the pulse is too short to measure peak current with this instrument. So let's try to estimate the current. I postulate, that the current is dominated by the RC element. Looking at the calculation above, I expect to draw about 720uA through R3 when applying 3.1V to 4.3K.
    And a bit more math to figure out the average current over a full cycle:
    0.00025 s * 720 uA = 0.18 uAs (pulse of 250 microseconds at 720 uA)
    0.91 s * 0.0374 uA = 0.034 uAs (0.91 seconds waiting for a pulse at 37.4 nA)
    Total 0.214 uAs of energy (?) per cycle
    Divided by total time (.91025), we get 235nA of average current.
    This is pretty close to the stated goal of 10% of what the display alone draws (2uA). That number can be significantly lowered by picking a better RC combination for R3 and C4.
    For example lowering C4 to 0.01uF theoretically shortens the pulse to 25us. Doing the same math exercise as above, I'd expect an average current of 57nA. That would be less than 3% of the display's power consumption.
    I could also increase the resistor value to lower peak current, but that would increase the pulse length by the same factor, i.e. a 0-sum game. Still, lower peak current might be desirable in some cases. E.g. 43K resistor and 1nF cap gives a 25us pulse width at 72uA charge current, which pans out to 39nA average current.
    Another thought is to increase the number of pulses, as some SHARP datasheets ask for more VCOM toggles than 1 per second. This would obviously increase the average current by roughly the same factor.
    One thing I so far ignored is how much the display draws from DRVn during the pulse. So the real world numbers probably will be higher. Which is the next thing I will have to verify and write about (definitely not tomorrow ).
    Edit: typos and grammer
  18. Like
    tripwire reacted to pneumatics in Products using MSP430   
    Interesting tear down.  I did DIY bicycle tail lamp using MSP430 back in 2011. Still working. Using 2xAA Alkaline cells. Running for more than 3 months in the battery. 3x4 red LEDs. BC107 transistors. One push button switch. Sleep in LPM4. LED driving from PWM. I have't measured the currents.
    20 uA is too much! 
  19. Like
    tripwire reacted to RobG in Who knows RGB LEDs?   
    The big spot lights in the video are DMX moving head lights, the rest of the lights are WS2811.
    There are several ways to control them, but you will need specialized software, like Vixen, and one or more controller, like SanDevices' e682 or Falcon F16.
    I have few types of floods, WS2811 and plain RGB. The total cost to build 10W is about $12-$15 per flood, 20W $20-$25.
    The 24ch DMX controller kit is $32 and it can be driven from LaunchPad, USB-DMX dongle, or other controllers like e682 (which has pixel and DMX outputs.)
    If you go with WS2811 floods, you will not need 24ch controller.
    To learn more, check out http://diychristmas.org/and http://doityourselfchristmas.com
  20. Like
    tripwire reacted to RobG in Who knows RGB LEDs?   
    Yes, I have 10W & 20W RGB flood lights with a companion 24ch DMX controller.


    Here's my board used for Xmas show (in Puerto Rico.)

    [will post link to video once it's made public]
  21. Like
    tripwire reacted to Rei Vilo in SensorTag   
    You need to power the MPU9250. There's a dedicated GPIO for that.
    Also, the MPU9250 uses a specific I
  22. Like
    tripwire reacted to dubnet in Problem facing while detecting peak   
    Another way to approach a peak detection task is in the analog domain.  With the proliferation of capable, inexpensive MCUs sometimes the simple tried and true analog solutions are not considered these days. That said, it may or may not make sense for your application but I thought I would throw it out there. Please see the discussion in the link below for some of the pros and cons. 
  23. Like
    tripwire reacted to greeeg in SHARP Memory Display Booster Pack   
    @chicken  Nice research. I always chuckle when people suggest using a 555. While still a handy IC if you have a uC running to keep a RTC alive then toggling a pin with a hardware timer adds ZERO* extra power draw.
    I noticed on my sharp memory LCD projects that if I had the display inverted, (All black) there was a noticeable contract difference while the EXTCOMIN was toggling. However could not notice it when not inverted, but likely still there.
    Incidentally I've just ordered some more displays for a new project, now that digikey stock them. Unrelated, have you seen the RGB model?
    I assume you are going to all this effort so you can deep sleep your MCU?
    *Not actually zero. but in the order of nA.
  24. Like
    tripwire reacted to chicken in SHARP Memory Display Booster Pack   
    Toggling VCOM in hardware (part 1)
    Everyone who did in-depth experimentation with the SHARP Memory LCD probably remembers this tidbit from the datasheet:

    Neglecting VCOM inversion never damaged my display, but according to the documentation, contrast is impacted by inversion.

    VCOM inversion is easily implemented in software with a timer interrupt, but that complicates things, especially when one tries to create a simple-to-use library that supports multiple platforms. My own library relies on the user to either update the display at least once a second, or call a dedicated function to trigger VCOM inversion. The latter is not very beginner friendly.
    VCOM inversion in hardware is done by wiggling the EXTCOMIN pin of the display. The different datasheet versions and sections are a bit contradictory, but the rough requirements are:
    EXTMODE is tied to GND to enable hardware VCOM inversion VCOM inversion is triggered by a pulse on EXTCOMIN EXTCOMIN pulses have to occur at regular intervals < 1 second (some say 30-60 Hz, some 0.5-30 Hz, some "should not exceed 1 second", and "higher frequency = better contrast") Minimum pulse width for EXTCOMIN is 2 us (some places say "the duty cycle of EXTCOMIN sould be 50%", but I think they mean the duty cycle of VCOM) As said the datasheets are bit cryptic, but this chart makes pretty clear what is going on:

    "555 to the rescue!", I thought. But low-power variants like the LMC555 consume 50-100 uA, and that's without the charge/discharge current for the capacitor. Compare that to the 2 uA typical (15 uA max) the SHARP datasheet specifies for displaying a static image.   
    Enter the Marlow Thermo-Electric Generator (TEG).
    Say what?!?
    Well, back in August @@bluehash wrote on the 43oh blog about energy harvesting with a TEG and the related TI application note. The topic of energy harvesting is only mildly interesting to me, but the circuit featured a TPL5100 which was labeled as Nano Power Programmable Timer.
    The TPL5100 is member of a small family of programmable timers which, hold on to your supercaps, consume 30-35 nA while twiddling their imaginary thumbs. Each IC features a different combination of
    how the timer is programmed (resistor, 3-bit code) (DELAY) what happens when time's up (toggle a pin low or high) (WAKE) how to acknowledge that signal (DONE) watchdog functionality that kicks in when WAKE is not acknowledged in time The TPL5111 looks like the perfect fit for our purpose:

    .. to be continued (getting late here.. more tomorrow)
  25. Like
    tripwire reacted to L.R.A in Tiva C launchpad runs too slow.   
    How to improve? Don't use any Energia function.

    What sampling rate? How to do you test that if there is not a single command according to you.

    Serial print is really slow. Not sure how it handles just 1 variable but still.
    digitalRead is also really slow when compared to alternatives. 

    Let's see the function:
    int digitalRead(uint8_t pin) { uint8_t bit = digitalPinToBitMask(pin); uint8_t port = digitalPinToPort(pin); uint32_t portBase = (uint32_t) portBASERegister(port); if (port == NOT_A_PORT) return LOW; if(ROM_GPIOPinRead(portBase, bit)){ return HIGH; } return LOW; } I would estimate your addition of 1 digital read (it seems you add some math too, not only the reading) takes about 43 cycles! If you want the full potential of the MCU capabilities, you have to be go lower and lower until you reach your desired performance.

    This would be so much faster with register programming or Tivaware.
  • Create New...