On Sun, Jul 31, 2016, at 10:42 PM, Charles Steinkuehler wrote: > On 7/31/2016 4:54 PM, John Kasunich wrote: > > > > I found the source on github, which included a commit from > > January 2015, where Charles changed the pin numbering from > > 1xx and 2xx to 8xx and 9xx. However, the Xylotex sample > > configuration (as shipped in early 2016) is still using the 1xx > > and 2xx pin numbering scheme. It looks like the Xylotex > > config wasn't updated when the pin numbering was revised > > (and it also looks like it hasn't been tested since early 2015, > > since that change should have broken the config). > > The 1xx/2xx and 8xx/9xx pin numbering are equivalent and can be used > interchangeably.
Yes, once I started reading the code I saw that you translate the old-style numbers to the new style. > > > I'm about 99.9% sure that I need to invoke the startup script > > to deal with device trees and other hardware issues. But the > > startup script is also totally undocumented. > > > > My plan was for this email chain to continue documenting > > forward progress. However, I'm very frustrated by the lack of > > documentation for BeagleBone specific code that has been > > added to machinekit. I will continue trying to figure this out, > > but I'm going to hit send in that hopes that someone can > > help. > > Sorry about your issues. I'm 99.9% sure you're hitting an ARM SoC > issue. On the ARM in general and the BBB specifically, the GPIO banks > are not enabled at power-up. If you do not export a GPIO pin from a > bank (and there are four unique GPIO banks for the BBB), it will not > be powered on or have a clock routed to it, so any accesses to the > physical address of the GPIO bank will cause a bus exception. That is consistent with the observation that ports 0 and 1 work and port 2 crashes. (I'm assuming that "port" and "bank" mean the same thing - the code uses "port".) I didn't test port 3. > You should load a device-tree overlay that enables the GPIO bank(s) > you want to use prior to loading the hal_bb_gpio driver. The easiest > way to do this is to load my "universal" overlay and then use the > config-pin utility to set the GPIO pins to input, output, or a special > function (PWM or encoder) as required. I will try that tomorrow. > You are correct that this isn't really documented anywhere, and that > needs to be corrected. At least I did finally manage to write a man > page for the hal_pru_generic driver! (baby steps) :) > > -- > Charles Steinkuehler > [email protected] > > -- > website: http://www.machinekit.io blog: http://blog.machinekit.io github: > https://github.com/machinekit > --- > You received this message because you are subscribed to the Google Groups > "Machinekit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > Visit this group at https://groups.google.com/group/machinekit. > For more options, visit https://groups.google.com/d/optout. -- John Kasunich [email protected] -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
