Moka

About a week ago, I was looking for something to do... And I decided I would come back to this project, and see what was needed to finish it.

There were two things I wanted to improve.
The first one is that I forgot to put a diode before each button, so there were phantom pushes... not a big deal, even if there is not that much room left on the board.
The second one was that I find the pad from Adafruit to be a bit too hard to push to make it comfortable to use as a musical instrument, so I was looking at a way to design my won silicon pad.

I was wondering if maybe Adafruit could have update their pad in that way... And the ndiscovered that they have just made the NeoTrellis, which does... exactly what Moka does.

So, time to move to another project ! :)

Do you remember that previous log where I was talking about the SK6812 pinout? I was surprised to see two different pinouts for the same led...
When I did the first tests on the boards I've received, I couldn't succeed in programming them. The Arduino used as ISP was shutting down when connected to the board. I didn't have much time for further testing, so I put it aside for a few weeks. It appeared there was a short somewhere on the board, with ground and VCC being tied together. And it soon appeared that it was coming from the leds, because when not mounted I was able to upload the program.
And the problem was of course these leds' footprint. In fact there are two different one, one for the 5050-sized leds, and one for the 3535 ones. And of course they don't match, unless you turn the led 90°, but then the leads are not exactly matching the pads on PCB. So by turning leds around 80° instead of 90, I was able to test boards!

A new batch of newly drawn boards have been ordered today. With a few other minor corrections... Wait and see!

I've been in the process of writing code for the board for two days now.

First part is of course the code that will run on the board. I spent some times looking for something efficient for I2C communication. Usually I2C is used with chip that do a special job (like driving a led matrix, reading light intensity, etc.), and have registers that you set and read, whom are described in the datasheet. But the Atmega 328p that is the main components of most Arduino and this board is an "empty" component. So registers have to be write from scratch. And as it could be up to 32 boards running together, communication has to be quite efficient!
I've tried to distinguish led and buttons reads for more general commands:
Commands addresses are composed of arbitrary bits. In order to save bandwidth, when a setting has a boolean as parameter, the parameter is included as the LS bit of the address. An example would be Display state turned on when sending 0x01100001, and off whe nsending 0x01100000.
Led and button addresses are composed of the four MS bits designing the setting to modify, and the four LS bits corresponding to the led or button ID. That way we can save one byte of data for each command.

Each SK6812 led needs three bytes of data to set their three colors. One for each of red, green and blue. But as this is an interface and not a display, maybe having that much color isn't a real need. So the color can be handled in two ways. The heavy one is to set the complete color for each led. When updating a whole panel you got 72 bytes going from control boad to Moka. But there's a lighter way to manage color: having each color set on two bits, you can have 64 colors, and that left two bits unused. So the lighter mode is to define a color with a 0xAARRGGBB byte, with an alpha channel. So intensity can be set for each color. The I2C is happy with only 16 bytes to update a whole panel, and the program running on board computes corresponding value for leds when receiving commands.

Another big deal is the led data stream: these leds need a waveform that give both the bit stream and the clock reference. Each 1 is to be sent as a 0,6us high level followed by a 0,6us low level, and each 0 is a 0,3us high level followed by a 0,9us low level. Running ont he internal chip oscillator at 8MHz, a low level is 2,4 clock cycle. So that part has to be really efficient! Adafruit and pololu have libraries for driving this kind of led, and both use direct ASM programming for that purpose. I hope I can rely on PWM for that. For each cycle I have to update the PWM value according to the bit to be sent, and I don't know if it will be fast enough. I'll give it a try when I will receive the leds. If not, I'll have to learn ASM!

The other part of code is of course th library users will use to run the Moka board. I've started to work on it today, but this part is easier.
For now it can handle a board, with all necessary functions implemented. One can set a led color or brightness (that is linked to color, as explained above), read switch, update display. The I2C can be set both normal (100KHz) and fast (400KHz). I hope it will be fine, but I've never had problem on Arduino running fast I2C.
Color can be set for one led of for global panel, thus saving data stream.

The next step is to create a global object that handles all needed board has a big one. I'll look at it in the days to come.
And the step after will be to port a library I had written for Trellis to this board, that handles a virtual pad larger than the physical one, trough which we can move. As if the physical pad was a window openned over a larger one.

But for now, I'm gonna go to bed. :)

The github repositories have been updated, feel free to share your toughts.

I've spent half a day redeisning the boad, because of a wrong led pintout. Can you believe it? If you look for "SK6812" in google, you will find two pinouts. I've stuck to the one of the datasheet that is chared by Adafruit for their Neopixel. Hoping that it will be fine.
A few hours to design a logo for the board, because it's soo cool! And another half day to understand how a svg file can be imported in Kicad. It's a real pain to do! Kicad has dxf import capability, but can only manage lines. There are scripts for Inkscape to export such dxf, but I couldn't have it run... I eventually realised there is a module in Kicad that transforms an image into a footprint. But it took another hour to figure out that this module can open png files (the only image file type you can export from Inkscape), but cannot make a fotprint out of it.

So, svg to png in Inkscape, png to jpg in Gimp, jpg to footprint in Kicad, and in the end I have nice silks on my board!
And I could order a batch of prototypes! :)