fourtyseven

I understand but i'm having those 'What if' moments... Remove extra hardware and implement into one.. i feel like the GPIO is being wasted on these boards.

I'm even more curious with the I2S bus where you can use it as a pseudo SPI bus in the ESP32 platform and control a 74hc595. Is this possible with these SBC's?

Nothing is overkill for stepper motors

Was unable to get 2Mhz stable using /dev/mem. I wonder where they got the 80Mhz number from. If they are talking about the BCM2835 chip then it's a different story.

I tried the /dev/mem route and got around 1.6MhZ (on a H3 based board) at best which i arrogantly concluded as 'slow'. Well that may hold true for a lot of SBC's but the major differences come down to the base address and the control/data registers address. The overflow for the BCM2835(faster gpio) with H3 is quite similar when it comes down to the interaction with the GPIO. I however cannot say the same for PWM and anything other then that. honestly i am quite impressed as i have not seen a implementation without sysfs until now. Great Work! i wonder how well will this work with the RT patch. Only if the pin state's gets buffers before outputting to compensate for jitter.

any benchmarks for this?

Okay so after some fiddling around with registers;it seems like 1.6Mhz is the best for stability and the results seems quite consistent when the pin is checked if it actually changed the register or not. #define GET_GPIO(g) (*(unsigned int *)(gpio+0x10) & (1<<g))// 0 if LOW, (1<<g) if HIGH #define GPIO_SET(g) if(!GET_GPIO(g)){*(unsigned int *)(gpio+0x10) |= (1 << g);} #define GPIO_CLR(g) if(GET_GPIO(g)){*(unsigned int *)(gpio+0x10) &= ~(1<< g);} This is still disappointing but i guess its a 'one up' from the previous results.

Hello, I'm new here and do not quite understand the sub-forums here but hopefully this is the right one. I got an Orange pi ONE running 4.19 RT kernel with Armbian buster. I was testing out the GPIO capabilities of the H3 SoC without any libraries and got only 1.67 Mhz at best(which is ironically the same as WiringPIOP) with some task interrupt issues. #define INP_GPIO(g) *(unsigned int *)(gpio+0x04) &= ~(7 << (((g) % 10) * 3)) //I did not thoroughly check if the mapping is okay #define OUT_GPIO(g){\ *(unsigned int *)(gpio+0x04) &= ~(6 << (((g) % 8) * 4));\ *(unsigned int *)(gpio+0x04) |= (1 << (((g) % 8) * 4));\ } #define GET_GPIO(g) (*(unsigned int *)(gpio+0x10) & (1<<g))// 0 if LOW, (1<<g) if HIGH #define GPIO_SET(g) if(!GET_GPIO(g)){*(unsigned int *)(gpio+0x10) |= (1 << g);} #define GPIO_CLR(g) if(GET_GPIO(g)){*(unsigned int *)(gpio+0x10) &= ~(1<< g);} //after accessing /dev/mem OUT_GPIO(12); for(;;) { GPIO_SET(12); GPIO_CLR(12); } The result is pretty inconsistent but at least works (any suggestions?). One could say remove the if statement(got 2Mhz) but that makes the output even more bizarre. At this point i am quite stuck and not sure how to get a faster result with correct timing when rising and falling. Any suggestions for this would be helpful. Thank you! test.cpp