-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The only problems I have had with pins is when I assign more than one thing to drive them (ie: both the PRU and the hal_bb_gpio driver) or get the muxing wrong in the device tree overlay.
The PRU can talk to any GPIO pin on the device, as well as the dedicated PRU pins. On 7/5/2013 1:45 PM, Troy Jacobson wrote: > 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: > > 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/ iEYEARECAAYFAlHXGVwACgkQLywbqEHdNFwwSgCeOb2G6bSyDCTtnDpgQoRMtcNz JTsAoKQRm1eP2NRr0Z1sN0K9y8RyrL7v =+HRV -----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
