madparts electronics footprint generator 2.0 release

 

The Open Source madparts electronics footprint generator tool has been in use since its initial release at Productize. While the core functionality worked fine the library management code contained in it leaved to desire and started to be a problem when handling with the huge number of electronic parts we deal with at Productize. This is solved in the 2.0 release by removing all the library management code and simplifying the program down to its core: a powerful footprint editor and generator.

 

Library Management

As library management is gone in the 2.0 release, this changes the workflow a bit. The program is now used to edit a single footprint only. Previously making a new footprint involved cloning an existing one in the library management part of the tool. Now a simple “Save As” from the File menu provides the same.

This also means that the ‘id’ and ‘parent’ meta data contained in the file are no longer used by the program. They are still allowed to be there but are silently ignored.

The file names and directory structure are completely up to the user now. This gives the flexibility to manage footprints any way the user wants.

 

Bug fixes

A bunch of small bug fixes have been applied. Mostly concerning ‘export to kicad’ as this is the most used functionality of the tool.

 

Enhancements

The 2.0 release also introduces the 2.0 file format which adds some extra functions for generating footprints.

 

BGA function

 

The BGA function rect_bga allows generating BGA footprints in an elegant way.

It works by passing it an x and y size, a single pad (ball), a distance between the pads and two functions: one for generating names for the pads and a second optional one for filtering out pads based on x and y coordinate. The following screenshot shows an example:

 

bga_example

paste option

 

The paste option can be used on Pads or SMD Pads to disable the ‘paste layer’. The BGA example above demonstrates this as well.

 

Download

Read further documentation and download the new release from the website.  Code and bug tracking lives in github.

KiCad BOM generation

BOM (Bill Of Materials) generation is an important and usually cumbersome part of doing electronics.  KiCad has two ways to generate a BOM: from the schematic and from the layout.

Layout based

In pcbnew select from the menu: File -> Fabrication outputs -> BOM file.

This generates a simple CSV (Comma Separated Value)  file with the components grouped by type and value.

"Id";"Designator";"Package";"Quantity";"Designation";"Supplier and ref";
1;"C1,C24";"0402_C";2;"10nF";;;
2;"C2,C5,C8,C9,C10,C15,C16,C17,C18,C19,C20,C22,C23,C28,C32";"0402_C";15;"100nF";;;
3;"C3,C4";"0402_C";2;"8pF";;;

 

While useful for simple boards and experiments, in practice you usually want more detail e.g. capacitor voltage in the BOM, as explained nicely in this article from Spark.

Schematics based

KiCad also allows generating a BOM from the schematic. This works by it generating an XML exporting all the data fields for all used components and post-processing this XML with a script. This is nice as it allows to document everything in one place: the schematic.

2015-05-25-104514_3120x1920_scrot

example component with Fields providing good detail

 

The biggest disadvantage is that currently it seems to be impossible to save these extra fields as part of a component meaning it involves manual entering for each schematic. Automating this in some way would be nice.

The actual generation of the BOM is done with the menu: Tools -> Generate Bill Of Materials

This gives the following screen:

2015-05-25-105205_3120x1920_scrot

 

This may seem a bit daunting but it is actually quite simple. What KiCad does is just generate an XML file with all the components with all the fields. Each plugin is just a script that is passed that XML file as an argument and the output is the resulting BOM.

An example XML fragment:

<comp ref="C12">
  <value>2.2uF</value>
  <footprint>passive:0402_C</footprint>
  <fields>
    <field name="Voltage">10V</field>
    <field name="Package">0402</field>
    <field name="Identifier">capacitor</field>
    <field name="Tolerance">X5R +-10%</field>
  </fields>
  <libsource lib="passive" part="C"/>
  <sheetpath names="/" tstamps="/"/>
  <tstamp>54FF2106</tstamp>
</comp>

 

This example python code generates a BOM from the XML, assuming a bunch of standard fields and allowing for extra fields, groups by Identifier and Value.

It uses the beautifulsoup python library for easy parsing of the XML.

P.S.: for the language purists out there: yes, this code is very inefficient (quadratic complexity) but it still runs in milliseconds on a modern computer so it doesn’t matter 😉

Conclusion

It is possible to generate a nice and detailed BOM from KiCad but there is still work making it more automated.

