100 MA Is a Myth

A lot of electronics ends up being connected to USB - whether they need computer or not. USB and its 5 V has became an unofficial standard power supply for the world. And thus it makes me crazy when I hear from people that you can only draw 100 mA from USB without going through USB enumeration else something horrible is going to happen. And that is bullshit.

Yes, there is such a thing as USB negotiation where each device can request certain amount of current from its host. Older USB devices could ask for up to 500 mA (in units of 100 mA) while USB 3.0 devices have maximum of 750 mA (in units of 150 mA). If you go higher than that, you get into the category of USB Power Delivery 3.0 and the beauty of multiple voltages we’ll conveniently ignore here, and deal only with 5 V requirements.

A misconception when it comes to USB negotiation is due to ability of USB devices to self-report their maximum usage and likewise the ability of chipset to say no if multiple devices go over some internal limit. Ideally, if you have four USB ports on the same power bus with total of 1 A available and you connect four devices using 300 mA each, three would get positive response and fourth one would get their request denied.

What might not be completely clear from this story is that bus has no means to either measure current or to enforce device’s removal. This whole story depends on the device accurately reporting its (maximum) usage and actually turning itself off if it receives “power denied” response. And yes, this self-reporting works as well as you can imagine it. As there is no way for computer to ensure either accuracy of data or device’s compliance everybody simply ignores it.

Computer manufacturers decided to save some money and not verify device’s consumption. So what if device that reported 300 mA is using 350 mA? Should you disconnect the device just because it uses lousy cable with a big loss? Why would you even care if that is the only device connected? What to do if that device just goes to 500 mA for a fraction of second? What to do with devices reporting nothing (e.g. coffee heaters)? Is nitpicking really worth bad user experience (my damn device is not working!) and is it worth extra cost to implement (and test)?

While there were some attempts at playing “power cops” in the early days; with time all manufacturers decided to over-dimension their power bus to handle more power than specification requires and simply placed cheap poly-fuse on it to shut it down in the case of great overload.

Such friendly behavior has culminated with each port of any laptop made in the last five years being capable of 1 A minimum. And you can test it - just connect data lines (or use UsbAmps’ high-power option) - and you will see you can easily pull 1 A out of something officially specified for half of that. And that is without any power negotiation - courtesy of the USB Battery Charging specification.

This leniency from manufacturers in turn generated a whole category of completely passive devices. Why the heck would USB light have a chip more expensive then all other components together just to let computer know its power usage? That is just wasting money if you can get power out of it whether you inform it or not.

Devices that have to communicate with computer over USB kept their self-reporting habits just because they had to use a bit smarter chips to interface the USB. And all those chips had to have power negotiation built-in to be certified. There was literally no cost in using this feature.

And even then they would fudge the truth. Quite often an external CD drive or hard disk would actually need more than 500 mA to spin up. And there was no possibility in the early days to specify more than 500 mA. So they lied.

Such (lying) behavior was essentially later approved with the USB battery specification that uses not an USB message but voltage levels as a limiting factor. It essentially says that you can pull as much as you want while voltage levels are high enough. Once voltage starts dropping, ease off a bit. This point can happen at 1 A, or 1.5 A, or 2 A - it all depends on power source/computer you are using.

Device manufacturers have become quite verse too. Since USB battery charging specification was done is hardware friendly manner, there was no extra cost to bear. Only task was to determine if computer supports the, then new, specification. If yes, pull current until voltage start dropping. If not, limit yourself to 500 mA. How do they recognize it? You’ve guessed it - by shorting the data lines.

Due to the powers of backward compatibility you can pull essentially as much current as you want from your PC. Yes, you are still limited by fuse (quite commonly 2 A or more per port pair), you still have thin USB cables and their voltage drop (with accompanying losses) to deal with, and yes devices - especially phones - will still self-limit to avoid tripping aforementioned fuse. But otherwise it is a wild west.

Unless you are making device that has to be certified, stop worrying about the power negotiation. If your device already has an USB transceiver onboard and you need to program it anyhow, go for the standard and configure current you need. But if you don’t have such chip or programming is just too much of a hassle, simply ignore it and world is not going to self-destruct. I promise.

