Go

After sticking with C# and its ugly step-mother Java for a while, I though it was a time to check out a new language. One that seemed interesting was Google’s Go, a simple garbage-collected, strongly-typed, and C-like language supporting Linux and Windows.

Go syntax itself is really friendly and suits me well. There are only a couple of statements around and you should know them from C, semicolon is optional at many places, and in-place variable initialization is a treat. Yes, x := 5 is not really superior to var x = 5; nor it saves you a lot of keystrokes. However, syntactic sugar is what makes or breaks a language in my opinion. And such lazy variable initialization is nice to have.

Cross-compilation is reasonably easy with just a few environment variables (GOARCH and GOOS) that need adjusting. As it is statically linked, you can count on having no additional dependencies whatsoever. One binary is all it takes. Yes, binary is a bit bigger even for the simplest of things but I’m perfectly fine with that if I can avoid .dll hell.

Speaking of compilation, it is annoying. Compiler is simply too aggressive with warnings. Great example is if you initialize variable and you don’t use it later. Damn compiler will complain and refuse to do its work. If you have unused import, the same thing. It will simply stop at any warning. One might say this is the correct behavior and that it will help you to write better code. That hypothetical guy should burn in hell next to guy who created this compiler.

Since proper debugging tools for this language are nonexistent, you are pretty much forced to use generous peppering of printf statements throughout the code together with liberal commenting out so that you can pinpoint the error. And guess what happens as you debug it? Damn compiler refuses to work just because I am no longer needing one variable I used for debugging or because I am importing package use of which is currently commented out.

And those are errors compiler correctly identifies and it could correct itself. Variable not used? Report me a warning because it might be me making a typo but compile the damn program so I can continue to debug. Same for extra package - if you are so smart to report it is unused, remove the damn thing yourself and compile. It is impossible to describe how annoying these warning are during writing and debugging of program. ANNOYING.

Syntax of Go is mostly pleasant with a couple of weird decisions most notable of which is to have variable type after the variable name, as in func x(dummy int). While designers do offer an explanation, to me frankly it seems as changing stuff just to be different. Yes, it might be more correct way of doing things but it goes against muscle memory of every developer on earth. Same goes for decision to use nil instead of null. Why?

Go is not object-oriented language and I am not really sure how I feel about it. A wonders can be done without full OO support, especially when it comes to small tools I was using it for. What I was missing were two features usually connected to OO languages.

First one is syntactic sugar of method calling syntax. I find myStr.TrimSpace() as superior compared to strings.TrimSpace(myStr). While they can both serve the same function, I find former much easier to both write and read. I sort-of expected Go to have something similar to C# extension methods where you essentially just use OO syntax for non-OO concept.

Second is method overloading. Yes, I know Go creators have excuse for this too. Who knows, they might even be technically correct. However, the need to have slightly different name for each method taking similar parameters is annoying. Have they allowed optional parameters maybe I would feel different about it but, as it is implemented now, I find this decision hurting the language.

Lastly among complaints is lack of globalization features throughout the language. It could be at least partially due to the lack of overloading but all globalization features feel as an afterthought and not as the part of language. Good luck localizing this.

As you might have guessed, I don’t find Go a particularly well designed language. I do like some of its features (especially the ease of cross-compiling) but general discomfort during development will keep it as tool of choice only when I want a single binary with minimal impact to the rest of system and not for much else.

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.

Visual Studio in Small

With Visual Studio 15 release getting close, a lot of new features are seeing the light of a day. One feature that doesn’t get deserved attention is the new installer shown to the world on Build 2016 conference.

It is a simple and tiny (in Visual Studio terms) installer. Executable is under 1 MB and it gets all other components from the Internet. On its own it is not a news, but some optimization magic has been happening there so your downloads are reasonably small (again, in Visual Studio terms). I am sure as release day grows closer some things might gain some “fat” but idea is there. I just hope they will still allow you to install it from media too - having Visual Studio download itself multiple times for multiple computers kinda nullifies smaller downloads.

You can give it a test run yourself and see whether it improves your workflow.