Hello @ricard !
I have a couple of these: https://www.sparkfun.com/products/retired/11733
Seems like a pretty simple matter of just making the connections from buttons to breakout, and breakout to axo, yes? On your control object I see "data, clock, latch, inh" -- do these equate to "serial out, clk, ce, and sh/ld" on the breakout?
Which of those need to be connected to the serial enabled pins on Axo?
Thanks for the help!
Yes, that should work fine.
Almost. 'latch' on the object goes to shift/load (sh/ld), and 'inh' on the object goes to clock enable (ce).
You actually don't have to connect anything to the clock enable line, as it defaults to the clock being enabled, and the object just pulls it low at init time and never changes it. The reason it's there at all is because the P6 hardware which I've used the object with has the line connected.
If you mean that you need to connect the data output from the 'HC165 to a pin which has a serial receiver, no, that's not necessary, you can use any I/O pin on the Axoloti. The object uses simple bitbanging (i.e. manipulates the I/O bits directly) rather than utilizing for instance an SPI interface in the STM32F427 chip.
If I were to not hook that up so I could use the pin for other I/O would it cause problems? Like -- won't the object be scanning whatever pin I select in the drop down?
I noticed in your P6 patch that you had some different bit values in your 165 read objects -- were they device specific, or required? I am trying to get 8 bool inputs like this:
Seems correct? I'll test it out more tomorrow with the hookups you noted. Thanks!
Yes, to use the Axoloti I/O pin for other purposes you need to remove the corresponding code from the object, i.e. the following two lines from the Init section:
palSetPadMode(attr_inh,PAL_MODE_OUTPUT_PUSHPULL);
palWritePad(attr_inh,0); // inhibit, leave 0 at all times to enable clockand then for clarity also remove the corresponding inh attribute. (I suppose I should have added "don't use" value to the list of pins in the drop down list so the object could handle this without modification).
Although principally not necessary for the 165 chips, one of the pins for the 595 chips in the P6 is connected to a port which is not available for general I/O in Axoloti. So I added it (PA8) to the dropdown (attribute) list for the 595 controller object and then re-used the list for the 165 objects even though it's not strictly necessary, as the P6 uses PA0-3 for the 165 chips which are available as standard Axoloti pins.
That looks fine, except that the output bits are numbered from 0 and upwards, i.e. 0 to 7, rather than 1 to 8. Actually, since the output register from which the bits are fetched is shifted when the bits are read in and never cleared, the patch as it stands will work as the bit numbers wrap after 'count' bits, but the bit numbering will be a bit confusing as the first bit will be 8 in the patch, followed by 1, 2, 3 etc.
you're such an OG for these, i was getting worried cause i need the SPI pins for ws2812 and thought i'm out of luck with my 165s...