RetroHat

Raspberry Pi is often used for retro-arcade machines. It really fits well there: low power usage, reasonable emulation software support (it is based on Linux after all), more then capable processor, and really cheap price ($35). It is hard to beat this.

What surprised me is that I couldn’t find proper Raspberry Pi HAT that could be used to treat buttons as a keyboard. Yes, there are guides how to setup buttons, but they don’t do auto-detection and require a bit too much setup for my taste.

There are also USB devices to which you can connect buttons but I find them a bit annoying to deal with in physical sense. While they do offer huge amounts of buttons, them sticking out of Raspberry’s side is always ugly to see.

What I wanted to build was maximum amount of buttons I can get away with using only natural HAT connections and without the need for any driver not available out-of-box. Of course, it should be a proper HAT with EEPROM, auto-configuring everything needed as soon as machine is booted.

First of all, with number of available pins on HAT connector it became clear there is a hard maximum at 24 buttons. Assuming 2 players, that comes to a joystick and 8 buttons (A, B, X, Y, L, R, Start, and Select) per player.

As HAT gives you quite respectable surface to work with, connectors for these buttons could also include a LED support at the cost of few resistors. Moreover, a discrete (fused) connector for both 5 V and 3.3 V rail was added. While neither is intended for heavy use, it comes in handy for powering various extra components in your retro-cabinet.

For keyboard emulation, this HAT uses a built-in support for GPIO keys. As long as you connect momentary button between GND (-) and pull-up input (S) it will detect each press as the transition from high to low and simulate the appropriate button. Default keyboard configuration is selected in such manner that player 1 configuration matches default RetroPie settings while all keys for player 2 are assigned numbers 0 to 9.

Of course, you can configure all this just by modifying retrohat.dts, a file whose creation took probably more time than board design, soldering, and everything else. But it was worth it to get auto-configuration running once EEPROM is programmed. To get more information on how to program the auto-configuration EEPROM, you can either go over read-me file or check how I did it for Cananka.

In any case, check project’s page for a short description and to find link to source files so you can build your own.

OshPark Vs PCB:NG

For feeding my electronics addition I mostly use OshPark. They have quick turnaround, excellent user service, and price is quite acceptable.

However, they are not the only game in town. Probably the best alternative if you are willing to wait a bit is unsurprisingly in China. Yes, I am speaking about Seeed Studio’s Fusion PCB. It is not exactly comparable to OshPark but it is close enough for many purposes. And it is excellent choice if you need different PCB colors - something OshPark doesn’t offer.

But times are changing and there is a new challenger on US soil - PCB:NG. They are PCB assembly house - something that is a bit too pricey in low quantities and something I personally never needed. But they do offer a possibility to order only PCBs.

PCB specifications are quite high-end: ENIG finish (I love this), 4/4 mil traces (vs 6/6 for OshPark), 8 mil vias (vs 13 mil), and they generally support cutouts and slots (although no promises here). As I generally don’t go lower than 8/8, I find them working equally well for my use case.

Price is $6 per inch for 6 boards, compared to $5 per inch for 3 boards OshPark offers - quite similar if you only need a few but PCB:NG wins at higher quantities.

Order process is simple enough and I had no issues with DipTrace 3.0 produced gerbers - something that might fail occasionally with OshPark (e.g. my PCB bear). I would say parser is definitely more forgiving with PCB:NG. I kept all file names setup as for OshPark and there were no issues. Your mileage might vary but I don’t expect anything unsurmountable as you can correct auto-detection yourself. And no, neither PCB:NG nor OshPark support RAR.

First thing you’ll notice when you get a board is attention to packing. There is a nice layering of red paper between each board and there is virtually no chance of them scraping one another. While I am not sure that matters as I never had any issues with loose boards arriving from OshPark, this does look a bit nicer.

What you will see after unpacking is a dark red colored board. I have ordered two within a few weeks and shade is a bit different. It is similar experience to year’s back when OshPark was testing other factories - I am sure shade will become constant very soon if it is not already. Just be mindful if you need exactly the same shade to order all boards at the same time.

