Tuesday, June 23, 2015

STM32 Nucleo and DFU USB Bootloading

Over the last few months I have been playing with the Nucleo development boards from STMicroelectronics. If you're unfamiliar with them, they are fast, mbed and Arduino (headers) compatible. This makes it easy like an Arduino to program and use. What sets them apart is that they are 32bit and have, depending on the model, tons of memory and flash. The Nucleo boards maintain the Arduino footprint but also have headers for the extra pins which gives this board plenty of GPIO for your projects.  In turn, you end up with multiple buses such as SPI, I2C, and UARTs for your consumption. They are priced very well and come in different flavors based on your needs. Each flavor is based on different ARM Cortex architectures such as M0, M3, and M4. One of the best features is real debugging via ST-Link/V2-1. The unfortunate thing due to the nature of mbed, you can only use the debugging features using a full desktop IDE such as Keil or some of the other free alternatives. But mbed allows you to export your code from the online IDE to the project format for those IDE's. So there's that.

Most of my projects spend very little time on the development board. Once they are working, I usually want to design a PCB for it. Therefore I prefer to use microcontrollers that support native USB programming, such as the popular ATMega32U4. With some AVR chips you can use the Arduino bootloader but most chips come with a DFU bootloader that can support flashing over serial and USB. In the case of STM32, it additionally supports CAN, I2C, and SPI bootloading. For some reason the Nucleo boards don't have the native USB connector onboard, but the needed pins are available for easy access. (The discovery boards do.)

Connecting USB Pins

To access these pins you can use a USB breakout or a USB Tester. Of course you could always cut open a USB cable, but seriously, why create a mess? If you have one of my USB, Testers it makes it much easier, plus all of the other features it provides. BUY ONE NOW!! Just kidding! The pins for D+ and D- are not labeled on the pin out of the Nucleo board out but if you look up the datasheet you can find them and match the pin names with the Nucleo pin out as shown below.

So far I have tested the L152 and F411 and both have been PA12, PA11 (D+, D-). Which is pin 6,7 from the top on the right most column of male headers.

STM32 Nucleo USB DFU Connections

Saturday, May 23, 2015

Maker Faire, Bay Area 2015

This year the Bay Area Maker Faire celebrated ten years. William and I could not believe it! We've attended BAMF (as we cheekily call it), for the past eight years. Wow! It feels like only yesterday that we were frantically searching for parking, trying to stand in line before the gates opened. Oh wait, that happens each year. Ha!



This year was just as eye opening as ever. It has grown in popularity for sure, but more so it has also grown into a lot more than just garage hacking. From the new 3D Printer tent, to the Start-up area, the BAMF has become a fair that now encompasses so much more and will surely continue to morph. We feel like we've grown along with it. After-all, some of William's first blog posts were about the Arduino Projects Pack from MAKE.




We've certainly come a long way since the early days of the Maker Faire. For us, BAMF has become more than just the faire itself. It's a real treat to meet-up with some folks from around the globe that we now consider friends. Over the past couple of years, there have been some post Maker Faire shindigs like the BAMF meet-n-drink hosted by the Hackaday crew and the BringAHack dinner hosted by Laen from OSHpark. Honestly, it's really these outings that we look forward to attending. A chance to mingle without the distraction of a crowd or the barrier of a booth? We could do that all night!

I tried to capture some images from those evenings this year, but bare with me as it was dark and you know, after a long day with one or two beers, hiccups are bound to happen. :)







Sunday, May 3, 2015

Jamrific

Over the last few weekends and then some, I have been playing with the Colorific RGB Bulb from Amazon. Inspired by this learn guide https://learn.adafruit.com/reverse-engineering-a-bluetooth-low-energy-light-bulb/explore-gatt I decided to make it reactive to audio. Finally! An excuse to buy the Teensy Audio shield!

Here are a few pictures and a short demo of it in action. You can find the code and my notes on the issues with it and where the project is at currently on:https://github.com/FriedCircuits/Jamrific

Teensy 3.1 with Audio Shield, TFT connect to RPi

Raspberry Pi 2 with BT 4.0 and UART connected to Teensy 3.1.

Colorific Bulb in action


Monday, April 13, 2015

Review: Hummingboard

