This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
TinkerOS 2.0.8 breaks /dev/mem access to GPIO pins
#1
I adapted the GPIO control code for the PiDP-11 panel to run on my original Tinkerboard, running Jessie. This C code creates a thread with real time priority that accesses 21 GPIO pins at a high aggregate rate (100K+/second) by mapping the physical registers to user space. I then installed the software on a TinkerOs 2.0.7 (Stretch) image with no issues, since Jessie was losing support. I then tried 2.0.8, since it was 'the latest and greatest', and the software no longer runs.

I seem to have narrowed the problem down to really weird behavior with the GPIO register banks mapped to process memory (using /dev/mem or /dev/gpiomem doesn't matter). You can read the values, but any attempt to write is just ignored with no error (bank GPIO0 seems to be and exception). If you use the GPIO command to manually flip the direction and value individual pins, and state of the pins changes and you can read the new values via mapped memory.


Anyone know what's going on? My guess is they tried to discriminate between RAM and peripheral addresses and got the ranges wrong, but not getting segment faults is a real puzzle.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)