All boards come fully broken out - unlike with OshPark where you can still see breakout tab pieces. Tabs themselves seem nicely defined and PCB:NG puts less of them than OshPark. Generally I have less work filing the rough edges then with OshPark. Somebody less nitpicky would be able to use them without filing altogether.

Silkscreen is not bad but white on red makes it less visible than white on dark purple OshPark uses. If you need good silkscreen visibility (e.g. user visible panels) you should probably go with OshPark.

I am not sure whether it was a fluke or standard practice but PCB:NG placed their custom markings on my silkscreen. This is something done by Seeed Studio and most low-cost services as it makes their process a bit easier. OshPark doesn’t do it and I was surprised when I saw PCB:NG doing it. However, on my second board I had no custom markings so they seem to have abandoned this vandalism.

When it comes to copper quality I can really say nothing bad about either PCB:NG or OshPark. Both have nice ENIG finish, neither had issue with traces or solder masks, both can handle hand lead-free soldering without much trouble. If there wasn’t a color difference, I wouldn’t be able to tell them apart.

For me it comes to two things. If board is meant for user visible panel (e.g. end panel for plastic enclosures) I find purple, almost black, OshPark gives fantastic look to a final device.

Where PCB:NG wins is price. As soon as you go over 3 boards OshPark offers, you are better off using PCB:NG. And, if you want some assembly, there is no content at all. PCB:NG is the one that offers low volume assembly.

As I usually do extremely low volume orders (often making just one or two devices) I will probably stick with OshPark. There is something to be said about familiarity. However, PCB:NG is a high-quality contender and worth trying out (remember 4/4 mil traces) - even at a fraction higher cost for a small volume.

Cananka, the Raspberry Pi HAT: Problems

[This the last post in the series.]

Mistakes? I’ve made a few…

The very first one was noticed after I’ve already sent order to OSH Park. For back-powering isolation where 2 A are needed, I used the same footprint as for 100 mA DC-to-DC voltage regulator. There is no chance of getting a part that would support 2 A in such a small package. I’ve replaced it with properly sized 1x1" isolated voltage regulator and contacted OSH Park support. As my original order was not sent to fabrication facility yet, I got it swapped with a new design without any additional cost. OSH Park support rocks!

While waiting for a board, I continued going over the design and thus I’ve noticed I’ve forgotten to pull-up the reset line. Uncaught it would cause chip not to function so respin was definitely needed. Additionally I’ve changed layout of board a a bit alongside making a slightly bigger cuts to allow for official case to carry the board. I find it amusing that HATs made in accordance with official specification don’t fit the official case. :)

What I didn’t catch was that my new DC-to-DC brick needs a bit bigger holes. It was possible to get DC-to-DC converter in the board but with a lot of elbow grease. Definitely not what you would want. I also didn’t notice I had damn pinout backward on one side of the chip. And guess what, since I’ve already sent for revision B to be manufactured, I couldn’t change it before revision C.

I did try to mod-wire the revision A of the board but important traces to cut were under the DC-to-DC brick itself so there was no approaching them - not with tight drill holes I had. Fortunately I was able to jump the missing reset line and thus have a proof of concept all is working well.

Revision B arrived when I was already preparing for next revision due to already mentioned faults and thus I have just populated the “cheap” part of the board. It made no sense to mount $25 DC-to-DC voltage regulator if I know it is not going to work. Revision C did have few other changes to silk-screen and other minor changes. Most notable change, outside of DC-to-DC pinout correction, was changing EEPROM to be write protected when WP jumper was soldered over.

Original suggested EEPROM circuit makes write-protection to be default. This means you need to connect the jumper to write chip and then desolder it later to make it read-only. I find it much easier on me if all chips start with being writable and then you make solder bridge to make them read-only. Additionally, as chip has internal pull-up, this means you save a resistor. :)

As revision C came, all seemed great until I tried power-back circuit - it didn’t work. Short troubleshooting later I’ve noticed my reading of remote on/off functionality was lacking a bit and thus I was missing connection of that pin to ground. With that single change power-back started working perfectly. Of course that meant revision D had to be made.

