Embedded Hardware & Software

Some years ago in 8-bit times when I was AVR fan, I have been aware sleek, low-footprint TagConnect Pogo pin interface for Programming and Debuging the MCUs, initially Microchip's PIC series, which made me a bit jealous and highly motivated me in buying them. It has two footprints: legged and no-legs (-NL suffix). The bigger one has hooks for holding in place, which is for comfortable debugging.

The smaller footprint is great for fast in-system programming on your final product's assembly line. It is inly about 1 cm^2 large.

This is the footprint for its corresponding ICD cable-to-board connector:

As folks around know, I prefer Segger's J-Link over STLink, because it supports virtually unlimited breakpoints and is much faster overall, so I bought one and never looked back. That was the reaason I decided to push a bit further and create my own TagConnect J-Link adapter.

As you can see, the board contains selectable 1117-style 3.3V/0.3A LDO, as well as all JTAG pins placed conveniently on a header, which may be nice to have. Heck, you can even ignore the TagConnect and use the board as a PSU + debug interface.

EDIT: After taking my TagConnect cables out of a dusty box, I found out that I have RJ12 versions. This board is upgraded. Now it contains RJ12 along with IDC socket.

We had enough looking at manufacturers, making their own closed gardens at users' expense. A generic (umbrella) Automation Communication Protocol is needed, in order to open and connect these closed gardens. A modern Layer 3+ protocol for dealing with today's hardware is needed. The layers below may stay platform dependent.

An open hardware and software Vendor Implementation Kit which will allow third party vendors and hackers to seamlessly implement their own inter-protocol bridges through an API. This way, it would be easy to bridge the proprietary protocols and start talking to protocols based on different standards.

In today's world Internet of Things world going after their own users' privacy, while “security” agencies collect more and more bulk data, it is our initiative to fully respect your privacy. Every device in your home has to stay silent to the outside world, unless you tell it so. Allowing your fridge to phone home to its manufacturer through our system is unthinkable, because Open Source should design with privacy in our minds.

Up until recent months, Open Source oriented developers developing for ST's' Cortex-M SoCs were faced with a tough choice: should they choose the development tools that exist today, but are Windows-centric? Let's be fair and admit that using Windows for any FLOSS development is like developing without arms and legs.

Fortunately, native open source OS solutions have started popping up lately, though they narrow down to GNU/Linux (mainly Ubuntu 12.04 or later), gcc toolchain, openocd, and a handful of scripts for make and linker. Another addition to the list is Eclipse IDE.

With these findings, I'm on the “me too” side of STM32 bandwagon.

The first thing to go after, in my point of view, seem to be Vedder's Get Started With STM32F4 on Ubuntu Linux about building modified summon ARM GCC toolchain. With minor modifications to the script, this works well with Ubuntu 12.04 LTS.

Mastering STM32

If you are STM32 positive like me, then you may find even better reading with ST-specific internals:
Mastering STM32. Carmine Noviello did a great job at explaining many implementation details and caveats. Although the book is HAL library oriented, STM32 users with SPL affinity like me should also read this book. In short, this is the best book about STM32 Cortex-M systems on chip so far.