Fixing old central, and fixing meteo node

Time flies - I just wanted to finish something, and it's almost midnight.
We had some problems with electricity yesterday. Few weeks ago, the wall socket in the bathroom burned out. Well, not really, but my wife reported strange smell when using the washing machine. It wasn't your typical burning smell, it was more like ironing a perfumed piece of clothing. As a quick hack, I asked my wife to use an extender cord. However, the other circuit did not handle a water kettle and the washing machine at the same time, and breakers went off.
I am using an old central node designed few years ago. The new, Arduino Due based central node I am working on is supposed to replace this old central node.
The old central node has a problem I was aware of, but wasn't able to debug so far. Sometimes, it simply hangs after being powered up, or stutters in the main loop. I noticed that before, but the problem went away when I attached the debugger. This time, it didn't, and first debug output suggested the central node isn't getting the IP address via DHCP. A few tests suggested the MAC address isn't unique, and router refuses to assign new IP. I am still not sure what caused this, probably a router problem. I'll keep an eye on it and if it happens again, I'll generate random MAC on every start or something.
Next thing I worked on this evening was making the RasPi log all the sensor node packets into a file. It was pretty simple, and works fine so far. I want to see what exactly is happening with the meteo node in the evening.
The meteo node was also modified to report the correct voltage of the goldcap that powers it. I assume the sensor are eating too much of juice, and the whole thing will need some optimization. Not a big deal, I was planning on running this from battery anyway, but - well, if it can be solar powered, even better!

RasPi or not...

No updates yesterday, sorry. I was looking for the best library I could use for the ILI9341 display from C code on RasPi, and ended up rewriting the Adafruit library. However, the whole thing is object oriented, inheriting stuff from the GFX class that inherits the stuff from Print class... not that it's impossible to port all those to RasPi, but I got bored pretty quickly. I cannot guarantee that it will work, and I don't want to waste one evening by porting a few C++ libraries, then another evening debugging it, and in the end finding out it does not work.
I thought about it and decided to go back to Arduino, abandoning the whole RasPi idea for now. In fact, there's not much of benefit in using RasPi. I was thinking about that email checker, but I still don't know I really want it. If I decide I really do, I can hook up the RasPi to the whole system somehow. The limitations of RasPi do not overcome the benefits. So - I am back to Arduino. I in fact want to use Due this time, making at least one small step towards ARM. Due has enough of RAM, enough of pins, three HW SPI ports, and even DMA.
When looking for a good ILI9341 library, I verified that Adafruit works fine, but there's another library based on Adafruit code that allows using HW SPI, and even DMA, making the display blazingly fast. Library is made by Marek Buriak (?) and can be found here.
There's a few open things related to SPI on Due. The chip supports three HW CS pins, but I might need more. Can I combine hardware and software CS? Or will I need to move some of the peripherals to software SPI? I am planning on using the ILI9341 display, ENC28J60 network, and a few nRF24L01 modules. My guess is that the ENC28J60 library will need porting, and thus using the software SPI would be the easiest way to go.
Anyway, the ILI9341 works, I'll test the RF24 modules tomorrow, and if all looks good, I'll start porting one of the ENC28J60 libraries. There's Ethercard library I am already using for other projects, and then there's arduino_uip that looks good, too. I am also running out of ENC28J60 modules, I actually had to steal one for testing from an older project that's on standby right now.

Python? No thanks...

Oh well. My attempt to use Python for the RasPi node was over before it actually begun. I was about to port the include file over to Python, just to find out that Python does not support structures. There's some sort of emulation of regular structures, but that looked so complicated and awkward I simply gave up. Back to C. If nothing else, I will be able to share the source code with any other hardware I have at home, being it Arduino, RasPi, MSP430 or PICs.
I tried to use the ILI9341 display as RasPi console, and add ncurses to my skeleton RasPi RF24 central node. To my surprise, RasPi crashed. I did not get any message about the crash, but it was hard, as even SD card wasn't synced. I tried older code without ncurses that actually did not touch the display at all (and I am running stuff over SSH thus nothing was really written to the display). Crash. I tried even older code that for sure worked. Crash. Disabling the ILI9341 as console solved the crash. Strange.
I have no good explanation for this. I even tried to debug this behaviour with gdb, but the last thing I can see is the RF24 library opening the /dev/mem. Then the program gets out of gdb's control as it continues running, starts communicating with the RF24 chip, displays some internal details about it, and then the whole system stops responding. I guess it's two things trying to use the SPI device at the same time (console and RF24) and that somehow doesn't work... I don't think I will be able to fix this, and I am now remembering why I always preferred using Arduino to RasPi. Anyway, I need to think about this. Most likely going to my own library for the TFT support, probably porting the Adafruit Arduino lib. Great...
There is one positive outcome of all this - I found out about gdb's TUI (Text UI). Not that it makes gdb the best debugger ever, but certainly makes it less PITA *grins*

RasPi extension board

I spent most of the evening testing the TFT display attached to RasPi (see my yesterday's entry), and enabling it to work. The info is confusing, or at least I did not find anything that would look simple enough. In the end, I followed the guide for notro/fbtft and managed to make the display work. It's not that difficult, although it still sounds to me like magic.This is what I needed to do:

1) FBTFT drivers as loadable modules. This installs the necessary kernel drivers without actually recompiling anything:
   sudo REPO_URI=https://github.com/notro/rpi-firmware rpi-update
   sudo reboot