I came across the Hummingboard while reading Engadget. This isn’t your run-of-the-mill Linux board, it’s jam-packed with features that other boards don’t have. The main feature that sets this board apart from the others is that the SOC is socketed and swappable. What a great idea! Need more power for your project or different board features? Just swap out the SOC module or board and now you can have an expanded set of features all while using the same platform.

Does this new board look strangely familiar for some reason?
This board shares the same footprint and IO layout as the Raspberry PI.


Sunday, February 22, 2015

Raspberry Pi 2 and Motorola Lapdock

Back in October of 2012, I had tested the Motorola Lapdock with the original 256MB Raspberry Pi. Recently I was able to get my hands on a Raspberry Pi 2 and decided to see if it worked any better. It pretty much works the same in that if the Lapdock doesn't detect it, it goes to sleep and it won't try again until it turns itself off. So the only way to get past the point in boot where the display signal is lost for a second, is to power the Pi up from another power source with the HDMI connected. You must wait for it to fully boot. Then disconnect the HDMI, wait for the Lapdock to turn off, and then plug it all back in and power it up. It's quite the sequence just to get it to work.

This time around I had a hard time with audio. Last time it was a struggle too, but at least it worked. I didn't spend a lot of time on it, but only the way I could get it to work was by loading the Python games app and selecting force headphones. Then you can use the web or anything else but this is using headphones instead of the built in audio. A lot has changed in software since the 256MB version so this needs more investigating.

Raspberry Pi 2 and Motorola Lapdock
This is unfortunate since the Raspberry Pi 2 and all of its power would make a great travel companion with the Lapdock. What really needs to be done is a way to fake an HDMI signal at all times in any case it would work much smoother. Maybe if the Lapdock can be hacked to always stay awake or a longer detection timeout. At this point it will be at the bottom of the project list.

Friday, February 13, 2015

HA: Living Room Node

Just wanted to do a quick post about the node running in the living room. It's similar to the other nodes except I am using a Tiny328 and a DHT11 temp/humidity sensor. Currently, this is the only node with humidity. It's presently being powered from a 5V USB wall adapter using a USB Tester to break out the power - same one that is running the La Crosse gateway!



Here is the github link that I am using for all nodes. I have adapted it to support each sensor that a node might have. It's based on the roomNode by JeeLabs. This sketch assumes the node has been configured already with the JeeLabs rf12demo sketch.

Owncloud

Last year I decided to give freeNAS another try despite the warnings of not having ECC memory and running in a VM. Long story short, it ran great for awhile. I had freeBSD jails setup for CrashPlan and Owncloud - it was heaven! It was all running smoothly until not having ECC memory caught up to me. I began to have checksum errors, so I had to dump the data. Much faster than restoring from backup.



Wednesday, February 4, 2015

HA: DomotiGa Web Interface

DomotiGa is an open source Linux app written in Gambas which I hadn't heard about until now. As part of any good home automation or any connected project is a way to control it remotely and easily, otherwise it's easier just to hit the light switch yourself, right? I am using a Ubuntu Virtual Machine running in VMWare ESXi. VMWare offers ESXi as a free version of there enterprise bare metal hypervisor. ESXi can run on most hardware but if you have trouble there are plenty of guides out there to get drivers working.

One of the easiest ways to get a remote interface is a website. It is much easier, universal and platform independent compared to using an app. There are two types of web interfaces available in DomotiGa. I tested both out to pick the best one for my application and decided that since each one serves a different purpose I would leave both active.



Simple Web Client

DomotiGa Simple Web Client

DomotiYii


From the above screenshots I am sure you can tell the difference between the two. The simple web client is well, simple, and it is great for quickly checking sensor data or controlling switches. But for advanced management, DomotiYii fits the bill. I keep the simple web client running in a browser window on my left monitor. It can auto refresh and the changes turn green momentarily.

This would be a good interface to easily setup a Raspberry Pi with a display on the wall as a status display. DomotiGa has a JSON RPC interface so it wouldn't be hard to grab the data and pipe it into your own front end. There is another system that makes easy to design a UI and interface it with DomotiGa, one is CF iViewer https://www.domotiga.nl/projects/domotiga/wiki/CF_iViewer