Last update on .

There's an expression to the effect that a picture is worth a thousand words. Maybe it's true and maybe it ain't, but if it was true, and you had to document something, wouldn't you consider doing the maths and reaching for a camera, instead of the keyboard? And if a picture is worth that much how much is a video worth? If a picture is worth a thousand and I encode a video at 25 frames per Second then is a video worth 25,000 words per Second? Now that, if true, is a no brainer, in terms of maths and keyboard time. Having said that if you compared the word count of your favourite book to the seconds of video then words are probably much more valuable. The Lord of the Rings, for example, 481,103 words equates to less then 20 Seconds of video! Not my favourite book, but I'll take the words.

Regardless of tenuous maths, video is a great communications medium, and given access to readily available Software tools, vlc, simplescreenrecorder, and openshot, And a publication portal like Youtube, this is a great time to be documenting something, even a hair brained scheme to re-wire a tractor! And thus another Youtube channel is born.

The electronicSoup Youtube channel

If I was working for a regular company, (whatever that is), developing a product, then at the end of development process I'd publish the documentation necessary to sell that end product. Maybe there'd be very little actual real documentation published, (some things have to be secret), and the majority would be guff from the marketing department. (Don't knock it that guff works!) Fortunately I'm working for my own company, and for this hair brained scheme, (Global Domination 1.0) I can document the journey, not just the destination. I can document the destination if and when I get there, but for the moment I can document the journey.

Now as you might be able to surmise the written word ain't my forte in life. So let's take the easy way out and communicate with moving pictures and spoken word. So now having said all that lets just stop typing and let the videos do the heavy lifting.

Episode 1 - Hello cinnamonBun

This was my first cinnamonBun, or the version which I thought was ready to go. That was until I was doing some contract work on a boat and encountered a NMEA 2000 (Nautical CAN Bus) based GPS system. I've mentioned it in a previous post, but just in case you missed it, the GPS system flooded the CAN Bus with the current location of the boat, stationary and tied to its mooring. It was basically the CAN Bus equivalent of a Denial Of Service Attack. So my cinnamonBun, based on a PIC24FJ256GB106, couldn't keep up with the traffic on the bus. So after this video was uploaded a redesign ensued.

In spite of that the video simply went through the creation, flashing and execution of the classic embedded "Hello World" project. Basically the first step in bringing up a new embedded system, can I get any evidence of life out of the device. So a simple circuit with one input pin and one output pin using the input pin to set the logical value of the output pin. The code couldn't be simpler:

#include <p24Fxxxx.h> int main(void) { /* * set pin RE0 as an Input pin */ TRISEbits.TRISE0 = 1; /* * Set Pin RE1 as an Output Pin */ TRISEbits.TRISE1 = 0; while(1) { LATEbits.LATE1 = ~PORTEbits.RE0; } }

It's possibly unfortunate that that early version of the cinnamonBun got superceded, retired or simply axed due to lack of computational power, but I've left the video in place, on Youtube, as it's the same process for the later micro-controller, and this is one step on the journey.

Episode 2 - Hello Again

And so to the dsPIC33EP256MU806 micro-controller. This little beauty is capable of up to 70 Million Instruction per Second! If that can't deal with a Garmin based Denial Of Service attack then what can? Like the previous cinnamonBun's PIC24FJ256GB106 this is a 64 pin device, so the layout of the board could remain more or less the same, and has 256KB of Program Flash. On the plus side the dsPIC33 has CAN Bus controller built into the device, whereas I had to add an SPI based CAN Bus Controller to the PIC24. That saves a bit of PCB space. After that it's going to be a case of porting various libraries of my code to the new device. I'll get to that in time.

After that the actual process of creating a MPLABX project, the code, and flashing the device is pretty much exactly the same. The only gotcha is the default configuration of Analog Input pins, which catches me out now and again. I'm getting used to that one.

#include <xc.h> int main(void) { /* * set pin RE0 as an Input pin */ ANSELEbits.ANSE0 = 0; // Set the pin to Digital mode TRISEbits.TRISE0 = 1; /* * Set Pin RE1 as an Output Pin */ ANSELEbits.ANSE1 = 0; // Set the pin to Digital mode TRISEbits.TRISE1 = 0; while(1) { LATEbits.LATE1 = ~PORTEbits.RE0; } }

So that was the first two videos, spaced months apart. Hopefully I can now build up a head of steam and become a more regular contributer.


Pingbacks are closed.



Comments are closed.