Energy harvesting Workshop

Power is a big constraint for connected products. People want to have a product without a wire or even without cumbersome batteries.
We met Geoffroy from e-peas at the university of Louvain-la Neuve to evaluate their new Energy harvesting chip in our IoT environment.
The goal was to validate the possibility to use energy harvesting for very low power consumption products, even in a dark environment like for home automation sensors.
We successfully did some tests and we want to share the testing details in this article.

 

Energy harvesting

An energy harvesting chip is a device used to capture and store an external energy source like solar, thermo-electrical or piezzo-electric power and distribute it in the sensor node electronics. This kind of chip provides a really small amount of power but this is enough to run very low-power electronics safety and timelessly.

 

e-peas

e-peas is a belgian company located in Liège and founded in 2014. The company is developing two new chips that are key to the design of wireless sensors. First the AEM1x940 is an energy harvester that is claiming a “cold start” at 5 times lower poser conditions than anything on the market and then a 32-bit microcontroller that will consume an order of maginitude less than the competition.
With these chips, we will be able to solve the hassle of replacing batteries and be able to make really autonomous IoT products.
We tested the first prototype of the AEM1x940 and a new version is in progress. The samples for customers should be available in Q4 2015.

 

Testing

First test : Power a Bluetooth Smart module sending only advertising frames
Hardware setting :
We used a Nordic Semi nRF51 PCA10001 dev kit as Bluetooth product.
The power was provided by an outdoor solar panel (ultra low cost) which is connected to the AEM1x940.
To temporarily store the energy from the solar panel, we had to use the capacitors available in the laboratory, so we used a big electrolytic capacitor of 100mF (ultra low cost).
The AEM1x910 has a built-in programmable LDO regulator, so we decided to power the nRF51 board directly by the AEM1x940 at 2.5V.
sch-BLE
Software setting :
We configured the nRF51 to send a Bluetooth advertising frame every 5 seconds.
To avoid useless consumption provided by the programming part of the dev kit, we disabled it by switching it off by the provided button.
Testing Environment:
The installation was placed in a dark environment. The curtain was closed to reduce a maximum the sunlight and only one light was lit.
Test validation :
epeas-BLE-test
We used a µcurrent tool from EEVblog to analyse the current provided by the solar panel and the current consumption of the nRF51 board.
The current consumption of the nRF51 board was 30uA with peak of 10mA every 5 seconds when the frame was sent.
We also connected an oscilloscope to monitor the voltages of the solar panel and LDO output.
The output voltage was stable.
We analyzed the frames sent with an Android App from Nordic Semi called nRF Master Control. This App allowed to validate that all frames had been received (every 5 seconds).

Second test : Power a microcontroller with Sharp memory LCD and display a dynamic clock
Hardware setting :
We used the Silicon labs Zero Gecko Starter Kit.
The power was provided by the same outdoor solar panel.
To store the energy from the solar panel, we used four big electrolytic capacitors of 100mF because during the startup of the Zero Gecko, it asked for more current then the Bluetooth module used in the first test.
We powered the Zero Gecko board directly by the AEM1x940 at 3V.
Software setting :
We programmed the Zero Gecko board with the clock example available from Silicon Labs. This software displays an analog clock. The seconds hand causes a display refresh every second waking up the board.
Testing Environment:
The installation was placed in a dark environment, the curtain was not totally closed to have a minimum of the sunlight and only one light was lit.
Test validation :
epeas-clock-test
We monitored the current and the voltage with the same tools.
We validated the functioning of the software by looking at the display.

Conclusion
We are really satisfied by the results. We ran a Bluetooth beacon-like device and low power microcontroller with display on only small solar panel. We deliberately chose a low cost solar panel, a low cost energy storage (capacitor) and a very bad light environment to simulate a worst case scenario. The technology proved to be very promising to build autonomous wireless sensors that can work outside or indoor. This can open the door to exciting new applications and products.
We are now waiting for a final sample to continue our analysis.

segger j-link loadbin vs loadfile

Using the segger J-Link to directly upload firmware using SWD to micro-controllers has always been a bit cumbersome. One of the problems is that it required a binary file with just the raw binary data and you had to explicitly give the location the binary data has to be written to as an argument.

loadbin <filename>, <addr>