2) To continue using fbtft_device, add to /boot/config.txt:
   dtparam=spi=on
   dtoverlay=pitft

3) Add to /etc/modules - edit according to your connection of TFT signals to GPIOs, and according to used CS0 or CS1. All on one line!
   fbtft_device custom name=fb_ili9341 width=240 height=320 rotate=270
   speed=32000000    buswidth=8 bgr=1 gpios=reset:23,dc:18 cs=1

4) Add kernel argument to file /boot/cmdline.txt if you want to use the panel as console
   fbcon=map:10

I also need to make a final decision about the language I'll use for the RasPi code. I am deciding between C and Python. C would be the language of choice, but a lot of nice libraries, like the Adafruit TFT one, is written in Python, thus I am more and more leaning towards Python. I need to start with it anyway as we'll use it at work, and this could be a nice way to start with it for real. Let's think about it till tomorrow.

RasPi extension board

As promised, a picture of the extension board that will become a center of the RasPi node. Arduino Pro Mini in the middle, surrounded by RF24 module connected to SPI.0 of RasPi, the flat cable to RasPi GPIO header, a display (and buttons) connector with attached display, power supply part with KIS-3R33S, and another RF24 connected to Arduino. The empty socked next to Arduino will host PCF8574P I2C expander (when it arrives from China) that will take care about buttons (if any) and other low speed stuff.To test the display, I used Adafruit ILI9341 Python library, and it worked fine. I rewired the thing a bit and did not test it since, but I assume it should work, or could be fixed if it doesn't.
I had some major issues with the RF24 module - it did talk to RasPi, but did not receive any packets. I spent a few hours trying pretty much everything, and in the end added some tantalum caps directly to the module pins. That helped, and I hope it was the only problem. I added a few capacitors here and there, and one 1000uF is hidden under Arduino... the whole module has so much juice it can run by itself now.
The CR2032 module stopped with around 2.45V. Unfortunately it was snowing overnight, and the snow melted so I retrieved the module in the morning, dripping wet, and reporting voltages around 4V - the water bricked the 1M24 resistor, fooling the divider into thinking there's much higher input voltage. Anyway, the battery now shows 2.94V without any load. I'll continue the experiments in upcoming days.

Future plans for the central node

Lazy day today, I sorted out some components I had laying around in drawers, took a long afternoon nap and played Deus Ex: The Fall. The game isn't bad... just a bit weird, and it looks like I cannot jump... Did someone say "Doom"?
I needed to make the final decision about the central node. I was leaning towards using Arduino Mega or Due, but finally I decided to go the "Raspberry Pi + Arduino Pro Mini" way. That way I'll have the whole communication under control and I can use the code I already have for Arduino, but additionally I'll have access to the processing power of RasPi. If possible, I'll make the RasPi act as a web radio as well, and will let Arduino control the mpd or whatever music program I'll use.
The plan is to have one RF24 module connected to the RasPi directly, and RasPi will act as an internet bridge, using one dedicated channel for nodes that care about getting internet connection. Another RF24 will be controlled by Arduino, communicating with sensors and sending out time info, weather info etc. on another channel. I might actually connect TWO RF24 modules to Arduino,  one running the RF24Network stack, the other just using basic RF24 for reading data from sensors (reason explained below). That sounds as an overhead, but when one RF24 module costs 70 cents... Arduino will also control one RFM12B module for compatibility with other devices at home using these modules, and will also need to support the RS485 interface for the old clock on my wife's bedside table. The clock is about ten years old, before the wireless modules became available and popular, and it's running on PIC!
To recap and write my thoughts down:

• RasPi
• RF24 module providing internet access on specific channel, using RF24Ether
• 2.2" ILI9341 based TFT LCD
• Arduino
• RF24 module running basic RF24 radio stack to receive info from sensors
• RF24 module running RF24Network to communicate with clever nodes (clock, remote displays etc)
• RFM12B module for older devices
• RS485 for that old clock
• IR receiver, control knob etc. for controlling the web radio running on RasPi

I started to build the "baseboard" that will hold all this additional hardware, but I barely finished the power supply and RasPi cable / connector, so no pictures today. I'll work on it tomorrow and post a pic of it when it takes final shape. It's connected to RasPi via flat cable. If necessary, I will be able to flip it over, face-to-face to RasPi, making the whole thing more compact to be put into a small box.
The CR2032 node doesn't perform well. I started it yesterday evening with 2.97V, and in the morning it was still around 2.97V - 2.96V, hovewer, it dropped over day, and while I am writing this, it dropped again to 2.92V. My impression is I am at the end of the discharge curve (meanwhile, the voltage dropped to 2.91V) and the battery is dead. I am puzzled, and wondering if perhaps the whole overhead of RF24Network isn't causing this. It only sent something like one or two hundred of packets! Another node running with just basic RF24 radio stack was running for two weeks without much of power optimization.
Voltage dropped to 2.90V... oh well. I'll let it run and see where it stops - that would be the minimal operating voltage *grin*.