You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If this code is relatively stable, it would be nice (if it's even possible; I'm not a RPi engineer) if the 4 GPIO ports allocated for the debug UART were able to be allocated as additional digital inputs. Putting the device at or over the 24-channel barrier would greatly increase its utility, as you could then fully analyze embedded controllers with a 16-bit address and 8-bit data bus. A 25th input would be even better, since that could be tied to either a clock signal, a R/!W signal, or something similar.
I also wonder if you'll save CPU cycles and be able to successfully have a sample-on-rising-edge feature if the ADCs and debug printf()s were omitted (since printf() is a very expensive operation). Not having time to look into the code at the moment, are interrupts being set on trigger pins? This could save the overhead of having to software poll by just having the hardware interrupt logic watch a pin for either rising or falling edge, and then the ISR samples all the GPIO channels.
Just a thought.
The text was updated successfully, but these errors were encountered:
If this code is relatively stable, it would be nice (if it's even possible; I'm not a RPi engineer) if the 4 GPIO ports allocated for the debug UART were able to be allocated as additional digital inputs. Putting the device at or over the 24-channel barrier would greatly increase its utility, as you could then fully analyze embedded controllers with a 16-bit address and 8-bit data bus. A 25th input would be even better, since that could be tied to either a clock signal, a R/!W signal, or something similar.
I also wonder if you'll save CPU cycles and be able to successfully have a sample-on-rising-edge feature if the ADCs and debug printf()s were omitted (since printf() is a very expensive operation). Not having time to look into the code at the moment, are interrupts being set on trigger pins? This could save the overhead of having to software poll by just having the hardware interrupt logic watch a pin for either rising or falling edge, and then the ISR samples all the GPIO channels.
Just a thought.
The text was updated successfully, but these errors were encountered: