Friday, December 2, 2016

working console on Shuttle xs36v mini computer with Debian 8 (Jesse)

I recently re-installed this system to use it as a local server.

Installation of Debian 8 went smooth. I choose not to install a graphical environment as I only want to attach a screen in emergency situations.

The system boots fine but then the screen goes into power-safe mode. The system is still reachable remotely.

After some searching on the internet [1] the solution is to blacklist the graphics driver of the system.

Create a file called /etc/modprobe.d/blacklist.conf and add the following to it:

blacklist gma500_gfx
This tells the system not to load the driver. Then do
 sudo update-initramfs -u
this updates the boot RAM disk to reflect the change.

Reboot the system and enjoy a working console.

Picture or it didn't happen:

Friday, March 7, 2014

Bluetooth Low Energy Explorer Tool

Bluetooth Low Energy is all about services and attributes. Exploring these attributes is an interesting way to gain more insight in how a device works and is invaluable for testing. In order to make this process more comfortable a testing tool is invaluable. Hence the BTLE-explorer was born.

continue reading on the Productize Lab blog.

Monday, January 20, 2014

programming the attiny10 in linux

The attiny10 (and it's brothers attiny4,5 and 9) is a cute little 6-pin SOT23-6 AVR micro-controller. The very tiny footprint and low price makes it interesting as replacement for e.g. the 555 in simple circuits.

attiny10 sitting between a 5050 RGB LED and a 555 timer IC

Programming it seems to have been quite involved but the more recent gcc supports it just fine, making it finally easier to use. I tested with 4.8.1 downloaded from Atmel, as the one provided by Debian (also 4.8.1) did not yet have the definitions for the attiny10. It seems like the public source tree for the avr tool lags behind quite a bit against the Atmel provided toolchain ...

For programming I'm using an AVRISP-MKII. I updated it to the latest firmware. This updating unfortunately requires avrstudio in windows; programming itself works fine in Linux.. You may also need a recent avrdude. I'm using 6.0.1.

Programming requires that the chip is powered by 5V according to the spec. I can confirm that this is the case because I tried it with 3.3V and it didn't work, it tries to program but fails on verification.

Once programmed the chip runs all the way down to 1.8V.

The pin mapping is pretty obvious:

attiny10 pinout:

  2. GND
  4. PB2
  5. VCC
  6. PB3/RESET
AVRISP-MkII pinout:

  1. MISO
  2. VCC
  3. SCK
  4. MOSI
  5. RESET
  6. GND
And the mapping:

  • GND - GND
  • VCC - VCC
The following C++ code blinks a LED every second on pin PB2:
#include <util/delay.h>
#include <avr/io.h>

static inline void setup() {
  // configure PB2 pin
  PUEB &= ~_BV(PUEB2);   // disable Pull-Up
  DDRB |= _BV(DDB2);     // enable Output mode
  PORTB &= ~_BV(PORTB2); // set output to Low

int main() {


  while (true) {

    PORTB &= ~_BV(PORTB2);

    PORTB |= _BV(PORTB2);

  return 0;
The following makefile builds it and uploads it with the help of avrdude:

# Makefile loosely derived from generated avr toolchain makefile

PROG   := avrispmkii
MCU    := attiny10
F_CPU  := 1000000
TARGET := blink

COMMONFLAGS = -g -Os -funsigned-char -funsigned-bitfields \
  -fpack-struct -fshort-enums -Wall -DF_CPU=$(F_CPU) -mmcu=$(MCU)

CFLAGS = -std=gnu99 $(COMMONFLAGS) -Wstrict-prototypes \
  -Wa,-adhlns=$(<:.c=.lst) \

CXXFLAGS = -std=gnu++11 $(COMMONFLAGS) -fno-exceptions -fno-rtti \
  -Wa,-adhlns=$(< \

ASFLAGS = -Wa,-adhlns=$(<:.S=.lst),-gstabs
LDFLAGS = -Wl,-Map=$(TARGET).map,--cref

# TODO fuses
# FUSE:=-U lfuse:w:0xff:m -U hfuse:w:0xd9:m -U efuse:w:0xff:m

AVRDUDE:=avrdude -c $(PROG) -p $(MCU)

TC = /your/path/to/avr8-gnu-toolchain-linux_x86_64

CC      = $(TC)/bin/avr-gcc
CXX     = $(TC)/bin/avr-c++
OBJCOPY = $(TC)/bin/avr-objcopy
OBJDUMP = $(TC)/bin/avr-objdump
SIZE    = $(TC)/bin/avr-size

default: $(TARGET).hex




%.hex: %.elf
 $(OBJCOPY) -O ihex -R .eeprom $< $@
 $(SIZE) $@

%.elf: %.o
 $(CC) $(CFLAGS) $< --output $@ $(LDFLAGS)

%.o : %.c
 $(CC) -c $(CFLAGS) $< -o $@

%.o :
 $(CXX) -c $(CXXFLAGS) $< -o $@

%.s : %.c
 $(CC) -S $(CFLAGS) $< -o $@

%.o : %.S
 $(CC) -c $(ALL_ASFLAGS) $< -o $@

 -rm *.hex
 -rm *.lst
 -rm *.obj
 -rm *.elf
 -rm *.o
In action:

Tuesday, December 24, 2013

using madparts for making electronics footprints: an eleborate example

In this blog post I'm discussing a more complex footprint I've made and how I made it with madparts based on the vendor's specification. More specifically I'm making a footprint for the Bluegiga BLE113 Bluetooth Low Energy module.

Lets start by collecting all the needed data.

The physical dimensions of the module are found in the spec page 16:

This will be used to define the physical boundaries of the package.

Next is the landing pattern. It can be found on page 17 of the specification:

 This is used to define the pads for the module.

The order of the pins can be found on page 7:

Finally the specification also gives a clearance for the antenna on page 20:

This means we'll have to add a restrict area to the part for this clearance area.

let's write code!

Define the size of the module as found in the physical dimensions:

  module_dx = 9.15
  module_dy = 15.74

Define the size of the pad as found in the recommended landing pattern:

  pad_dx = 2
  pad_dy = 0.5

The horizontal pads need an adjustment from the center of the module. The landing pattern defines 5.35mm between the two columns of pads, and we orient from the center of the pad so in total this gives and adjustment value of:

  pad_hadj = (5.35+pad_dx)/2

The landing pattern tells us the distance between pads:

  pad_between = 0.8

The pinout description gives the number of pins:

  n_left = 18
  n_down = 6
  n_right = 12

The physical dimension tells us the distance from the bottom of the module to the center of the bottom left and right pad. This works because the pad centers are the same for the physical diagram and the landing pattern.

  lr_pad_from_bottom = 1.45

Now this gets a bit tricky. We need to calculate the vertical adjustment needed for the column of pads, but this is relative to the center of the module. The trick is to take pad 18, move it to the 0 point, then to the bottom of the module, and then use the lr_pad_to_bottom adjust value specified in the spec.

  pad_vadj = ((n_left-1)/2)*pad_between  # move pad 18 to 0
  pad_vadj -= module_dy/2                # move pad 18 down to bottom
  pad_vadj += lr_pad_from_bottom         # and back up by 1.45

Let's draw a rectangle to document the module shape, and draw a silk around it to make it easily visible on the board later.

  r1 = make_rect module_dx, module_dy, 0.1, 'docu'
  r2 = make_rect module_dx+0.2, module_dy+0.2, 0.1, 'silk'

Let's define the pad shape with the earlier defined constant. we want 100% round corners.

  pad = new Smd 
  pad.dx = pad_dx
  pad.dy = pad_dy = 100

Now lets make the left row of pads. First make them, then adjust the x and y by the values we calculated earlier.

  l1 = single pad, n_left, pad_between
  l1 = adjust_x l1, -pad_hadj
  l1 = adjust_y l1 , pad_vadj

Next the bottom row. clone and rotate the pad, and create a horizontal row of pads. Adjust the y as specified in the landing pattern figure. Finally renumber starting with the number after the last number we used for the first column of pads.

  l2 = rot_single (rotate90pad clone pad), n_down, pad_between
  l2 = adjust_y l2, -module_dy/2+lr_pad_from_bottom-0.55
  l2 = generate_names l2, n_left

Finally the right row. Again a single row of pads. Reverse the order. Renumber starting after the last number used for the down pads.

  l3 = single pad, n_right, pad_between
  l3 = reverse l3
  l3 = generate_names l3, n_left+n_down
  l3 = adjust_x l3, pad_hadj
  l3 = adjust_y l3, pad_vadj+(n_right-n_left)/2*pad_between

Let's add a name somewhere inside the module, a bit below the top:

  name = new Name (module_dy/2-1)

Let's add a rectangular for the restrict area. This is a but messy but it boils down to placing it right above pas 36 and 3.5mm on the right of the left side of the module.

  k = new Rect
  k.type = 'restrict'
  k.dx = module_dx
  k.dy = module_dy/2-l3[n_right-1].y
  k.x = -module_dx/2+3.5+k.dx/2
  k.y = l3[n_right-1].y+pad_dy/2+k.dy/2

Finally combine it all in a list and we're done.

  combine [name, r1,r2, l1, l2,l3, k]

The latest version of the full file can be found at

This is a screenshot:

And this is the part in eagle cad:

And in kicad:

Saturday, December 21, 2013

a look inside the shielding can of the BLE112 Bluetooth Low Energy module

Given that I accidentally damaged this Bluetooth Low Energy anyway, I thought it interesting to take a look what is inside the shielding can with a macro lens.

Here you see the bluegiga BLE112 module on a board with the shield still in place:

And here I removed the metal shielding can:

As you can see no real surprises here:

The central unit is a Texas Instruments CC2540 SoC Bluetooth Low Energy module.
On the lower right of it sits a 32 Mhz crystal for the main clock.
Above it is what I assume the 32.768 kHz low speed clock crystal.

The antenna was already visible with the can in place, but what's interesting is the second companion chip inside the can. I assume it is some kind of filter for the antenna.

Besides that just a few passives and that is it!