**** BEGIN LOGGING AT Sun Feb 25 03:00:05 2018 Feb 25 05:40:05 sorry for disconnecting, but to ask again: how can i load my asm PRU code to the PRUs using remoteproc? Feb 25 05:48:27 i don't think i can write the asm code in a .p file Feb 25 06:10:26 i am not able to find remoteproc 1 and 2 Feb 25 06:11:14 is there any alternative to using uio for pruss Feb 25 06:11:21 something other than prussdrv Feb 25 08:34:00 hey guys Feb 25 08:34:16 im using a BBBlue and on kernel 4.14-ti-rt Feb 25 08:34:25 im unable to configure servo1 as pruout Feb 25 08:38:24 can someone help me out Feb 25 08:44:49 its never setting servo pins to mode 5 Feb 25 08:45:22 zmatt: do you have any idea how to set pin modes on the beaglebone blue Feb 25 09:03:39 Apologies for disconnecting I tried to modify the iEnv by loading A robotics cape dtbo Feb 25 09:03:56 And now my beaglebone isn't booting up so I have to reflag Feb 25 09:04:26 Can someone tell me the procedure to change the pin modes for the beaglebone blue Feb 25 09:04:35 Specifically the servo pins beginning from P8-27 Feb 25 09:05:12 Show-pins shows that all servo pins are on mode 7 while required mode is 5 Feb 25 09:11:37 config-pin: you don't need to reflash, you can just boot from sd card and then fix the uEnv.txt file Feb 25 09:13:06 I was booting from eMMC all this while, so can I boot from an sd card and change the uEnv.txt for the eMMC one? Feb 25 09:13:58 Also for configuring the servo pins as pruout modes, can I use this: http://beaglebone.cameon.net/home/pin-muxing Feb 25 09:14:28 the 4.14 kernel for some reason doesn't set the pinmux of those pins right yet, nor allow them to be set via config-pin. you can try filing a bug report, or just grab the dts from kernel 4.9 and compile that in the presence of the include files (am33xx.dtsi etc) from 4.14 Feb 25 09:15:18 yes you can mount eMMC when booted from sd card to fix stuff there Feb 25 09:15:36 e.g. mkdir -p /mnt/tmp; mount /dev/mmcblk1p1 /mnt/tmp Feb 25 09:15:51 now the /boot/uEnv.txt on eMMC is /mnt/tmp/boot/uEnv.txt Feb 25 09:16:50 Thanks for that as soon as I get back to to my BB I'll do that. As far as the pin config is concerned, where can I find the dts I need to copy? Feb 25 09:16:55 the info on that page is completly obsolete Feb 25 09:17:16 zmatt: noted thanks! Feb 25 09:17:31 you can use https://github.com/RobertCNelson/dtb-rebuilder Feb 25 09:18:44 This one correct?: https://github.com/RobertCNelson/dtb-rebuilder/blob/4.9-ti/src/arm/am335x-boneblack.dts Feb 25 09:19:04 Do I need to compile this structure? Feb 25 09:19:24 so, check out the 4.14-ti branch using git, then retrieve the 4.9-ti version of the dts using: git checkout 4.9-ti -- src/arm/am335x-boneblue.dts Feb 25 09:19:37 then compile it with make src/arm/am335x-boneblue.dtb Feb 25 09:20:43 if that compiles without errors, there's a decent chance it'll work if you place it in /boot/dtbs/VERSION (where VERSION is your kernel version) Feb 25 09:20:51 be sure to make a backup of the original one Feb 25 09:23:18 You mean the one already in /boot/dtbs/version/ ? Feb 25 09:28:47 zmatt: I'll try these and get back to you Feb 25 11:09:47 zmatt: hey sorry im really dumb so im unable to checkout the branch like you said, i ran thiS: Feb 25 11:09:57 git clone https://github.com/RobertCNelson/dtb-rebuilder.git Feb 25 11:10:04 git checkout 4.14-ti Feb 25 11:10:13 git checkout 4.9-ti -- src/arm/am335x-boneblue.dts Feb 25 11:11:34 did you execute those checkout commands from within the dtb-rebuilder directory that git-clone created? Feb 25 11:11:51 yea Feb 25 11:12:16 oh is the other branch not called 4.9-ti? hmm Feb 25 11:12:16 oh duh Feb 25 11:12:18 "invalid reference" Feb 25 11:12:30 git checkout origin/4.9-ti -- src/arm/am335x-boneblue.dts Feb 25 11:12:31 sorry Feb 25 11:12:43 lol ok Feb 25 11:12:56 4.9-ti would refer to a *local* branch called 4.9-ti Feb 25 11:13:46 (the reason 'git checkout 4.14-ti' works is because it automatically creates a local 4.14-ti branch that tracks origin/4.14-ti ) Feb 25 11:13:47 ah i see Feb 25 11:14:16 so youd have to back track from that local copy Feb 25 11:14:22 to checkout another one Feb 25 11:14:44 ? Feb 25 11:15:30 nothing chuck it lol Feb 25 11:15:44 btw im getting this wehn i run make src/arm/am335x-boneblue.dtb Feb 25 11:15:46 when* Feb 25 11:15:54 #include "am335x-bone-common-universal-pins.dtsi" Feb 25 11:16:11 not found Feb 25 11:16:31 grab that file also from the 4.9-ti branch I guess Feb 25 11:16:34 with git checkout Feb 25 11:18:30 any idea where in include/dt-bindings/ will it be? Feb 25 11:18:40 nowhere, just in src/arm Feb 25 11:18:50 oh lol yeah Feb 25 11:18:51 sorry Feb 25 11:18:56 just noticed Feb 25 11:20:24 is it normal for more files to be missing? Feb 25 11:20:27 even am335x-boneblue-wl1835.dtsi is Feb 25 11:20:30 missing Feb 25 11:20:58 well it compiled Feb 25 11:23:48 it booted Feb 25 11:23:55 any idea how i can get your show-pins script Feb 25 11:24:02 should i just take it from ur repo? Feb 25 11:24:02 it's just that 4.9-ti is the main branch right now and where am335x-boneblue has seen the most work Feb 25 11:24:24 but 4.14-ti is safe to use? Feb 25 11:24:32 https://github.com/mvduin/bbb-pin-utils/tree/blue#show-pins Feb 25 11:24:44 what do you mean by "safe to use" ? Feb 25 11:25:18 like Feb 25 11:25:21 is it tested Feb 25 11:25:38 I don't know if all functionality available in 4.9-ti is already available in 4.14-ti, presumably not since otherwise it would probably already be the default branch. I have no idea what might be missing though, or whether you care about any of that Feb 25 11:25:56 tested? probably not as much as 4.9-ti, and certainly not on the beaglebone blue Feb 25 11:26:29 we recently switched from 4.9-bone to 4.14-bone without any problems though Feb 25 11:26:32 youre right lol i cant even tell the difference Feb 25 11:26:53 what is the difference between the ti and the bone kernels?? Feb 25 11:28:18 -bone is somewhat closer to mainline and configured in a more beaglebone-specific way. -ti contains some stuff from the TI kernel branch that hasn't reached mainline yet (e.g. I think remoteproc-pru falls in that category), and is used for multiple boards including the beagleboard-x15 Feb 25 11:32:07 what does "mainline" mean? Feb 25 11:34:35 the version of the kernel as released by Linus Torvalds and subsequently maintained by Greg Kroah-Hartman Feb 25 11:35:15 ohhhhh Feb 25 11:37:04 anyway, even though you're clearly an "early adopter" for 4.14-ti, it will get a lot more focus sooner or later Feb 25 11:37:56 4.14 is the next LTS (long term support) release of linux after 4.9, and mainline support for 4.9 ends januari 2019 Feb 25 11:44:22 zmatt: man i wished i knew more about this... most of this stuff, esp device trees confuse the heck out off me, currently im satisfied even if it works without me understanding it:p Feb 25 11:44:27 so long as it does work :p Feb 25 11:44:31 thanks for the info btw Feb 25 11:45:01 device trees are not terribly hard... once you understand them Feb 25 11:45:10 (yes that was a useless remark) Feb 25 11:46:42 lol Feb 25 11:46:45 :p Feb 25 11:48:28 it's just a filesystem-like tree of information that's passed to the kernel to describe the hardware. in fact you can view it as a filesystem in /proc/device-tree Feb 25 11:49:32 yeah i mean i did read about it (adafruit to the rescue lol), but i still cant solve problems when they arise Feb 25 11:51:20 an easier way to produce them would be very much welcome indeed... I'd said that for years now I think :P Feb 25 11:51:54 btw do you have any ideas about using rproc? Feb 25 11:52:00 i followed zeekhuge's guide.. Feb 25 11:52:09 but the thing is i write code for pru in asm Feb 25 11:52:18 i dont know how to load that with rproc Feb 25 11:52:18 right now they're just too "untyped" ... you can put anything in there, and the only way to know for sure whether what you did is right is by testing. of course there's documentation about it (often incomplete, sometimes plain wrong), but still Feb 25 11:52:35 no idea, I don't use rproc-pru or care about it really Feb 25 11:52:38 I just use uio-pruss Feb 25 11:53:06 hey prussdrv is the only c library for uio pruss right? Feb 25 11:53:33 I'm not sure if a better one has been written yet... it would certainly be welcome Feb 25 11:53:37 prussdrv is kinda eww Feb 25 11:53:37 yeah someone should come up with a way that even newbs like me can modify them Feb 25 11:53:43 i guess config-pin is a good way Feb 25 11:53:51 zmatt: then what other alternative is there? Feb 25 11:54:03 oh Feb 25 11:54:06 ok lol Feb 25 11:54:40 recently I did some work on a pure python library for working with uio-pruss... because The People wanted it mostly, I don't hugely like python myself Feb 25 11:55:13 dont you use prussdrv? Feb 25 11:55:17 what do you use then? Feb 25 11:55:21 your py lib? Feb 25 11:55:46 I actually haven't done as much with pruss as I want to Feb 25 11:56:30 usually I just used my own headers and some generic uio code Feb 25 11:56:46 you don't really need all that much "library" anyway Feb 25 11:56:56 what do you mean??!! Feb 25 11:57:06 most of my python code is also just the equivalent of C headers Feb 25 11:57:10 and a bit of mmap Feb 25 11:58:27 prussdrv_map_prumem uses mmap right? Feb 25 11:58:41 can you show me these headers you use? Feb 25 11:58:44 loading/running pru code via uio-pruss just consists of: find and open the uio device, mmap pruss into userspace, initialize a few registers, load your code into iram, set a bit to start the pru core Feb 25 11:58:59 oh really? Feb 25 11:59:00 wow Feb 25 11:59:17 i did not know thats what went on under th ehood, but surely the INTC business is more involved? Feb 25 11:59:22 slightly Feb 25 11:59:43 I have both a basic test and and intc test in python you can look at: https://github.com/mvduin/py-uio/blob/master/pruss-test.py Feb 25 12:00:28 and pruss-intc-test.py in the same directory Feb 25 12:01:04 you said there are C headers you sue? which are they? Feb 25 12:01:07 use* Feb 25 12:02:14 well i really wish i could understand this but lol i dont get anything in cfg or core.. Feb 25 12:02:48 those are basically just "structs" with a few methods stuck onto them Feb 25 12:03:01 see https://github.com/mvduin/py-uio/blob/master/ti/icss/__init__.py for the overall layout of pruss Feb 25 12:03:11 core.py and cfg.py are in the same directory Feb 25 12:04:03 core.py, cfg.py, intc.py are all directly based on my C headers Feb 25 12:04:34 I mean C++ headers btw, sorry Feb 25 12:05:10 I never really released them propertly... maybe I should, although my C++ style can be a bit eccentric Feb 25 12:05:46 https://liktaanjeneus.nl/pdsp.h.html is the one equivalent to core.py Feb 25 12:06:05 (more or less) Feb 25 12:08:03 so i could include this in a program, create an instance of the struct Core, and use it like you have in your example? Feb 25 12:08:26 pruss_test.py i mea Feb 25 12:08:27 mean* Feb 25 12:08:40 well you don't really "create an instance", it directly represents a region of memory-mapped registers Feb 25 12:10:05 hold on I'll just grab the relevant headers into a zip Feb 25 12:11:00 yeah you shouldve defs released this c++ thing as a replacement fo rprussdrv Feb 25 12:11:02 for prussdrv Feb 25 12:11:18 i mean atleast lookign at the python code, its much more understandable what exactly is goin gone Feb 25 12:12:18 well I think it's still too rough and unpolished, lacks useful higher-level functions, and needs much more care in use due to my tendency to avoid the use of 'volatile' in my C++ headers in favor of appropriate use of explicit barriers Feb 25 12:12:35 so I don't really want people to end up writing buggy code as a result of that Feb 25 12:12:47 oh okay Feb 25 12:13:05 config-pin: take a look at this example https://github.com/ZeekHuge/BeagleScope/tree/port_to_4.4.12-ti-r31%2B/examples/firmware_exmples/PRU_inline_asm_blinky Feb 25 12:14:08 if you are using rproc. Feb 25 12:17:01 here's my ti/subarctic/pruss.h header and the headers it depends on (I hope at least, haven't checked carefully whether I added all of them to the archive) -> https://liktaanjeneus.nl/icss-includes.tar.xz but like I said, I'm not sure I'd recommend their use unless you know what you're doing Feb 25 12:17:06 but it may at least be informative Feb 25 12:17:36 that's their primary purpose anyway: most of these headers started their life just as notes (and not necessarily even be compilable) Feb 25 12:19:04 zmatt: ill download em and check em out Feb 25 12:19:12 so how I'd use them is by mmap()ing the primary memory region of the uio device and then cast that to (Pruss *) Feb 25 12:19:19 the cores are members thereof Feb 25 12:20:01 zeekhuge: im looking at the code rn, and i guess code written in .p wont work? also can i use the same .cmd and the same resource table? Feb 25 12:20:46 (the 'extern' declaration in ti/subarctic/pruss.h is actually meant just for baremetal use, or use in combination with a really disgusting library I made that uses /dev/mem and some linker magic to more or less simulate a baremetal environment for code running in linux userspace) Feb 25 12:21:33 zmatt: wow ok i got none of that... :p, i guess considering my level of knowledge about the BB in general, i prolly hsouldnt mess around with it? Feb 25 12:22:00 well like I said, they may still be informative Feb 25 12:22:08 lots of comments in my headers Feb 25 12:23:00 ti/pdsp.h especially contains information (based on testing I did) that I haven't seen anywhere else, including the am335x TRM Feb 25 12:23:07 config-pin: The example basically shows one way to load asm code onto the PRU. Look into the Makefile, how it is done. Feb 25 12:23:37 config-pin: you can compile asm code using clpru for loading with remoteproc-pru Feb 25 12:23:45 although its syntax isn't quite compatible Feb 25 12:23:58 ah yess im seeing that in the makefile Feb 25 12:23:58 and I think some of pasm's more advanced features are missing Feb 25 12:24:57 I think it should also be possible to convert a pasm binary into ELF format for loading by the remoteproc, but that may need a bit of research on how to use objcopy or whatever TI's equivalent thereof is called Feb 25 12:25:13 is there an advantage to using rproc over uio_pruss considering the fact that Id be using prussdrv?? Feb 25 12:25:23 you can't use prussdrv with rproc Feb 25 12:25:41 yeah i know Feb 25 12:26:02 i meant that id be using prussdrv with uio_pruss Feb 25 12:26:59 I don't know if there's any reason to use rproc unless you want to write kernel code that interacts with pru code Feb 25 12:27:07 zeekhuge: btw im the guy who sent you that mail :p Feb 25 12:27:31 zmatt: yeah cuz rproc is sooooo complicated for me to understand rn Feb 25 12:27:42 config-pin: Dhruv ! Although I kind of guessed it. Feb 25 12:27:56 zeekhuge: lol :p Feb 25 12:27:59 yes rproc mostly seems to add complication and reduce flexibility Feb 25 12:28:20 zmatt: ikr! Feb 25 12:42:56 prussdrv_map_prumem( PRUSS0_PRU1_DATARAM, &memPointer) would make mempointer point to start of DRAM0 for pRU1 right? Feb 25 12:45:03 yes Feb 25 12:46:40 so if i wanted to write 4 32 bit integers to the dram, i would cast mempointer as a uint and access it as mempointer[0], mempointer[1]...? Feb 25 12:46:49 yes Feb 25 12:47:00 volatile uint * Feb 25 12:47:12 okay Feb 25 12:48:07 mempointer = (volatile uint*) mempointer and mempointer[0] = val1 etc..? Feb 25 12:53:06 you can't reuse the same variable name obviously, but other than that yes Feb 25 12:53:26 or ((volatile uint *) mempointer)[0] = value; Feb 25 12:53:28 yeah Feb 25 12:53:29 cool Feb 25 12:53:31 thanks Feb 25 12:53:36 righ tofc Feb 25 12:53:39 right ofc* Feb 25 13:03:50 eesh Feb 25 13:04:13 im gonna have a crack at using ur py lib to debug why my code isnt working Feb 25 13:04:40 I hope the examples are self-explanatory enough, there isn't much documentation yet Feb 25 13:05:01 I added one wiki page related to mapping memory Feb 25 13:05:43 be sure to install etc/udev/rules.d/09-uio-pruss.rules Feb 25 13:06:09 (and either reboot, or unload and load the uio_pruss kernel module) Feb 25 13:06:15 otherwise it can't find the uio device Feb 25 13:07:08 (unlike prussdrv, I don't hardcode the assumption that /dev/uio0 - /dev/uio7 belong to uio-pruss, since that would break horribly if you have more uio devices, and I personally do use uio for purposes other than pruss) Feb 25 13:07:34 i did do that Feb 25 13:08:00 ok :) Feb 25 13:10:28 I should update the readme Feb 25 13:14:25 yeah prolly lol Feb 25 13:14:29 brb Feb 25 13:21:02 the default beaglebone images already include udev rules to give you access to uio devices right? Feb 25 13:23:45 anyone? Feb 25 13:24:13 (I'm hoping to be able to be lazy and not have to download and inspect the default image :P ) Feb 25 13:27:29 zmatt: just so you know, i saw ur message but hoplessly out of my league Feb 25 13:27:33 :p Feb 25 13:28:23 did you install any .rules file from py-uio other than 09-uio-pruss.rules? (I just renamed it to just uio-pruss.rules btw) Feb 25 13:28:56 no i did not Feb 25 13:29:05 what does ls -l /dev/uio0 say? Feb 25 13:29:38 crw-rw---- 1 root users 240, 0 Feb 25 13:15 /dev/uio0 Feb 25 13:29:43 ok thanks Feb 25 13:29:46 that's all I needed to know Feb 25 13:34:02 hey if i do memset(pruDRAM0_32int_ptr, 0, 4*4) will it write 0 to the first 4 regs of DRAM? Feb 25 13:34:16 assuming pruDRAM0_32int_ptr pointed to DRAM ? Feb 25 13:34:28 yes Feb 25 13:35:20 well, see i have a pwm generator, and my program is working (well sorta), but before starting i want to initialise all channels to 0, so i do the memset thing and then it doesnt work Feb 25 13:35:26 however without memset it works Feb 25 13:35:47 heres the asm code: https://github.com/Thalaivar/dobby/blob/master/pru/pwm_src/pwm.p Feb 25 13:36:03 heres the c file that sets the dram values Feb 25 13:36:04 https://github.com/Thalaivar/dobby/blob/master/pru/pwm_src/pwm.cpp Feb 25 13:37:34 is it because once it is set to 0, the thing subtracts and starts subtracting this huge number Feb 25 13:38:05 just a random remark: instead of just documenting what the various registers do in comments, you can also define the parameter struct in pasm and bind that to r0-r4 (see my pruss-intc-test.pasm and .py for an example of that) Feb 25 13:38:21 okay i will check it out Feb 25 13:38:26 yes, you're subtracting before testing Feb 25 13:38:46 so if you initialize it to zero, then after the first subtraction it becomes 0xffffffff Feb 25 13:39:44 okay, any other remarks are welcome :p Feb 25 13:39:57 this is my first attempt at asm properly so i need the critique Feb 25 13:41:21 wait, the last bit of your code doesn't make sense to me Feb 25 13:41:41 shouldn't it be qbne INNER_LOOP ? Feb 25 13:41:50 instead of DELAY_OFF Feb 25 13:42:07 uhh Feb 25 13:42:29 actually I see multiple problems Feb 25 13:42:47 no thats the part where the longest pwm pulse has been sent out, now we have to wait till 20000us have passed since the start of all the pulses to maintain 50Hz Feb 25 13:42:55 yeah tell me everything Feb 25 13:43:09 okay lemme look a bit longer to see if I understand what you're doing Feb 25 13:46:37 so, the high-time of channel 4 is always greater than or equal to the high-time of channels 1-3 ? Feb 25 13:47:28 ahhh good catch Feb 25 13:54:48 anything else? Feb 25 13:54:57 there's also the annoying issue that the number of cycles per loop iteration is not constant right now Feb 25 13:55:03 because of all the branches that skip one instruction each Feb 25 13:55:10 I'm trying to think of the best way to fix that Feb 25 13:55:54 oh you mean cases when CLR takes place and when it doesnt Feb 25 13:56:00 yes Feb 25 13:56:12 wont that just result in a error of the order of 10ns? Feb 25 13:57:37 you have to pass through all of them for each inner loop iteration, so skipping even one instruction is going to make a big difference Feb 25 14:01:33 so like, if I ignore that issue, I might write https://pastebin.com/raw/e45CnJdM Feb 25 14:01:51 (I made the period a parameter just to make it easier to play with) Feb 25 14:02:10 ah right, but that only happens once per main loop Feb 25 14:02:13 for each channel Feb 25 14:03:21 so yes it means that the high-time of each channel will depend on that of other channels, but only by 15 ns or so worst case I think? Feb 25 14:03:32 if your pwm frequency is 50 Hz, I understand that you don't care Feb 25 14:04:58 wait if i got you correctly, you were saying at max i would be skipping 4 instructions Feb 25 14:05:02 so 20ns at max Feb 25 14:05:09 one ugly thing I don't like is that even if all channels are set to zero, there will still be a brief (15-45 ns) spike on each channel Feb 25 14:05:25 how? Feb 25 14:05:39 they're unconditionally set in the outer loop Feb 25 14:05:47 and then cleared in the first iteration of the inner loop Feb 25 14:05:52 (in my version at least) Feb 25 14:07:46 I don't know if it matters for your application Feb 25 14:08:08 oh you mean where all channels are set high? Feb 25 14:08:23 ? Feb 25 14:08:24 yes, that happens unconditionally Feb 25 14:08:30 even if all channels are set to zero Feb 25 14:08:31 nah thats chill :p Feb 25 14:09:06 like I said, I don't know if it matters to have a max 45 ns spike every 20 ms, it just seems... dirty... to me Feb 25 14:09:22 we could always add checks before the bits are set high Feb 25 14:09:36 if a channel is 0 when it s read, dont ever set that bit high? Feb 25 14:10:30 yeah, or you could make it a parameter to allow userspace to select which channels are enabled Feb 25 14:11:15 yeah cool ill look into that Feb 25 14:11:30 what do you think of my version btw? some differences are obviously a matter of personal taste (e.g. I'm not a fan of using all-uppercase for stuff other than constants and macros) Feb 25 14:12:04 i loved how you tackled the major issue in my code about the last channel Feb 25 14:12:13 mind if i use that solution? :p Feb 25 14:12:52 yes, I made this example for you to admire, but now you must erase it from your mind and make sure to write something different instead Feb 25 14:12:55 :P Feb 25 14:13:05 lol Feb 25 14:14:14 is it clear how the .struct and .assign work btw? the nice thing is that you can declare the same struct in C, and then cast the memory pointer to (volatile struct Params *) to access it Feb 25 14:16:27 oh lol I made two typos Feb 25 14:16:40 r30.r10 should be r30.t10 obviously (and same for .t11) Feb 25 14:16:44 ok so in ".assign Params, r4, r8, params", you are assigning r4 to r8 registers teh corresponding Params members Feb 25 14:16:54 and calling that struct params? Feb 25 14:17:01 bah i corrected that thats chill :) Feb 25 14:17:18 basically it's declaring struct Params params; and making it reside in r4-r8 Feb 25 14:17:27 okay Feb 25 14:17:33 so params is the name of the "variable" Feb 25 14:17:45 hence that's what's referenced in the code Feb 25 14:17:59 (you can obviously have more than one variable of the same struct type in your code) Feb 25 14:18:23 i didnt get what you meant by the C thing Feb 25 14:18:29 yeap got that : Feb 25 14:18:31 :) * Feb 25 14:21:51 https://pastebin.com/NSQyj6Hm Feb 25 14:22:11 whoa Feb 25 14:22:13 serious? Feb 25 14:22:34 why is that so surprising? Feb 25 14:22:46 idk i just never thought you could do it this way Feb 25 14:23:00 so params.ch1 = X will load X into r4 Feb 25 14:23:35 it'll write X to the memory location which, at the start of the next pwm period, will get loaded into r4 yes Feb 25 14:24:03 you can replace the ch1-ch4 fields by u32 ch[4]; if you prefer of course Feb 25 14:24:35 okay cool Feb 25 14:24:39 thats amazing infp Feb 25 14:24:43 info* Feb 25 14:25:42 watit a min Feb 25 14:25:46 so i dont need the LBCO call then? Feb 25 14:25:52 yes you do Feb 25 14:25:59 cuz itll directly load into r4 right? Feb 25 14:26:15 oh Feb 25 14:26:17 wait Feb 25 14:26:18 sorr Feb 25 14:26:21 sorry* Feb 25 14:26:23 C accesses the data ram Feb 25 14:26:31 lbco loads it from data ram into registers Feb 25 14:26:33 uh huh go on Feb 25 14:26:51 so what happens when i do params.ch1 = X it gets loaded into DRAM? Feb 25 14:26:53 oh btw above you said params.ch1, that should be params->ch1 of course Feb 25 14:27:24 yeah Feb 25 14:27:27 yes, params in C points to a struct Params located (at offset 0) in pru memory Feb 25 14:27:52 params in the pru code is a struct Params located in r4-r8 Feb 25 14:27:59 so the params in C is not the same as the params in asm? Feb 25 14:28:27 the lbco loads a struct Params from data ram (c24) offset 0 into 'params' (i.e. r4-r8) Feb 25 14:28:36 correct Feb 25 14:29:33 and why volatile params in C as opposed to static? Feb 25 14:29:53 static and volatile are totally unrelated concepts Feb 25 14:30:01 oh Feb 25 14:30:03 I was already puzzled at why you were using static in your code Feb 25 14:30:04 lol ok Feb 25 14:30:35 'static' also has multiple meanings unfortunately... it means something different for local variables inside a function than for variables at file-scope Feb 25 14:30:51 (and yet again something different for struct/class members in C++) Feb 25 14:30:53 right ill read up on that Feb 25 14:31:22 so, if we rename the 'params' in C to the perhaps more accurate 'paramsPtr' Feb 25 14:31:55 then the lbco is basically memcpy(¶ms, paramsPtr, sizeof(params)); Feb 25 14:32:03 (where 'params' here does mean r4-r8) Feb 25 14:33:35 yep got it now :) Feb 25 14:35:40 btw, if you mix fields of different sizes (u8/u16/u32), be sure to stick __attribute__((packed)) onto the C struct to indicate that no alignment padding should be used (since pru doesn't use any), or manually make sure all fields are naturally aligned Feb 25 14:36:22 actually, you'll probably want to do the latter Feb 25 14:36:50 ? Feb 25 14:36:50 meaning put all data types same Feb 25 14:37:12 u8 x; u32 y; would put y at offset 1, which is not a multiple of 4 bytes Feb 25 14:37:24 that's not "naturally aligned" Feb 25 14:37:51 naturally aligned means the offset is a multiple of 4 for u32, a multiple of 2 for u16, or any offset for u8 Feb 25 14:38:03 ok got it Feb 25 14:38:14 the simplest fix in this example would just be to swap the order of x and y Feb 25 14:38:38 the alternative is inserting 3 bytes of padding between them Feb 25 14:39:04 C would insert that padding implicitly. pasm doesn't Feb 25 14:39:13 padding would be? Feb 25 14:39:27 unused fields Feb 25 14:39:47 just to take up the necessary space Feb 25 14:43:44 id have to cast paramsPtr again as uint32_t* again right? Feb 25 14:43:49 after prumem()? Feb 25 14:43:54 ?? Feb 25 14:44:00 what? Feb 25 14:44:07 for what? Feb 25 14:44:15 prussdrv_map_prumem(PRUSS0_PRU1_DATARAM, (void **) ¶ms); after this Feb 25 14:44:24 wont the type of params be void* Feb 25 14:44:25 ? Feb 25 14:44:26 why would you want to cast it again? Feb 25 14:44:28 no Feb 25 14:44:35 params is a struct Params volatile * Feb 25 14:45:03 (or equivalently volatile struct Params * but I have reasons for not writing it like that) Feb 25 14:45:09 ok since ur passing it as (void**) only in the function Feb 25 14:45:21 yes because that's the type prussdrv_map_prumem requires Feb 25 14:45:22 it stays as struct Params volatile * Feb 25 14:46:00 that cast can't magically change how 'params' is declared Feb 25 14:46:11 yes got it Feb 25 14:46:49 basically that's to avoid declaring a temporary void *memoryPtr; variable, passing &memoryPtr to prussdrv_map_prumem, and then doing params = (struct Params volatile *) memoryPtr; Feb 25 14:47:59 well you improved my code a lot Feb 25 14:48:01 it would have been more convenient if they just returned the mapped pointer (or NULL on error) instead Feb 25 14:48:03 thanks for that Feb 25 14:48:35 thats prussdrv for you... Feb 25 14:49:04 anyway, ive been on this for far too long, ill take a break now, get back at it tomorrow, thanks for all your help btw! Feb 25 14:49:42 especially since it can't return different error codes anyway Feb 25 14:49:44 all errors are -1 Feb 25 14:49:51 your techinqure was inspiring :p Feb 25 14:49:52 (see prussdrv.c) Feb 25 14:50:12 technique* Feb 25 14:50:25 the implementation of map_prumem really makes you wonder why the fuck that's even a function Feb 25 14:50:52 for newbs like me who dont know how it all works under the hood? Feb 25 14:51:19 its existence doesn't make it easier for noobs Feb 25 14:51:19 tbh this learning curve is quite steep for a non code-enthusiast Feb 25 14:51:20 but harder Feb 25 14:51:53 im not into embedded programming at all, i study control systems so this who PRU thing has been really hard for me Feb 25 14:52:04 if they just exposed the global prussdrv struct then you could just do params = (struct Params volatile *) prussdrv.pru1_dataram_base; Feb 25 14:52:34 you could make ur C++ lib public Feb 25 14:52:40 after the necessary mods Feb 25 14:52:51 I might, eventually Feb 25 14:53:03 https://github.com/beagleboard/am335x_pru_package/blob/master/pru_sw/app_loader/interface/prussdrv.c#L580-L599 Feb 25 14:53:09 here's what map_prumem looks like :) Feb 25 14:53:41 so that is pruss.dram1? Feb 25 14:53:47 in ur py code i mean Feb 25 14:53:50 yes Feb 25 14:53:52