My upgraded pololu motors (for my robot-in-progress) are coming soon, and they include integrated encoders.
The Pulse Count Module seems good for keeping tabs on the encoders, but it seems that for 4 motors/wheels, I would need 4 Pulse Count Modules.
This is doable, but each takes an S socket, so with the other two S modules I am using, we’re looking at 6 S sockets (and the raptor only has 3)
So now Im looking at the S-Plus module, and I see that it is “chainable” to increase the # of S sockets, but I have a couple of questions.
1: It is chainable by “one cable from the next S+ to an S Socket on the previous S+, and one cable to a Y socket on the Raptor”, correct? Meaning each new S+ module uses two cables, one S socket from the previous S+ and another Y socket on the raptor mainboard? Or is there another method of chaining them?
2: Is there going to be another unexpected “gotcha” surprise/slow down from a “software bit banging solution” that will render these chained S+ modules and attached modules slower than if they were connected to the main board?
3: Is there a simpler “gadgeteer” method for counting the inputs from 4 motor/wheel encoders without 4 Pulse-count-modules, 4-5 S+ modules, and 14 to 15 gadgeteer cables? It seems a little extreme for what I’m trying to do. I’m going to end up moving a basket full of modules qnd cables around. I suppose I can always just wire the encoders to 8 gpio lines with extenders/breakouts, but I’m either going to be using lots of "pin 3"s for interrupts, and a massive # of interrupts (6000 per revolution per wheel?) or some sort of insane polling loop, to use up all my cpu bandwidth.
Are there pins on the G400 that automatically count pulses?
Does anyone have any alternate suggestions for this (seemingly) basic requirement? (handling 4 wheel encoders)
@ mtylerjr - The SPlus module should not have the slow down you see on the Hub AP5, it uses the physical processor pins, which is why you need another Y socket from the mainboard for each module. Do keep in mind that the more SPI devices you have on the bus, the less time there is available for each individual device.
Based on this input, I’m now thinking that while it might be “doable” from a pure gadgeteer modules/cables standpoint, I might be better served just using one of my spare tiny arduino nanos laying around as a dedicated 4 channel pulse counter, and just have it send all 4 counts every .1 seconds or so to my raptor, with maybe a stall indicator on a single interrupt line.
I wanted it to be a pure gadgeteer creation - I’d use a cerb40 II if I had one laying around, but I don’t
@ mtylerjr - If all you need is four pulse count modules, you can get by with 3 SPlus modules. The very last one will have two pulse counts on it. So you’d need three extra Y sockets as well. Which you could for the modules themselves since they support Y sockets, though it won’t be as fast as native SPI.
I’ve never really looked closely at that module before now. That seems like an awful waste of resources just to get one extra S plug. Sounds like we need an SPlus+ that utilizes all of the Y pins and turns one S into 5 (or 8 if you also use the GPIO from the S…). Or maybe even one that doesn’t worry with chaining but utilizes all of the GPIO of the incoming S socket to turn one S into 3. Am I missing something here or was this made this way entirely to shave $1 off the cost?
[quote=“ianlee74”] Or maybe even one that doesn’t worry with chaining but utilizes all of the GPIO of the incoming S socket to turn one S into 3.
[/quote]
@ ianlee74 - You are correct that we could have more efficiently used all of the pins by adding more S sockets as outputs, but we would also need to add more Y sockets if we were to remain compliant with Gadgeteer. A SPI socket requires the three SPI pins and four GPIO (one of them being chip select). The most efficient way would be to have 8 SPI outputs as you said. But that requires 32 GPIOs, four from the SPI input, so 28 from 4 Y sockets. That’s certainly doable, but would make quite a big board.
This would have made the board a bit more expensive, which wouldn’t have been ideal for those who only needed one or two more sockets.
@ ianlee74 - I believe it is because other SPI devices often have GPIO requirements, so instead of requiring two sockets on the board, GPIO was moved to the SPI socket.
I understand. However, this convenience has created a situation where SPI can’t easily be used for its main purpose of being a bus I suppose with a bit of work one could create a module that uses a CS to also decide which module the GPIOs would be mapped to. However, since the “S” spec doesn’t really define a CS pin then that wouldn’t really work either.
So, one could create a module that maps one “S” to four but then you couldn’t label the new sockets with an “S”
there is a “Master SPI” board from @ Justin that deals with this. Lots of S sockets. And yes, there are many times the device on the end of the S needs more than just the SPI pins - one way to deal with that is to use two sockets on a module, but honestly I think that this works out a bit worse in terms of pin count…
I do recall a “Master SPI” but I don’t see it in Creations. I think it was a full mainboard. However, his “SPI Hub” is there which is basically what I was describing as a board for taking 1 “S” to four. However, it’s also obvious from his pic of the Gadgeteer designer that he’s lying to the designer and calling the “SPIx” sockets “S” sockets to make it possible to connect other “S” modules. This would work as long as they don’t also need the GPIO. But, this also means that the user has to know something of the internals of the attached modules and therefore violates the goal of Gadgeteer. It shouldn’t be necessary to violate the rules like this to create such an obvious module. I’m starting to think it would be better if the “S” socket only had a single GPIO that could be used for CS and if it needed extra GPIO then have a second X or Y socket for that.
I suppose with a bit of work one could create a module that uses a CS to also decide which module the GPIOs would be mapped to. However, since the “S” spec doesn’t really define a CS pin then that wouldn’t really work either.