using the 40 pin I/O universally across SBC

[Simon]

From what I see all single board computers have the RPi 40 pin IO connector. But the hardware differs across boards. I have a flashing LED from the RPi P400 working with the PIGPIO library. But I am likely to be using the ROCK4 board or any other board I can get hold of.

So in order to be able to change SBC at will without painful code adjustments should I avoid using the GPIO? I beleive that the various serial ports contained in the 40 pin header are standard linux. So am I better off using a serial port instead to interface to a micro controller for any custom signaling that I require?

[CJay]

Do you mean *any* SBC capable of Linux or do you have specific boards in mind?

If you mean *any* then yeah, TTYs would make it simpler but it puts a little more complexity onto the microcontroller.

If you have a few specific boards/architectures in mind then it's entirely possible something like WiringX (I'm sure there are plenty of others) would already support it or be ported to it relatively easily.

 

[Simon]

No I mean any. When I first considered the project I said to my boss tat in my view it is safer to design it so that it can run off a PC with a serial port. I will be putting CAN bus onto it so actually the serial part will either be the SPI port that all of the hat adapters use and is natively supported or a USB adapter on a PC I guess. The ability to run it from a PC was more of a flippant comment to emphasize sticking to standard hardware.

[Simon]

would it be wise to use the GPIO for a hand turned encoder?

[TomS_]

Whats wrong with choosing/qualifying 2 maybe even 3 boards from different manufacturers, and writing a little extra code to detect which one your software is running on and adjust things accordingly? Abstract the hardware interaction away from the application so that it stays as generic as possible and just need some functions to support the different platforms?

If youre not going to standardise on something, then you need accept the fate of building a more complex product in one way or another (hardware/BOM, software, etc).

Personally I'd probably choose the software route. Adding a microcontroller or some other device, which will need its own code written and maintained (and may need updating in the field), just to avoid writing some other code in your main application seems silly to me. And then you have two code bases potentially using two different sets of tools and toolchains, extra manufacturing steps, ....

[Simon]

what happens when i want to run on an x86(-64) motherboard? those IO pins are just a standard that one little manufacturer came up with and all the others copied. As I am working on machines a remote encoder on CAN bus is not so unusual, they sell them for some extortionate price, we can roll our own fairly cheaply.

[tszaboo]

would it be wise to use the GPIO for a hand turned encoder?

I've had issues with encoders even on microcontrollers, that have much faster GPIO access. Linux isn't real time, the user experience of such a setup will be... IDK probably not great.
IMHO decide first what hardware you want to use, and write code for that, not the other way around.