I might have a lead on the two problematic PWM pins. P8.36: All of the docs that I've seen don't show this pin being assigned to a pru. Does this mean that it isn't available to use with the PRU based pwm generator? It looks like it might have been used with the build-in pwm (ehrpwm) with the original software.
P8.45: In hal_pru_generic.h, PRU_DEFAULT_PIN is set to 17, which looks like it maps to GPMC_A0, which coincidentally is P8.45. I'm going to move this to another PRU pin for now. Troy On Thu, Jul 4, 2013 at 9:23 PM, Charles Steinkuehler < [email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Adding emc-users to cc: since this might help other folks, and direct > email to Troy is being bounced. > > I noticed in several of my configurations I have I/O pins being driven > by both the bb_gpio module and the PRU. This is a bad thing...it > doesn't cause any physical harm to the circuitry, but it creates very > confusing output results. NOTE: I have been fixing these issues as I > find them...please pull the latest MachineKit branch from git. > > Make sure that any PRU PWM pins are not assigned to the bb_gpio module > and your problems will probably go away (or at least you'll be on to > the next one!). :) > > Yes, I've seen the issue with overlapping ADC reads here. I really > need to see if I can migrate the ADC reads into HAL and talk directly > to the hardware (instead of using the current python script), but I > still want to "play nice" with the kernel ADC module because I plan on > using a touch-screen at some point. > > On 7/4/2013 3:07 PM, Troy Jacobson wrote: > > Thanks for the numbering info. That helped at lot at > > understanding parts of the configuration files. I have X,Y, and Z > > working. Haven't tried an extruder yet (waiting to get temperature > > stuff nailed down first). Home switches for all thre axes are > > working. I can read 2 thermistors. M104 and M140 commands work > > within LinuxCNC. Where I am now stuck is that I can only get 1 PWM > > output to work, an that is P8.46. P8.45 seems to refuse to do > > anything, and P8.36 looks to have a PWM signal coming from > > somewhere else. > > > > A couple of things I added were turing the pid on and off when the > > temperature was set. Without it, there was along delay between > > setting the temp and the heater being turned on. I also increased > > the sleep time between reads of the ADC. There was a post > > somewhere about a kernel bug that would show itself if reads of > > the ADCs overlapped. > > > > More after the holiday. > > > > Thanks, Troy > > > > > > On Sun, Jun 30, 2013 at 7:17 PM, Charles Steinkuehler < > > [email protected]> wrote: > > > > On 6/30/2013 11:26 AM, Troy Jacobson wrote: > >>>> Hi Charles, and all, > >>>> > >>>> My BBB is making my printer move, and I'm almost to a place > >>>> I can use it to make something. The system consists of a > >>>> bunch of jumper wires from the BBB to a RAMPS board. > >>>> Functional, but messy. > >>>> > >>>> The next steps are: 1) Tweaking the temperature code to > >>>> match the thermistor circutry on the RAMPS. I like that the > >>>> thermistor table Charles made is based on the resistance at > >>>> a temperature. I'll also need to add a second temperature > >>>> input, but I think most of the framework is in place for > >>>> that. 2) Outputs for a fan and two heaters (hot end and > >>>> print bed). 3) Home/limit switches. I have a good idea what > >>>> needs to be done here, except that I can't find out how to > >>>> map to the pin on the BeBoPr. > >>>> > >>>> I mostly need help with #3. I see the > >>>> [PRUCONF](Driver).stepgen.00.enable type lines, but how does > >>>> that map to an actual pin on the BBB? It also looks like > >>>> more pins on the BeBoPr might need to be added in the dts > >>>> file. As an alternative, I might try to use the K9 > >>>> configuration as a starting point, since there seems to be > >>>> more pins that I can use. > > > > There are more available pins on the K9 config, because the K9 is > > tied to just about every available I/O. :) > > > > I have just recently started trying to support more than one ADC > > on my BeBoPr config (to read extruder and bed temperature), and I > > have had issues with the Python ADC temperature code failing > > (apparently, the ADC "helper" driver isn't very robust and doesn't > > like being pestered by multiple user-mode programs at the same > > time). :( > > > > As for pins, there are several different schemes in use on the > > BeagleBone and within my config files: > > > > The Kernel GPIO naming convention: (GPIO_Bank * 32) + bit > > > > The hal_bb_gpio HAL module convention: P8 Pin = 100 + Pin number > > P9 Pin = 200 + Pin number > > > > The hal_pru_generic convention, which is similar to the kernel > > naming convention but off by one, so "zero" results in no output: > > > > ((GPIO_Bank + 1) * 32) + bit --or-- ( 5 * 32) + PRU_bit > > > > The home/limit switches are intended to be used with the > > hal_bb_gpio component. It should be resonably obvious how to > > connect these if you poke around in HAL a bit (I have the > > component loaded so it should export the pins you need, you just > > have to hook them to something!), but holler if you have any > > questions or problems setting up a configuration. > > > >> > >> > > > > - -- > Charles Steinkuehler > [email protected] > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlHWLgwACgkQLywbqEHdNFz2swCgtpGNA75Qqu1QMPYJI30JQBFS > PIEAoPflEEabakhE6epgdK4BZZyHUrw6 > =FQfB > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