D? No issues what-so-ever. :)

Cananka, the Raspberry Pi HAT: EEPROM

[This post is part six in the series.]

What makes HAT a HAT is its EEPROM. While official instructions are lacking in details there are some forum posts and tutorials dealing with that issue.

In order to follow steps later in this post, we first have to install some packages:

sudo apt-get install git i2c-tools

For HAT EEPROM access we have to tell system to allow use of, usually inaccessible, I2C bus 0:

sudo bash -c 'echo "dtparam=i2c_vc=on" >> /boot/config.txt'
sudo reboot

Easiest way to see if we have set it up correctly is to probe I2C bus 0 for EEPROM at address 0x50 and see what we have there. We are searching device with ID of 0x50:

i2cdetect 0
i2cdump 0 0x50

To manipulate it any further we need to install EEPROM utilities from the Rasbperry repository:

git clone https://github.com/raspberrypi/hats.git
cd hats/eepromutils/
make clean
make

Before anything else is done, it is a good idea to clean out EEPROM:

dd if=/dev/zero ibs=1k count=4 of=blank.eep
sudo ./eepflash.sh -w -f=blank.eep -t=24c32

Now we are finally ready to actually create .eep file from our text config and upload it to EEPROM:

./eepmake eeprom_settings.txt hat.eep
sudo ./eepflash.sh -w -f=hat.eep -t=24c32
sudo reboot

If everything is ok, you should have directory /proc/device-tree/hat with product, vendor, and other files:

more /proc/device-tree/hat/product

But this is not where we want to stop - we want also device tree so that our CAN bus can get some auto-configuration magic. And frankly that whole concept is such a mess that creating it from scratch takes unholy amount of time. However, since CAN over SPI is one of the already existing overlays, we don’t have to do anything other than include it and flash our EEPROM again:

./eepmake eeprom_settings.txt hat.eep /boot/overlays/mcp2515-can0.dtbo
sudo ./eepflash.sh -w -f=blank.eep -t=24c32
sudo ./eepflash.sh -w -f=hat.eep -t=24c32
sudo reboot

Even if our CAN bus implementation didn’t match existing overlay completely (e.g. using different frequency), we could still use it as a template for our modifications. We would first dump it:

dtc -I dtb -O dts /boot/overlays/mcp2515-can0.dtbo > hat.dts

Once we have it in (semi) human readable format, we can change what is needed (e.g. clock-frequency) and then use the same flash procedure as before:

./eepmake eeprom_settings.txt hat.eep hat.dts
sudo ./eepflash.sh -w -f=blank.eep -t=24c32
sudo ./eepflash.sh -w -f=hat.eep -t=24c32
sudo reboot

Now you can remove all modifications done to /boot/config.txt and our interface will still appear:

ip -d link show can0
 3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
     link/can  promiscuity 0
 ...

With that, we have Cananka project completed and the only post remaining is to reminiscence over development problems.

Cananka, the Raspberry Pi HAT: Software

[This post is part five in the series.]

One of the requirements I’ve stated was that we should use as much of Linux driver defaults as possible. In this step we should reap benefits of that as all needed to enable CAN should be:

sudo bash -c 'echo "dtoverlay=mcp2515-can0,oscillator=16000000,spimaxfrequency=10000000,interrupt=25" >> /boot/config.txt'
sudo reboot

After reboot, we should see device loaded:

ip -d link show can0
 3: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
     link/can  promiscuity 0
     can state STOPPED restart-ms 0
           mcp251x: tseg1 3..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
           clock 8000000

When I was setting this for the first time I was brought on a wild goose chase as nothing really worked. No matter what I did, can0 device would not appear (Cannot find device "can0"). It took me a while to notice something is off:

dmesg | egrep "spi|can"
 spi_bcm2835: disagrees about version of symbol module_layout

As this Raspberry was used for other projects and I’ve updated it multiple times it seems at one point something went wrong with drivers. A fresh reinstall of Raspbian sorted that out.

