anelok: revisiting Bluetooth, summing it up

Werner Almesberger werner at almesberger.net
Sat Nov 23 11:27:07 EST 2013


Ron K. Jeffries wrote:
> If [when?] you solve the bluetooth on Anelok challenge, a major benefit
> will be the added utility and ease of use with smartphones.

Yes, all the mobile devices that can't have or don't want to
have USB dongles sticking out would benefit a lot from this.

> Semi-unrelated: where do you stand on Anelok's MCU pin utilization? Are
> there any unused i/o pins?

Yes, but only very few. In the current design [1], I have ...

- PTE29, PTE30, PTE24, PTE25 set aside for a wheel with a 4-way
  switch.  But that wheel would be much larger anyway, so that
  reservation is cancelled.

- PTB0 (ADC-capable) is set aside for a light sensor. That one
  may stay.

That's a total of five unassigned pins that currently end in
little solder pads.

Pins on ports A and D are interrupt-capable. Pins on ports B, C,
and E aren't. (Why oh why, Freescale ? Would it really have been
so hard ?)

Now, I know I need one more pin to detect USB VBUS. Maybe I'll
use interrupt-capable PTD7 for it and send USB_ID testing (which
doesn't really need an interrupt) to one of the PTEs.

One down, four left.

Then, depending on how standby power measuring of the OLED goes,
I may have to add a FET to separate it from the boosted (*) 3.3
V rail, like I have a FET for the same purpose for the memory
card. This would eat another PTE.

(*) Not boosted in standby but the rail will still be at battery
    voltage.

Two down, three left.

If we need to give the MCU its own crystal, RF_IRQ on PTA19 would
have to move. (Freescale, why oh why do all those "special" pins
like SWD_*, nNMI, crystal, nRESET, those pins that would usually
not be assigned to any other function, have to be on port A,
taking away precious interrupt-capable GPIOs ?)

So after a bit of reshuffling, another PTE would become something
else.

Three down, two left.

Changing the radio is likely to introduce a number of additional
changes and may actually free one or two pins. Or maybe eat
another one. We'll see.

So nothing is certain at the moment. If there are free pins, I'll
route them to solder pads. But there won't be a lot of them. I
could free some pins by multiplexing signals, but that can
generate its own set of issues, e.g., a more complicated layout.

- Werner

[1] http://downloads.qi-hardware.com/people/werner/anelok/tmp/anelok-20131005.pdf



More information about the discussion mailing list


interactive