• Not every thing that has a lot of lines and pins you want to drive with Espruino has a smart controller built in, such as 1-Wire, SPI, I2C,... Often there is computing power left on the 'central' MicroController - where the application runs - to take on the role - and work - of this smart controller. No need to add specialized hardware.

    There are multiple options to drive something with lots of pins and lines to drive with 'scrificing' just a few Espruino pins:

    The port expanders are great, they even are able to manage interrupts in different ways - and Espruino has even a simple module to talk to those (not supportiong interrupts though - yet). When it though comes to simple output (and even input), a shift register is good enough. And actually, Portexpanders fall under the category of specialized hardware, because - the mentioned MicroChip - includes a full blown I2C or SPI controller - like a satellite/moon controller of the application driving controller.

    To drive, for example a simple LED matrix, a few stringed 74HC595 can do the job - complemented with a little bit of smart software. RYO of such a construct can be tough, but at the same time it is a great teaching moment. It helps to understand and appreciate what's going on when having to pay for, for example, an easy to use display module, supported by an existing Espruino JavaScript software module.

    This whole conversation got triggered by this forum question from @user81779: Is it possible to connect this 8x8 RGB matrix to espruino boards?. The post has pictures of the kind of LED matrix @user81779 wants to use, which I add also to this post. The post also includes some suggestions how I would tackle the task.

    Pure RYO from end-2-end is fun, but time consuming, and sometimes it is more interesting to take two invented wheels and come up with the glue to get them work together nicely.

    For this conversation I have only one wheel and some parts of the shelf to use, such as Espruino Graphic Class and a few 74HC595. (I could also RYO the 595... but may be another time ;)...). The other wheel is only quasi of the shelf. It is of MY DIY Collector's shelf back from the outgoing 70'... see the picture... I built and explored it with an 8-bit Intel 8085 4Mhz German Engineered Dev Board with 256 (256!) bytes of SRAM for the program and 1KB (1024 Bytes) ROM Monitor. It had 9 inputs, 9 outputs, a hex keyboard, 6 7-segment displays to display code address and machine instruction code, and it did cost CHF/DM500 - about $280. Though very powerful and unseen, it was that cheap because the 'maker' - as we would say today - used a lot of brain - including time multiplexing for both the display AND the keyboard- in the monitor (operating system) to avoid having to buy and use expensive IO devices. Last but not least, the 6 7-segment display was completely multiplexed with just two 8-bit parallel gates at decoded IO addresses... but enough of nostalgia...

    I built this 3x5 LED matrix with 15 small red LEDs and could explore the multiplexing in the code.

    The plan is now to build first some logic and 'compose' some hardware to display on the LED matrix what is in a suitable display buffer.

    Next step will be to 'connect' the Espruino Graphics Library with this display buffer... E voila! We have what we wanted, and because we built it step by step by ourselves, we can adapt it to similar things.

    Adaption in reuse is mainly not in the big outline, but in the details and scaling (making it work for more than 8x8 matrix).

    For example, the display @user81779 wants to use, uses RGB LEDs, and what I can read from the available documentation, the data lines are not LED (Pixel) but Color bundled. Most displays store the information for one pixel (LED) in a piece of contiguous memory / bytes / bits... For example for a display with color depth of 3 (to support 16 colors), there is a 1 bit for each color Red, Green, and Blue - makes 3 bits - and they are stored next to each other. The display @user81779 mentions seems to do it differently: to lighten up a row or column of LEDs / Pixels, first all Red bits have to be sent, then the Green ones, and then the Blue ones... That's wha Im reading from the Raspberry PI code referenced in @user81779's post. Why I deduct so is because of line 24 which includes the complete heart shape... in 8x8 bits - 1 byte - and all others are constant (not even a buffer). You will understand when it comes to the wiring and the turning on and off of bits to lighten up pixels or to keep them dark.

    Even though this display goes that path, I want to start out with the usual approach of storing all information next to each other.

    To be continued...

    5 Attachments

    • M3x5FrontR.jpg
    • M3x5BackR.jpg
    • SN74HC595.png
    • M8x8BackR.jpg
    • M8x8FrontR.jpg

Avatar for allObjects @allObjects started