More careful among you will notice that CAN interface is actually down upon boot. This is easy to correct and the only piece of data we need is the bus speed (this example will use 125 kHz):

sudo ip link set can0 up type can bitrate 125000

ip -d link show can0
 3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
     link/can  promiscuity 0
     can state ACTIVE restart-ms 0
           bitrate 125000 sample-point 0.875
           tq 500 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
           mcp251x: tseg1 3..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
           clock 8000000

Unfortunately this doesn’t survive the reboot. To make it stick just execute:

sudo bash -c 'echo >> /etc/network/interfaces'
sudo bash -c 'echo "auto can0" >> /etc/network/interfaces'
sudo bash -c 'echo "iface can0 inet manual" >> /etc/network/interfaces'
sudo bash -c 'echo "    pre-up ip link set \$IFACE type can bitrate 125000" >> /etc/network/interfaces'
sudo bash -c 'echo "    up /sbin/ifconfig \$IFACE up" >> /etc/network/interfaces'
sudo bash -c 'echo "    down /sbin/ifconfig \$IFACE down" >> /etc/network/interfaces'

For testing install can-utils:

sudo apt-get install can-utils

With them you can use cansend and candump, e.g.:

cansend can0 02A#FEED
candump can0

At this moment we have are HAT working. However, without EEPROM, we cannot really call it a HAT. So, guess what’s next…

Cananka, the Raspberry Pi HAT: Layout

[This post is part four in the series.]

The most difficult part of board setup is done for us - we have both dimensions and we’ve decided on components. Even better we don’t need to think about board much as our HAT specification has it all sorted out. Or does it?

If you make board based on HAT specification you won’t be able to fit official case around it. We need additional cutouts if we want it to fit - bigger on the left side and just a small one on the right. As board is not really crowded, it was easy to carve out the additional space. However, it might not be as easy for more dense layouts.

Top side is dominated by our DC-to-DC converter and nice 3.81 mm 4-pin CAN bus connector. Additionally there are through-hole LEDs so we can see activity and a through-hole oscillator purely because I hate SMD ones. To help with troubleshooting a few pads without solder mask are along the edge.

The whole board is essentially split into two parts. On top we can find components that can safely connect to Raspberry Pi. Most notable being MCP2515 CAN bus controller and 24C32 EEPROM needed for HAT compatibility.

Between CAN bus connector and controller we have isolation border crossed only by isolated DC-to-DC converters and ISO1050 CAN bus transceiver. Two millimeter spacing between these two universes should provide adequate protection.

It is a pretty straightforward layout mostly driven by the need to have isolation border and the size of the components.

Now, let’s get the board working.

Cananka, the Raspberry Pi HAT: Components

[This post is part three in the series.]

Usually behind component selection for any project there is a method in the madness. I will try to go through mine. :)

For the most visible part of board, we are going to need a nice CAN bus connector. I personally prefer Phoenix connectors for this purpose. As we are dealing with low voltages, I feel their MCV series is a great choice. It is a 3.81 mm pitch connector allowing for 8 A of current. Better yet, it is a two part connector so you can wire your plug in peace only connecting it to board once ready.

On the bottom we need to have a 40-pin female header. Final distance between our board and Raspberry, per specification, has to be 10-12 mm. However, that doesn’t mean your header has to be that high. Male header on Raspberry is already 2.5 mm. As long as our connector is between 7.5 and 9.5 mm, all is good.

First electronics component is easy - in order to satisfy HAT specification we need EEPROM for our settings. Here we pretty much take recommended circuit and roll with it. Maximum current CAT24C32 will take on write is 2 mA from 3.3 V rail.

Component selection is primarily driven by requirements and rarely we can see it as clear as here: As we need existing Linux driver to support our board, we are pretty much boxed into selecting MCP2515 as our CAN controller. Another obvious choice would be SJA1000 but that one is a few times more expensive. As Raspberry header pins are using 3.3V signal level, we will power it from 3.3 V rail in order to avoid level translator. Maximum of 10 mA will be used from 3.3 V rail.

