Things I Find Interesting
Posts tagged Developer
Here’s Why I’m giving up on MyNewt (for now)
Apr 4th
With all these sensors and platforms lying around, I wanted to just pick one and build a quick sensor demo. It should be easy, right?
The basic idea
As you may (or may not) know, I spent a lot of time with the Apache MyNewt project a year or so ago. It has enormous potential. It’s small, fast, and very lightweight. I even wrote a tutorial on developing an app with MyNewt. I’m sure this post is going to annoy the good folks working on that project, but that is surely not my intention.
In developing a new demo for my new-ish job, I have been having problems with the stability of the Arduino Bluetooth stack. I decided that maybe MyNewt was a better route for this particular device, so I began trying to develop the app for MyNewt. Here’s why I’m giving up.
This is a dead-simple app. It does 3 things:
- Waits until it gets a connection over Bluetooth
- When connected, it reads an I2C sensor
- Sends the value from the sensor to the connected device
Simple. In Arduino, there is an I2C library, “Wire” library, and I can simply do a Wire.begintransmission(0x68) — the I2C address of the device — then Wire.write() as many bytes as I want, then Wire.endtransmission() and the write to the I2C device is done. Likewise, I can read from an I2C device’s registers with a Wire.requestFrom(I2CAddr, len) and get back the number of bytes I requested from the I2C Device address requested. Simple. Clean.
The MyNewt Approach
Unfortunately, in MyNewt, I pretty much have to start from scratch and build complex data structures, then figure out how to initialize them correctly, Here’s the “example” from another I2C sensor:
int
bno055_write8(struct sensor_itf *itf, uint8_t reg, uint8_t value)
{
int rc;
uint8_t payload[2] = { reg, value};
struct hal_i2c_master_data data_struct = {
.address = itf->si_addr,
.len = 2,
.buffer = payload
};
rc = hal_i2c_master_write(itf->si_num, &data_struct, OS_TICKS_PER_SEC, 1);
if (rc) {
BNO055_ERR("Failed to write to 0x%02X:0x%02X with value 0x%02X\n",
data_struct.address, reg, value);
STATS_INC(g_bno055stats, errors);
}
return rc;
}Notice that the “data_struct” takes the address out of the “sensor interface” structure, but then I have to pass them both to the i2c_master_write() call. I fooled around with this for a few days trying to adapt it to the sensor I have — and my sensor is much more simple — I simply write 4 bytes to the proper I2C address, then read back 4 bytes.
Here’s the entirety of the code required in Arduino:
int readVal() {
int value = 0;
byte attn[4] = {0x22, 0x00, 0x08, 0x2A};
Wire.beginTransmission(Addr);
int x;
for (x = 0; x < 4; x = x + 1) {
Wire.write(attn[x]);
}
delay(10);
Wire.endTransmission();
delay(10);
Wire.requestFrom(Addr, 4);
byte i = 0;
byte buffer[4] = {0, 0, 0, 0};
while (Wire.available()) {
buffer[i] = Wire.read();
i++;
}
value |= buffer[1] & 0xFF;
value = value << 8;
value |= buffer[2] & 0xFF;
byte sum = 0; //Checksum Byte
sum = buffer[0] + buffer[1] + buffer[2];
if (sum == buffer[3]) {
return value;
} else {
// Failure!
return 0;
}
}I’ll spare you the 3+ pages of C code in MyNewt it takes to get anywhere close to doing this. And then there’s the Bluetooth stack, and implementing a series of event handlers, etc. to deal with events, etc. It’s literally almost 1,000 lines of code (the main.c file is over 500 lines).
The problem
And this, I think, is the problem with MyNewt. In the year+ since I was involved it hasn’t evolved to be any more user-friendly. It remains deeply mired in the weeds. If what you want to do is write highly board-specific code that is not really reusable, and requires a very deep knowledge of the underlying hardware, RTOS, libraries, etc. then MyNewt is for you. If, on the other hand, you’re a developer that simply wants to get stuff done, it just isn’t. I would love to be able to use MyNewt for this demo. I really would. I think it has great potential, and it’s come a long way in its short lifetime. But in order for it to gain traction with a wider developer audience — like, say, the Arduino crowd — it’s going to have to start making things a lot easier for would-be developers.
Abstraction libraries — like Arduino’s Wire library — and wrapper libraries around the Bluetooth NimBLE libraries, etc. are a necessity I really do hope I can come back to MyNewt again and develop this demo app quickly. I just don’t have the time right now to dig around and write very low-level, board-specific, code in order to make this demo work. I’ll just have to continue to work around the bugs in Arduino.
Breaking Out, and Down, the NodeMCU
Mar 30th
A few months ago I was really excited to order a NodeMCU IoT Board to experiment with. It basically runs Javascript (Lua) and from what I’d read about it, it was easy to use, and easy to program. Cheap, easy to program, powerful, etc., etc. You all know the drill by now. Sounds like a great platform to build stuff on! I’m in! When I bought it a few months ago I immediately opened the box, plugged it in and … nothing. So it’s been sitting on my “big board of IoT devices” for a few months until I had more time to actually see what was up with this device.
First, let me run down a bit of my philosophy on IoT developer platforms. It’s pretty simple, but apparently not many IoT developer Platform builders believe in it as I do:
- The platform should be dead-easy to get started on. I should be able to plug the device in, have clear, simple instructions for getting it running, and be able to start developing in a few minutes.
- The Documentation should be simple, easy to follow, and detailed. And easy to find. If I have to resort to multiple google searches to get the thing working in the first place, it’s already suspect.
- I don’t mind developing in C, Java, Javascript, Python, Arduino Script, or whatever other language your device supports. (Yes, I develop in al of those, and many more) but I should be able to get up and running quickly.
- There should be examples of how to do lots of things included, or at least referenced. How to get SPI up. I2C, PWM, ADC, etc.
All of these (and others, but I’m not going to make this a manifesto) are, to me, basic out-of-the-box requirements. And I have written a lot of installers in my day. I’ve written them in Java and even bash shell scripts, to make things dead-simple and repeatable. It’s part of the job of a platform developer to make sure that the user, the customer, isn’t burdened with doing things that I, the product developer, should have done right in the first place. Installing all the required packages and bits and making sure they work is one of the things I should always make sure is done, and done right, before shipping anything.
Ok, </rant> On to the NodeMCU itself. Here’s the Executive Summary:
Not. So. Much.
According to the NodeMCU site, it is “USB TTL included, Plug & Play” but that’s where things already start to go slightly wrong. Yes, it does have a micro-USB on-board. But Plug & Play? Not so much. You see, they used a cheap Chinese USB/TTL chip instead of going with an FTDI chip, so the drivers for it are a little less than ideal. I plugged it in and … nothing. So I poked around in the internals a bit (I’m running Mac OS X currently and not only have I installed all the FTDI drivers, I even went so far as to port the FTDI LibMPSSE-SPI drivers to Mac OS X.) Nothing shows up anywhere in the device tree. Clearly the device is not recognized, hence not ‘plug and play’.
Hmmm … so next I spent a fair amount of time on the Google Machine hunting for answers. The forums are mostly in Chinese, but I did manage to find a mention of the fact that the DevKit uses a Chinese USB TTL chip, and a link to some drivers for it. I downloaded and installed them and was forced to reboot my machine. Maybe it’s the old Solaris/UNIX guy in me, but rebooting my machine is something I typically avoid at all costs. I like my uptime. I really hope that those Chinese drivers didn’t include a rootkit hidden in there, since they are now part of the kernel. I poked around in the package using Pacifist before installing, and it appears clean, but who knows.
Ok, so now the device shows up in the device tree. That only took an hour. So what do I do with it? The answer to that is non-obvious. How do I get code on it? How do I update the firmware? I can build my own custom firmware using nodemcu-build.com but how do I get it onto the device? Not much documentation on that. Back to the Google Machine where I find ESPlorer. That looks promising. Nice Java-based GUI for developing and managing your NodeMCU device. So I grab that.
I can connect to the device now, and … wait, what?
PORT OPEN 115200
Communication with MCU... Got answer! AutoDetect firmware...
Can't autodetect firmware, because proper answer not received.
� #��ng�$gn��� c p��d{$sd8�o� � $ b g�| l��c��go�d��$` � gn d` gs�ۓn � dp�g� s����� c n�| � #��no� d` � nod�l o;���g {�` `�o ��c�nl� ��g'� � dp�g� s������d �c n�| � #��ng�$� l � no � $ g{���o r��` r��g {�` {l��n���gn�����{ 'og� d�c sd � �$� ��� � �$dl {l � �lllo�� � d�dl d � �$Ęn�� o��o~ � LJ '� $l��o �'���gd�| c d` ;l j
�sd�C�
Ai-Thinker Technology Co. Ltd.
invalid
That does not look good. Let’s run through some of the built-in commands and see what we get. First lets try a simple reset:
AT+RST
OK
ets Jan 8 2013,rst cause:4, boot mode:(3,6)
wdt reset load 0x40100000, len 816, room 16 tail 0 chksum 0x8d load 0x3ffe8000, len 788, room 8 tail 12 chksum 0xcf ho 0 tail 12 room 4 load 0x3ffe8314, len 288, room 12 tail 4 chksum 0xcf csum 0xcf
2nd boot version : 1.2 SPI Speed : 40MHz SPI Mode : QIO SPI Flash Size : 4Mbit jump to run user1
sd�C� Ai-Thinker Technology Co. Ltd.
invalid
Nope.
Get the chip ID maybe?
print(node.chipid()) ERROR
Nope. Check the heap?
print(node.heap()) ERROR
Nope.
So let’s turn on the WiFi and see if that helps.
AT+CWJAP? +CWJAP:"Murray Home" OK
Hey, something actually works! That’s at least some measure of progress, right? So let’s try the button that says it will do a cloud-based update of the device, since based on the above reset, it looks to be almost 3 years old:
AT+CIUPDATE +CIPUPDATE:1 +CIPUPDATE:2 +CIPUPDATE:3 +CIPUPDATE:3 +CIPUPDATE:3 +CIPUPDATE:3 +CIPUPDATE:3
ERROR
Nope.
At this point I’ve spend about 3 hours on this device, and about all I can do it get it connected to my WiFi, but it won’t run any code sent to it, and it won’t even successfully perform any of the basic system-check commands. This, combined with the extremely sparse documentation and I’m ready to add it to the pile of “good idea, poorly implemented” pile and move on. It’ll probably sit on the Big Board for a while longer, in case I have a few more hours to kill and need to up my frustration level, but I don’t see any real future for this device.
If you’re developing a platform for developers, don’t do it this way. Don’t make your developer’s life harder, more frustrating, or waste their time or they won’t use your platform. It really is that simple.
Recent Blog Comments