We started looking at using an MSP430 as an ultra-low power controller for an IoT setup. At this early stage we are still discussing the role it should play. The number one benefit of this chip is that it can keep time and turn off/on an LDO for the actual IoT device while consuming very little power.
At this stage we are considering an esp8266 serving as a network gateway. It is still debated if an attached sensor should be connected to the msp or to the esp.
Discussion items
0 what was already done elsewhere
1 power management for running the MSP430
2 power management for running slave devices (esp8266, ds18b20,...)
3 power source (battery, PV, charger?)
4 PCB layout for the MSP and above items
5 protocols/APIs
5.1 manage esp8266 as a network bridge (over serial?)
5.2 network protocol talking to other agents (MQTT? data server?)
6 device drivers (many scattered on the net)
I started using an eZ430F2013 supplied as a kit where the processor is mounted on the MSP-EZ430D, with a debugger/programmer MSP-EZ430U. The plan is to use the programmer to work with other msp430 chips.
The other option is to use an MSP430 Launchpad as the programmer but I do not have this ATM.
I installed CCS v6.1 on my laptop and discovered that it does not work, the driver works only up to windows 7 :-(
I now installed it on an old windows 7 laptop and it works OK (and very slowly…), I ran the blink example. I then attached an MSP430G2452 to the programmer and it did not like it, saying:
Configuring Debugger
Error connecting to target:
Unknown device
And yes, I did configure the project for this chip.
Good news. I decided to try the programmer from the eZ430-Chronos (the toy watch). It looks identical but was acquired much later. It did manage to talk to the external msp and I now have it blinking. Today the LED tomorrow the world…
And while I have the podium, this is a very nice writeup on using the ds18b20 with an MSP430G2452 http://karve.in/?p=1408
Worth checking the comments there too.
@Harvs Did you mention having access to some working code?
Yes, I have a bare bones library for reading a single DS18B20 (i.e. doesn’t do identification of multiple devices.) It’s barely 100 lines of code and will be trivial to port (only uses GPIO and a delay routine.) It will require a little bit of effort to optimize for power, albeit maybe that’s unnecessary in the big scheme of things.
The onewire protocol of the ds18b20 really is simple to implement straight from the datasheet.
I think we should put some effort into implementing (and briefly documenting) a standard API that would be used between the two processors.
No point for everyone doing the same thing. Will you prepare the sensor code or do you want to pass what you have and I will work on it?
I agree, we need to consider the whole relationship between the controller (MSP) and any other connected device. For the ESP as a network bridge we could go all the way and do slip or ppp but this is probably too far.
We need a formal discussion, starting with a good look at what is used by other similar projects. Then we should clearly define the scope of this project.
@Harvs When you say “it’s working” I assume you watched “temp = …” in the debugger?
We should plan to meet and discuss how we want to organize the code for easy cooperation. For example, I recommend moving the generic one-wire functions to a separate module as these will be useful for other devices. I also suggest creating some macros for common usage (e.g. DELAY_MS() or DELAY_US() and such). etc…
I am ready do this boring part, also adding some doco to the repository.
I spent more time with the esp, removing LEDs and tracking power usage. I am waiting for a few more esp’s (which I hope will show up next week) when I will putt together an MSP+ESP board that I will use for further development.
Even without the MSP there will be benefit from using a more suitable LDO instead of the 1117 I use now (or running directly off the battery as I also do).
BTW, I added some bullet points to the project document (#1 for this topic) and we should spend some time improving it.
Yes, I’ll be going along Wed night if it’s still on.
There’s certainly some code cleaning that can go on with this library, but I’m not getting too far into refactoring it yet until I’ve done some basic power optimisation. Also some of the stuff isn’t as trivial as you might first think. For example ms or us delay functions are not provided by TI because the MSP430 is designed to have its clock freq switched on the fly to optimise power. Therefore you as the programmer must manage how many cycles you’re delaying for because only you know if the clock will be any one of 8 different speeds at that time.
The OneWire functions are ported across from the Arduino library (I think.) Problem is only a small subset of functions are ported in a very limited way to get the DS18B20 working, and consume little code space. To use them with anything else will require complete validation on the end application (timing is completely tuned for the DS18B20, may not work for anything else.)
I expect so, but when you actually do a delay you should know what speed it is set to and act accordingly.
I agree that we should only port/write functions we need, so I am not suggesting we create a fully functional one-wire library. I am less pessimistic about the utility of these functions for other devices. We can just move what we have now into a separate module, as is. And a smart linker should drop unused functions anyway.
I can be there tomorrow (Wed), and it will be nice if other interested people attend too.
@clixx_io plans to have another ESP meeting so there may be wider audience then.
[later] Today’s (20 May) 7pm is on so I will be at the space.
As far as “use the MCU or the ESP” goes, I’ve been working on doing the interfacing from the MCU (in my case an Arduino), only turning on the radio hardware when there’s a message to be sent. This is partly to reduce instantaneous power draw, so I don’t have e.g. a motor running at the same time as trying to power the radio, and partly to separate the functionality of “taking readings” from “sending data”.
The MCU is quite capable of taking readings from SPI devices with tens of milliamps of power consumed. The ESP (or ZigBee in my case) requires far more power to do the same readings.
As a bonus, isolating the high power radio to a serial connection means I can switch to a different device for communication without having to rewrite the sleep/read/store code for a new platform.
I am working on the communication between the MSP and the ESP. I take it as made up of the following steps
UART TX/RX on the MSP. Test against a PC serial console.
UART TX/RX on the ESP. lua? raw sdk?
MSP/ESP protocol. Exchange data both ways.
end to end tests. Scenarios:
4.1) send “reading” to ESP to report to a server
4.2) request reading from the ESP
4.3) request server data from the ESP
Still reading on the subject. It is suggested that the MSP430G2553 is one with hardware UART (and more RAM too). I wonder if we should play with this one? I have a G2452 that needs a bit banging UART (not a biggie but why complicate our life?).
[later] The G2533 looks better and is cheaper too. Need to examine the data-sheet closer.
I haven’t ordered anything yet (they don’t deal with orders over the weekend anyway.)
I’m having second thoughts about the MSP430. I thought it was a good choice at <$1, however given we’ll be paying >$3ea in single qty, I think this is overpriced for what it is. At that price we have the choice of pretty much any of the ARM CM0 from any of the major manufacturers with more sram, flash, peripherals and considerably more processing power if required.
With what we’re doing, we don’t need the ultra low power of the MSP430. Any of the modern ARMs will have low enough standby current.
I am not married to the MSP430. Any suitable processor will do.
As for cost:
I see the battery as the most expensive component so far. Cheapest is Aldi 4xAA 2300mAh NiMH @$6, other brands double or quadruple this. A decent 18650 would cost much more (and will be equivalent to 3xAA). Any other options?
The other items are: ESP, MSP (or such), LDOs, PCB and misc small passives.
In short, the cost of the controller is not the main issue. Especially when compared to the Rigol :-)
I actually consider total power usage as the most important issue.
Philosophically I will appreciate open source software tools. The ESP is not winning here.
I think many of the problems are due to some weird power thing.
For example, the button on my wifes LED-strip controller turns on/off at the strangest times, directly coinciding with:
turning on the kettle
turning on the flourescent lights
As I only just completed the physical installation after about 4-installation-attempt-sessions I’m sure that I’ll get it sorted out. It’s just capacitors missing somewhere.
But crazy stuff. 1 x 10uF Capacitor is just not enough.