Clock for MCP2515 can be up to 25 MHz but I’ve decided upon 16 MHz as this figure fits nicely with Raspberry’s divisor controlling SPI bus. It wouldn’t hurt to use higher clock-rate but 16 MHz is a value I use often in another project so I had component handy.

For CAN bus we also need transceiver and of course there is no single answer on which to select. For isolation we can go either with a dedicated isolator (e.g. Si8421 paired with MCP2561) or we can use one of rare isolated CAN bus transceivers.

As isolated transceiver already needs two power supplies, we can avoid level translator and keep each side on its own preferred level. Signal side will be powered on 3.3 V and CAN bus side will be on 5 V. One device that matches these requirements is ISO1050. Not exactly cheap but not too expensive considering it is all-in-one solution. Maximum current of 3 mA on 3.3 V side fits well within our restrictions. On its 5 V side we need 75 mA maximum from the isolated 5 V rail.

Typical application circuit for ISO1050 also mentions additional protective diodes and we shouldn’t forget those too. Searching for basic two-channel TVS diodes supporting 30V and above (in case we get to work with 24 V CAN bus) PESD1CAN comes as a first choice. And guess what NXP tells intended usage is? Yep, CAN bus protection.

There is a big chance we will need to terminate our CAN bus with 120 Ω resistor. For this purpose a place for two 1206 resistors is available. Combined this allows for about 1 W power dissipation, depending on the exact resistors used. Considering transceiver short-circuit current is 105 mA at 12 V, we are cutting it a bit close for the worst-case scenario. But, as such peak currents are not going to last for long, even at 24 V this should be sufficient.

My plan is to use nice Phoenix connectors and simply get through-hole resistor next to the wires. ISO 11898 even recommends such cable termination since that way you can disconnect node without impacting bus. What I definitely don’t want is header or DIP switch controlling this.

Speaking of which, in order to power up our 5 V goodness, we need isolated DC-to-DC power converter. Many of them come in 4-pin SIP interface and can be directly substituted for one another. I opted for ROE-0505S as it is cheap, small, uses standard pinout, and 200 mA it offers is more than sufficient for our needs. It is a bit finicky at low currents so we should put a LED to waste some of that (e.g. 15 mA). Taking into account its efficiency of 79%, we will use around 110 mA from Raspberry’s 5 V rail.

To power Raspberry Pi from CAN bus power, we get to use another DC-to-DC converter. Unfortunately Raspberry Pi is a hungry beast so we must get into bigger and more expensive choices. After taking literally every DC-to-DC converter capable of producing 5 V / 1.5 A from 12 V source available at Digikey and getting theirs pinouts, I’ve noticed essentially two groups with a few outliers. First group was of devices measuring 32 x 10 mm. These devices run around $25 and all share same pinout (e.g. JTF0824S05). Another group came in 25 x 25 mm size, sharing the same pinout, but unfortunately at a slightly more expensive $30 (e.g. JCM1512S05).

With board measuring only 65 x 56 mm, both would fit, but square one would be much easier to place due to camera slot so I’ve decided to go with that. While those are more expensive devices, for some reason they offer higher current output than their rectangular cousins so 2 A is the norm here. Fact all devices in this group use the same pinout means it will be easy to find replacement if original choice (S24SE05002NDFA in my case) becomes unavailable.

We also need a simple 2 A fuse on power-back circuit together with an ideal diode circuit as recommended by HAT specification. As with any DC-to-DC converter we have to keep minimum load in mind (usually around 10%) but Raspberry Pi is hungry device so we can ignore it this time. Even if we do not meet it, nothing bad will happen as only effect is that supply will go out of spec. As Raspberry Pi doesn’t use 5 V directly but goes over another DC-DC converter, we are safe even in sleep mode.

For those wondering why the heck we are accounting for each mA, answer lies mostly in Raspberry Pi header and 3.3 V rail. Maximum current we should pull is around 50 mA. Anything more and you might make for an unstable system unless you use a separate voltage regulator bringing beefier 5 V rail into play. On 5 V rail we are pretty much only limited by power supply used. If using normal 2 A supply, you should have round-about 500 mA available provided there are no hungry USB devices connected. If you kept with accounting, we have 15 mA usage from 3.3 V rail and 110 mA on 5 V. Well within the spec.

