So. i used site and did filtering against “push/pull”
so cost then is a wash. but if these can be setup to “push” .. seems way cleaner then a pull / scan logic A3144
Is their any reason I cannot use my already purchased MCP23S17-E?
Each one requires a 0.1uF decoupling capacitor. So now you need to solder in 576 capacitors puls the ones for the MCPs.
Appreciate your input.
What I hear is
-
A3144 with a pull logic will have a lot more issues in managment of noise and scan cycles and overhead on arduinio to scan, especially as I add to the board the “game logic”.
-
use of DRV5032DULPGM is valid. Is in alignment with push concept. Will significantly reduce the overhead on Arduinio. Downside is for each sensor I will need to wire a 0.1uF ceramic capacitor (Amazon version , Digi-key version.
-
Use of my already purchased MCP2317-E will work. Are usable for this. And logic of creating banks sharing MOSI,MISO, SCK. With each “array” of 8 MCP consuming a Digital pin on Arduino. Five total arrays are required for the 24x24 matrix.
For the two board I have that lean heavily into LED + Hall Effect Sensor:
Cost to change:
-
0.1uF ceramic capacitor (Amazon version $70, Digi-key version $157)
-
Push Hall Effect Sensor DRV5032DULPGM (Digi-key version $191)
-
If I can re-think how to solder up and use SL1623SH, and validate its size is same as A3144, I can drop cost down to $90. But I think I would still need the capacitors.
Let's get the terminology straight.
The A3144 is open-collector and the DRV5032 is push-pull.
With each “array” of 8 MCP consuming a Digital pin on Arduino.
You still do not understand how the MCP23S17 works. Each IC requires a seperate CS.
Appreciate your experience and input.
DRV5032 is push-pull → so is my selection of DRV5032DULPGM valid? On paper yes. But unlike Amzon with free return.. I can order batch of a dozen and test then send back or order more and get next day.. Digikey is 2-3 weeks and delivery/return cost. So trying to do better logic validation.
As for the MCP thread: The MCP23S17 datasheet (Section 3.2, SPI Interface): The control byte sent over SPI includes the device address bits (0100 0AAA, where AAA matches the A0-A2 pins), so when CS is pulled low for a group, all 8 devices in that group see the command, but only the one with matching A0-A2 processes it and responds (e.g., driving MISO for reads). Non-matching devices ignore it and keep their SO pin tri-stated to avoid bus conflicts.
Googled around and though not same found:
- Arduino Forum Post (): In a discussion about using an SD card and MCP23S17 on the same SPI bus, a user notes: “The MCP23s17 is a little different, has three address pins that allow up to 8 devices on the same chip select line if properly enabled.” This confirms the datasheet’s claim and aligns with your design.
- Practical Example: The Adafruit MCP23017 Arduino Library (while for I2C) has a counterpart for SPI in various community libraries (e.g., Rob Tillaart’s MCP23S17 library). The SPI version supports multiple devices with different addresses on one CS. An example sketch from the Arduino community () discusses wiring multiple MCP23S17s with one CS pin, setting A0-A2 differently (e.g., A0=+5V, A1=A2=GND for 0x21).
Well I never used that mode, learned something new. Have you confirmed that it actually works?
Neither have i.
But lets figure it out together.
Do you have thoughts and input on the hall effect sensor and 0.0uF capacitor? To make that order I may as well go all in and buy 1200 of them. So I will have to get the kitchen pass for that one 
, and that a push vs pull will set me up better.. seams resonable.
When it was pull. I guess it made more sense to me that the arduinio would “activate” the “group” of 8 MCP ( ex: CP0) and when that digital pin is selected. then it has to send sigal to focus which MCP within the chain it calls A0-A2 to note MCP0-MCP7 , cycle scan on all sixteen inputs. Then move on to next MCP on chain, then once that chain done toggle that chain “off” and go to next chain of CP# till all five done, then cycle back.
This logic made sense to me, and the issue would be more of could it run that cycle fast enough to make the game playable real time.
But.. now with a push… how does the MCP say to the arduino. “hey.. i have a sensor state change.. I need to tell you about…
and wht if another group has an update also at same time. do they toggle on/ off as soon as it sends “here is sensor with state change.. quick .. go back off so someone else can chat…
There are two ways of doing this. The first is to use interrupts. An interrupt will stop what the processor is currently doing and an "interrupt service routine" will be evoked. You have to write the interrupt service routine your self. The success of this will depend on how many interrupt triggers you have on the processor you are using. Some processors like the UNO R3 only have two pins, but others have all pins capable of generating them.
If two interrupts happen at the same time ( as Einstein proved there is no such thing as the same time but let's gloss over that fact for a moment) the one with highest priority will be triggered and what that is finished the next highest one will be done.
The other way of doing this is by polling, that is by periodically looking at the sensors. You will need to implement a state machine in software to do this, Look for things like "how to do two things at once" tutorials there are lots of them on this forum. Which this system you can set in milliseconds how often you want to look at your sensors. The priority will be controlled by how often you look and what you have just looked at.
But lets figure it out together
Well there is a bit (IOCON.HAEN) that needs to be set in order for addressing to be enabled by default it is disabled. However, since you have all CSs connected together, you will be accessing all 8 ICs at the same time before that bit is set and that is contrary to how SPI works using CS. It could work I suppose but I would definitely test before going any further.
Do you have thoughts and input on the hall effect sensor and 0.0uF capacitor?
0.1uF is the minimum, you may need larger depending on your layout, you may also need extra bulk capacitors (100uF) again depending on the layout.
could it run that cycle fast enough to make the game playable real time.
You would need to send 2 bytes and receive 2 bytes to get the state of all 15 inputs for a single MCP, so a total of 32 bits will be transferred. If you can run SCK at 1MHz it would take 32/1Mhz = 32µs to transfer 32 bits plus 1µs for CS setup/hold so a total of 37µs. Then for for 36 of them it would be 1.33ms. So I would say yes fast enough but that does not include processing time for doing what you need to do with the data.
But.. now with a push… how does the MCP say to the arduino. “hey.. i have a sensor state change.. I need to tell you about…
I assume yo mean push-pull as opposed to open collector but it does not matter, the MCP works the same way for both.
You could use interrupts but that would require an Arduino pin for each MCP interrupt line, so 36 more pins and wires or you could tie 8 interrupts together so you would only need 5 more pins but then you need to scan 8 MCP to find the one with the change. Software wise it may just be easier to scan all 36 MCP.
So what I think the thread is getting at is. the current A3144 with 10k ohm resitors plan seems to have issues, not in logic but in quality of A3144 for the task, and can the MCP , which on paper can do the pull logic, is able to do it.
The option of purchasing DRV5032DULPGM is with 0.1uF ceramic capacitor (Amazon version $70 would give me option to do push/pull.
I assume yo mean push-pull as opposed to open collector but it does not matter, the MCP works the same way for both.
But the scan logic of pull seems to be the way to get it to work. I am trying to formulate my next step. If it means investing $200 in parts with high % chance it will work, then the project is worth it, but my current concern is why I can’t get a single test, maybe even if not totally bug free, of the scan with CP0 CP1. both MCP set to ID 0 , cannot scan. I think my next step is to do a bit more testing on the two seperate then couple the test with shared
Let me know if you think testing with A3144 is a dead end.. if so, why.
Thanks for input.
No it is not if you are willing to solder in the 576 resistors in the final design
I though push/pull. was refering to how you got the “signal”. If you wanted you could scan dozens of them and if it read the digital output leg and it was “High” (aka held voltage state) then you had triggered it. If you scanned that sensor and it was “LOW” (aka voltage was near zero) then it was NOT triggered. But this was a “PULL” approach to reading the sensor. you set how often to spend clock cycles to come to each sensor and poke it and say “hey.. did someone touch you sense we last spoke”. This is “Polling” based
Push was the opposite (Iterupt-driven). If it was “LOW” (near zero volts) it would sit quietly. but when someone waved magnet over it and it drew up to “HIGH”, then it would release or “PUSH” that voltage down the digial line.
That is how I was A$$uming push / pull types work.
##
The other hall effect sensor I read on is “Open-Drain/ Open-Collector. I did read it is better for wired in parallel, but seemed to be slower. Its normal state is LOW (no voltate on digital read line) but when magnet is present, raises itself up to HIGH (allows power to flow over from + line).
##
The other types of Hall Effect sensors I read about were analog vs digital. If analog it could detect on a scale of say 1-10 how much magnetic field it was sensing and so you would have to have analog sensor to then decide at which “value” you wanted to declare “sensed” (HIGH). So I passed on this as this would have taken a lot more logic to scan and evaluate. I picked A3144 because it was digital and on some arduino forums I googled and had several youtube videos.
##
So it seems I picked A3144 based on Digital and its typical use. Not knowing if it was Open-Collector vs Push/Pull. It is an Open-Collector and Digial. It is normal state “LOW” and so to raise it up to “magnet detected” / HIGH , it need the pull up resistor. I read that the MCP23S17 could set ONE pull up resistor for all 16 inputs, but was not quite sure how that worked, so I wired the first batch of 4 x 24 rows with each having resistors. I will do the labor if needed but also trying to learn means to be more efficient.
When I did my single MCP + HES test, it read like a champ and so A$$umed I had logic and wire design down. But when I added more, and got weird results, and it would not scan second MCP in the same group, or as seperate group…. I assumed my INO logic was the issue, hense the start of posting. It looked ok on paper.. but… the real world shows up like the Bumpus Hounds from next door.
Next steps:
-
Get some correction on my understanding on how polling and open/drain A3144 really works and correct my logic - I think I am getting close
-
Post to chip forum to get better validation that MCP23S17 CAN do what I am asking
-
Get some words of wisdom on how to do it most efficient. This part is just the sensor side. Stiill to come is the game logic, OLED display side, and API calls, and game logic. All are all going to take overhead on the Arduinio UNO R4 Wifi. I am not clear when I will bump into that as my limitation.
I started with this one as this is the most complex.. So trying to find the road edges as I learn to drive.
@jim-p
It works with the SPI interface too if you enable them
IOCON.HAEN == Hardware Address ENable
No. It's normal state is high impedance. With a pull-up connected, the normal state is HIGH
This was all explained long ago.
You are constantly trying to do more complicated things before you can make a simple one sensor set-up work.
Have you actually tried it with all the CSs tied together?
Yes, I got an issue about it in my mcp23s17 github repo and after some tests it worked. Allows a plenty IO pins.
Thank you. That will save @penguinpages from doing even more testing.
I hope to get to work on this tonight.
What I think you confirmed is the archect design of up to 8 MCP sharing a single digtigal pin is a valid approach.
All 32 sharing the common three pins: MISO,MOSI,SCK.
5 x dedicated pins for each. “group” of CS.
I think the logic @robtillaart tested “IOCON.HAEN == Hardware Address ENable”. is this use of CS pin for each “group”
Trying to grok here..
Can you share your git repo with test code. if I can align my pins and test to yours as a baseline, then its just debugging if its a user error, or .. as may be the case, quality issue with MCP or sensors..
PS: Did you use common diods for pullup one per MCP… or did you use in on “RESET” pin and pullup all sixteen as one? the MCP lists it SHOULD have auto-pullup… but not even sure context of how it would do that.
Where do you see this?