Newer versions of the JLink tool allow uploading of various file formats which eases this a bit.

loadfile <filename> [<addr>]

An easy way to use this is convert the object file of your firmware to an intel hex file and just upload it with loadfile. For example the following Makefile rule does the conversion to intel hex:

%.hex: %.elf
    $(OBJCOPY) $^ -O ihex $@

 

The hex file can then just be uploaded with loadfile.

EFM32 bootloader scripted FW update

The Silabs Energy Micro EFM32 ARM-Cortex microcontrollers support updating the firmware in the chip via a bootloader. The chips come with the bootloader pre-installed by default.

So far I haven’t had much luck using this bootloader as my quest to get it working usually was quickly suspended by me overwriting the bootloader and then failing to re-install the bootloader.

The problem with re-installing the bootloader is that you need to compile the bootloader for your specific device and Silabs only provides files to do this in the IAR development environment which I have no interest in using.

Luckily I stumbled upon the work of the f-watch team: Bootloader , and after some digging I found the corresponding code here .

They modified the bootloader not to copy itself to RAM, which I don’t need anyway (it is only useful if you want to be able to overwrite the bootloader) and besides that they changed the bootloader triggering procedure from pulling low the SWD pin to pressing two other. That change was quickly reverted.

After installing the bootloader I can now use minicom + xmodem to upload and boot a firmware and it works fine.

The only remaining problem is that I want it to work from within the makefiles I use for building. After some trial and error I found this trick using screen:

 

# upload via xmodem
xmodem: exe/$(PROJECTNAME).bin
    # open serial device
    screen -d -m -S 'serial' $(SERIAL) 115200
    sleep 0.1
    # say we want to Upload
    screen -x "serial" -X eval '!!!| echo u'
    sleep 0.1
    # execute xmodem transfer
    screen -x "serial" -X eval "exec !! sx -vv $<"
    sleep 2
    # say we want to Boot the installed firmware
    screen -x "serial" -X eval '!!!| echo b'

Not the nicest trick but it works fine. To be replaced one day by a python script.

IMG_20141116_091712

driving WS2812 programmable RGB LEDs using hardware SPI

There is quite some interesting information on the internet already on driving WS2812 programmable LEDs already:

eliaselectronics.com

 

But the most interesting one I found was this one:

cpldcpu.wordpress.com

Especially the timing tables it contains, and especially the concluding one, which I took the liberty to copy here:

ws2812_timing_table

 

The WS2812 has a single data signal that provides both a clock and data. A zero bit is encoded as a short pulse and a 1 bit is encoded as a longer pulse. In order the differentiate them the zero pulse should not exceed a certain length and the 1 bit should be minimal a certain length.

This got me thinking how this easily matches on hardware SPI.

The idea is to use 4Mhz SPI and send 1000000 for a zero and 11100000 for a 1. Given that a bit at 4Mhz is 250 ns this gives a 250 ns pulse for a zero and a 750 ns for a one. Looking in the table this sits comfortably inside the timing window allowed by the WS2812 LEDs.

In practice this gives something like this for the zero bit:

 void zero_bit() {
spi->TXD = 0x80;
wait();
}

and something like this for the one bit:

 

void one_bit() {
spi->TXD = 0xE0;
wait();
}

The reason for the wait is that the particular ARM Cortex-M0 I’m using here does not expose DMA so I cannot use DMA to just send an entire frame asynchronously at once, but I need to wait a little bit to allow the MCU to push out the byte before the next one is entered. This could be done by busy looping on a flag but just some NOPs to wait seemed simpler to me:

static inline void wait() {
__ASM (
” NOPnt”
” NOPnt”
” NOPnt”
” NOPnt”

” NOPnt”
” NOPnt”
” NOPnt”
” NOPnt”

” NOPnt”
” NOPnt”
” NOPnt”
” NOPnt”

” NOPnt”
” NOPnt”
” NOPnt”
” NOPnt”
);
}

I’m using this code in practice and it works just fine and stable, tested with this adafruit neopixel strip:

1426-00

(image is copyright adafruit)

Android 4.3 Bluetooth Smart service caching

Random fact: Android 4.3 caches Bluetooth Smart services. When you change the services on a test device, a reboot is needed or your app will keep seeing the old services. (At least on my Nexus 4)

 

IMG_20140909_095547