Onto the board.

Cananka, the Raspberry Pi HAT: Requirements

[This post is part two in the series.]

Signalling-wise you can see CAN bus as 5V based but its automobile roots make 12V supply voltage quite common and that is what I am actually using at home. Annoying thing when using 12V is that every CAN board has to drop voltage to 5V needed for logic. Good thing is that you are carefree with longer cable runs. When using 5V, even drop of 10% is a problem and 12V can give you much more breathing room.

Considering I will connect this device to the potentially harsh world, it would be splendid to have its CAN bus portion completely electrically isolated from the Raspberry Pi board. Therefore it will need a major screwup on the input interface to take Raspberry to its death. As CAN bus can span quite a lot of distance and you don’t know all components will be on the same power circuit, this will also help to deal with ground loops and all those different potentials.

Having CAN driver isolated also means we have to power it from somewhere. While my “slave” devices obtain power from the 12V line, for HAT I’ve decided to go with on-board DC-to-DC converter. This makes my device essentially compatible with any CAN bus, regardless of its voltage. Removing external power from consideration also makes it less likely to have a outside high-currents flowing around.

Of course, it would be nice if we could power Raspberry Pi from our CAN power rail. Since isolation is name of the game, we need DC-to-DC converter capable of at least 1.3A (preferably 2A) at 5V. As these modules are usually expensive, this has to be optional part. And yes, back-powering device should be safe even if user forgets to unplug it from USB.

On mechanical side, in addition to HAT basic requirements, possibility of having the HAT on while Raspberry Pi is in the case would be desired. Official case is preferred but other cases should be taken into consideration. This will greatly limit component placement and it could even impact size as, on the first glance, the official HAT dimensions might be a smidge too big for the official case.

On software side it would be ideal to make a board compatible with existing CAN device driver already present in Linux. Default settings for device should be as close as possible to defaults used by that driver. While creating your own driver is possible and not that complicated considering simplicity of a CAN bus, it makes a little sense to create something you will have to compile every time when new OS is installed if you can go with something already present in the kernel.

Onto the component selection.

Cananka, the Raspberry Pi HAT

[This the first post in the series.]

As I got myself a Raspberry Pi, I started thinking about connecting some electronics to it. And in Raspberry world you can either just connect some wires to connector or go about making a HAT.

Raspberry Pi HAT specification defines both mechanical properties and a minimum of electronics while still allowing you to do whatever you please with available IO. Pretty much the only strict requirements here are board size (65x56 mm), hole placement, and presence of a special EEPROM with board identification data. A bit more complicated than bare wiring but simple enough.

Armed with knowledge of what’s needed, I had to decide what I’ll actually make. As I played a lot with CAN bus lately, it seemed as a reasonable choice. Not only I go with something familiar on a first try but I get to connect it to the rest of my humble CAN bus world.

Early into the project one has to decide on a name. In this case the name was obvious - Canberry. Unfortunately it was obvious to someone else too as there is already a project with that name. Lesser man would give up here as not only the name is taken but it is taken by a really similar project. However, project is not exactly the same and differences will make exercise worth-while.

With the preferred name taken, choice fell onto CanPi. Guess what - there is also project named CANPi out there. One guess at what it is about. :)

For a while I’ve settled onto Can314 and actually used it for a few days in my notes until, unrelated to electronics, I was playing with Red Hat. Suddenly its younger sister Fedora came to mind. As fedora is type of hat, what else to call Raspberry Pi HAT than Candora. Name seemed good for a while but I wasn’t completely happy.

However, now I had an idea. With the help of Wikipedia hat page I’ve came upon a few other names inspired by hats: Canbeen, Canullo, Canetto, Canouch… just to name a few.

But at the end Cananka, a name based upon Russian ushanka hat, won. Not only it is easy to pronounce but Google only finds 7100 matching pages.

With the name selected, onto the requirements.