Question about custom BOB for a 7i92

Sorry I misunderstood. I think I get what you mean now. I assume that would look something like the velocity or encoder position of the roller controlling delay setting?....which actually sounds like it could work fairly reasonably as a simple way of doing it. That might actually work well for that test scenario but the real use is a bit more complicated. I wouldn't use that since I have a more flexible way of doing it with a hal component. Merging that hal logic into a firmware module would be the best way to do it but it works well enough even with the stackup of software and ethernet IO read/write variations.

I've been using that for several years, this guy actually tried something similar with LinuxCNC and a 7i76e then switched to using his own firmware on a DExx Nano (altera FPGA).



Fundamentally a similar thing to what I'm doing but you can see the difference between when he used a software implimentation vs full FPGA. I spoke to this guy a couple times, was curious why he didn't just try to write a hm2 module to do everything....he seemed to have the skill.

PCW when you get a chance just let me know if that schematic usage an the pinout I posted yesterday jives so I can send that next rev out.

Looks OK to me

If just using 2 chips on BSPI, You just use 2 chip select pins and there is no frame pin right?

I just had the epiphany that I should probably just drop the 4 ADCs and use a 2nd 8bit MCU with analog inputs since I'm already in MCU land now.

PCW, when you get a chance this is the final pinout I need for the 2nd version of the firmware.

I removed the chip select decoder as I only have 2 devices now.
 

You would need to use DBSPI (decoded BSPI) if you do not use FRAME.
This is because BPSIs CS signals are just static addresses and not
de-asserted between frames (which most SPI chips require)

This would need minor changes in the driver to support DBSPI
(basically just accepting its GTAG and invoking the normal BSPI driver
plus cosmetic stuff like printing the pin names correctly)

So BSPI requires a decoder IC but DBSPI works like you would expect normal SPI to work?  That's slightly confusing.

I did design a "rev2" that uses the decoder but I ran "rev3" which is what that pinout list is for.

I'm pretty far off into the weeds with the component and 2 MCUs that need firmware (they do very basic things) so I'll see if my friend can modify the BSPI driver as well. Should this be a new "DBSPI" driver based on dbspi.c or should it just be an addition to bspi.c?

BSPI uses an external decoder to save interface pins (since can support up to 16 different devices (so 8 pins total for 16 devices rather than 19)

There's no need for a separate interface file. In fact if there are not mixed types in one
configuration (BSPI+DBSPI), I dont think bspi.c needs to change at all. The minimum change is probably just one or two lines so that either BSPIs or DBSPIs GTAG both invoke the bspi driver(the rest would just be cosmetic so the pin printout and hal pin names were correct)

In fact, because the register maps are basically the same, it probably possible to create a DBSPI
configuration that requires no driver changes at all

Well my friend wrote a very simple subdriver component that basically just has the hm2 functions so I can see how things show up in hal. I suppose once I have the new firmware with dbspi I can see how the stock bspi driver handles it.

It sounds like the changes to bspi.c are fairly simple but I'm guessing I'll have to compile linuxcnc from source to use the modified driver? Components are simple to deal with using halcompile but not sure about the driver.

I have changed the BSPI firmware so you can use decoded or non decoded
Chip select outputs. That is, both types are now supported by the unchanged
LinuxCNC BSPI driver. If a frame pin is found for a BSPI channel, the external
decoder firmware is built, if not, the decoder is built into the firmware.