- Redbear ble nano v2 segger embedded studio software#
- Redbear ble nano v2 segger embedded studio code#
Indicating the browned out conditionĬan you use a single eInk indicator to tell the power state, specifically whether an energy harvesting system is or has browned out?
You should put a state variable for an eInk indicator in persistent memory (FRAM in this case), otherwise you won’t know the state of the indicator when you wake up. In that mode, the CPU is powered off and all registers, stack, and RAM contents are lost. I use the MSP430, and use it’s LPM4.5 low power mode. You don’t have to use all segments, you can leave them unconnected, but then their color is not determined, they might not stay white. Thus you need seven GPIO pins for this device, if you use all segments. The device does not have a power and ground pin. You need a GPIO pin for each segment, and one for the top plate. I fear they might not sell their five segment bar gauge very long, their large displays are probably more in demand. eInk does not sell a single indicator device.
Redbear ble nano v2 segger embedded studio code#
The code doesn’t implement a BarGauge object, it implements a set of five indicators. Here, I use different segments of a bar gauge, each as in indicator. It takes power to set it, then requires no more power, forever. Usually indicators are binary, on or off. But an LED does not indicate unless it is powered. You can search for electronic parts using that word, or “indicator lamp.” Usually they are LED’s. The code does not implement a bar graph, it implements a set of five separate indicators. The code keeps state variables for indicator state in persistent memory. (If you just spin delay, a typical, active MCU takes 1000 times more power then does the driven eInk device. The code sleeps the MCU in low power mode while delaying for the eInk to change color. You can change it to use for example, Arduino. The low level code uses the Texas Instruments MSP430 DriverLib. The high level code abstracts what you must do to drive eInk.
The code is in my msp430Drivers repository, in the src/eInk directory. I don’t think it means that the device “burns in” if you drive it too long in one direction. Apparently this just means you must drive a segment to the same voltage, for the same duration, in both directions, whether changing white to black, or vice versa. Some documents say the driving must be “balanced”. A segment only changes color during a relatively long (seconds) delay. You can drive any segment to any voltage for a short duration without changing the segment.
In other words, the field for the changing segment bleeds to floating segments, and the ink appears to bleed. I found that you also must drive all non-changing segments to the voltage of the top electrode (you can’t leave them floating), otherwise nearby segments can also change. You don’t need a negative voltage rail (with respect to ground.) To drive a segment white, you drive the top electrode high, and the segment low (grounded.) Wait a while, then remove the drive: all segments to the same potential (voltage) or all segments inputs (floating.) Thus it takes 0.5uA for a half second to drive the device, which is not much energy. This device is about a centimeter squared. The datasheet says the device uses 0.5uA per cm squared. You can drive from white to gray and back again. But I found that a half second is adequate, if you can accept gray rather than black. The datasheet says a segment must be driven for a half to two seconds. It has six segments: the background and five bars of a bar graph. It has an invisible, top electrode (pin 1) that covers all the visible segments. But I found that you can drive it with only 3.3V. The eInk bargraphĮInk sells a 5 segment bar gauge, part number SCD722002. But that adds complication, and requires the system to have more power when relaying the indication. An indicator lets you simply walk up and look at it.Īnother alternative is to use wireless. eInk does that.Īn alternative is to write to persistent memory, then read it after plugging in a debug probe. The indicator must use little power to set, and zero power to maintain.
Redbear ble nano v2 segger embedded studio software#
I want to indicate or show software faults and system state. They can exhaust power when they don’t get enough ambient energy, say during a few days of cloudy weather. I build systems that are solar powered, without batteries, with only super capacitors. This reports my experience using an eInk bar gauge instead of LEDs. An eInk device is persistent: visible even after your embedded, energy harvested system exhausts power.
0 kommentar(er)
