• PS: will test the code when I get a display... ;-)

    ...was a hint looking for a sponsor... ;) - and kind of says: sorry, have (had) no chance to test... of course, I could make a dry test: print the bits I'm passing to SPI1.write(...), but that part I actually already use successfully as outlined below.

    I'm tinkering along on a different display 'project' as possible 'sub-project' or 'explorative project' for an other, larger project. Im tinkering with a retro display: National Semiconductor 12 digit 7-segment, red LED Bubble Display NS A5120A (see attached pic) - as found in many pocket calculators in lat 60/early 70 - about $2K a piece was HP's first usable/scientific pocket calculator.

    I use 3 595 shift register in series. The last one sources the 7-segment plus decimal point anodes, and the 12 bit of the 16 bits of the other two drain the common cathodes for each digit... since the shift register drains a measly 6ma on 5V, I'm already in trouble with just 595 and may need to add 12 transistors to reliably drive all segments plus decimal point of a single digit all at once... another 2 chips of ULN2703 or 12 plain transistors w/ 12 Base resistors (the issue is obviously not the driving of the cathodes, - otherwise you could not see the digit lit - but more so the reliable shifting on higher speeds to 'hide' the multiplexing from the slow eye. The heavy drain load makes the latching register not to behave nicely anymore...).

    The setup you see in the picture uses an Espruino-Wifi, which is more or less a Pico w/ onboard ESP8266 (latter here not in use right now even though the blue LED dims...). Also you see that only the drains of tje first 3 digits' are hooked - hidden under the white-blue-striped segment wires (Ran out of common cathode resistors from my reuse-pile... or rusty nails I keep for ever... ;) ...to the dismay of many around me...). I avoid the E.byteReversed() in digit's common anode driving, so think reversed. You see only 1 digit displayed because the digits are time multiplexed with very low frequency.

    The SPI1.write(...) that produces 'this' output is equal to:

    //          Segments   12 Digits, 1st is 'on' (=0=drains)           
    //          for 5 on     -------   ---1 
    //          595 right  middle    left
    //          latches    latches   latches
    //          1st byte   2nd byte  3rd byte
    //          receives   receives  receives
    //          data last  data 2nd  data 1st

    Regarding the SPI write with nss pin passed: SPI slaves requires the slave select line to go and stay low - hence called - nss (negative ss) in order to make a slave look at data on the bus (MOSI - Master Out Slave In wire) and detect when the transmission transaction is completed: ssn goes high. You can control ssn by yourself separately, such as B0.reset() (assuming ssn connected to B0), then do multiple sends with spi.write(aSingleByteOrAnArrayOfBytes); and conclude the 'transaction' with B0.set(). For convenience, @Gordon implemented the spi.write() with nss in addition to accepting an array of bytes and not just a single byte - lest to talk about multiple pins - so that when you have all of your things to send ready-made in one byte array, you just need one call - which makes thing just crazy fast, because it is executed 'down deep in the belly' of Espruino all at once rather than in piece meal, spoon fed...

    1 Attachment

    • NSBDd51R.jpg

Avatar for allObjects @allObjects started