There we are. I got it working using C24. That's incredibly confusing. What's config pin's deal here:
debian@beaglebone:~/Desktop/riot_bin$ sudo config-pin -q P8.15 P8_15 Mode: pruin debian@beaglebone:~/Desktop/riot_bin$ sudo config-pin -q P8.45 Pin is not modifyable: P8_45 lcd_data0 debian@beaglebone:~/Desktop/riot_bin$ sudo config-pin -q P8.20 cape-univ-emmc overlay not found run "config-pin overlay cape-univ-emmc" to load the cape debian@beaglebone:~/Desktop/riot_bin$ config-pin overlay cape-univ-emmc Loading cape-univ-emmc overlay bash: line 0: echo: write error: File exists Error loading device tree overlay file: cape-univ-emmc I mean the muxing on P8.15 works splendedly but then P8.20 is inaccessible. Also most of the pins on PRU1 are covered up by lcd pins which will quickly become unacceptable in my project. On Wednesday, May 21, 2014 11:11:47 AM UTC-5, Charles Steinkuehler wrote: > > Use the real TRM and data sheet. The page you linked to is for an > earlier version of the PRU. At the top it says: > > This arcticle is part of a collection of articles describing the PRU > subsystem included in OMAP-L1x8/C674m/AM18xx devices (where m is an even > number). > > The PRU cores are upgraded in the AM335x parts vs. the AM18xx. > > On 5/21/2014 10:57 AM, foreverska wrote: > > I got C3 from TI's website: > > > http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit#PRU_Internal_Constants_Table_Entry_Register_n_.280x0480_.2B_4.2An.29 > > > > > > > On Wednesday, May 21, 2014 5:31:19 AM UTC-5, Charles Steinkuehler wrote: > >> > >> On 5/21/2014 1:16 AM, foreverska wrote: > >>> Code never seems to work out of the box for me on these things. Now > >> that I > >>> have operational code looking at R31 I have issues putting the results > >> int > >>> datamemory which is just absurd. Here's the code: > >>> > >>> #define CONST_PRUDRAM C3 > >>> #define TOOTH_COUNTER R5 > >>> > >>> lpe: > >>> ADD TOOTH_COUNTER, TOOTH_COUNTER, 1 > >>> QBEQ lpe, r31, 0 > >>> > >>> SBCO TOOTH_COUNTER, CONST_PRUDRAM, 0, 4 > >>> > >>> I have also done this with SBBO pointed to 0x0 with no success. In > >>> prudebugger R5 has a non zero value but the memory comes up as 0x0 in > >> the > >>> debugger. The C program I have agrees with the bugger's reported > values > >> on > >>> that value and surrounding values. Is there a setup for the pru to > >> access > >>> DM? That feels absurd. It is it's own local ram. > >> > >> I suspect you are writing to the wrong address. Note that C3 which you > >> use above points to the local eCAP timer, I have no idea why you think > >> it should be writing to memory. > >> > >>> As an aside, a C program should be able to look down in dram and see > >>> registers at the 0x7000 offset right? It looks empty to the bugger > and > >> my > >>> C program. Or are those different registers than the R0-R31? > >> > >> Read the PRU Reference Guide. The documentation for these registers > >> indicates they are valid while the PRU is disabled. See the RUNSTATE > >> and ENABLE bits in the CONTROL register (section 5.4.1 of the PRU > >> Reference Guide). > >> > >> -- > >> Charles Steinkuehler > >> cha...@steinkuehler.net <javascript:> > >> > > > > > -- > Charles Steinkuehler > cha...@steinkuehler.net <javascript:> > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
