**** BEGIN LOGGING AT Mon Mar 19 03:00:02 2018 Mar 19 03:01:14 Hello! Mar 19 03:01:44 my entire system crashed due to whatever. Odd days. Mar 19 03:04:35 Blame static, it's still cold weather in most places and that leads to low indoor humidity. :P Mar 19 03:05:27 if not, you can always blame cosmic rays Mar 19 03:05:57 I thought it was the, you know, those people. Mar 19 03:06:44 I am not checking logs or any of that junk. I am going clueless on purpose. Mar 19 03:07:20 <<<<< setting up a new image and trying that server again Mar 19 03:08:01 cosmic rays are a real problem for electronics though Mar 19 03:08:12 Oh. Mar 19 03:08:39 moreso for electronics in orbit, but yeah, it's why we have ECC RAM, among other things Mar 19 03:09:26 I still think it's complete bullshit that non-ECC RAM is still being used Mar 19 03:09:55 the only excuse for not using ECC is if you don't care at all about your data :-/ Mar 19 03:09:58 Well...I guess that is how to brick a system. Mar 19 03:10:09 TETHER_ENABLE=no bricks the system. Mar 19 03:11:05 seriously Mar 19 03:11:11 Yep. Mar 19 03:11:23 Memory controllers can handle the ECC overhead no problem Mar 19 03:11:43 fortnight: are you sure? my impression was that you just rendered yourself unable to login because you were logging in via tethering :P Mar 19 03:12:01 Oh. What does that mean? Mar 19 03:12:02 that's not the same as breaking the system Mar 19 03:12:05 Heh. It's not bricked until there's no response on the console. Mar 19 03:12:18 I cannot sign in b/c there is no response. Mar 19 03:12:21 and even then... you might've just disabled the console getty :P Mar 19 03:12:21 also, it's not "bricked" in any case since you can recover trivially Mar 19 03:12:29 How can I recover? Mar 19 03:12:34 hahaha, that's not bricked, that's just you locked yourself out, knucklehead ;) Mar 19 03:12:42 Nice story. Mar 19 03:12:43 console access, perhaps? Mar 19 03:12:55 reflashing, using a serial console, booting from another medium and then fixing the config file, etc Mar 19 03:12:57 Welp. Off to Linux. Mar 19 03:13:01 actually, didn't you say you were using an sd card? Mar 19 03:13:06 Yep. Mar 19 03:13:12 I reflashed. Mar 19 03:13:12 so you can just stick the sd card into a linux system and fix the config file Mar 19 03:13:19 I tried. Mar 19 03:13:57 in any case, a system is bricked if it's basically nothing more than a brick, a useless dead piece of hardware... that is not the case here Mar 19 03:14:11 in fact it's close to impossible to brick the bbb unless you literally fry the hardware Mar 19 03:14:28 Okay. Where can I get info. about my current issue? Mar 19 03:14:45 It is on, the LEDs blink, and the system is not responding. Mar 19 03:15:12 you know exactly what's causing it: that line in the config file you changed Mar 19 03:15:19 Yep. Mar 19 03:15:31 "not responding" to one very complicated access means that you removed part of, but still responding to all the other things you're not connecting to Mar 19 03:15:34 it just sounds to me like it's doing exactly what you asked of it Mar 19 03:15:45 is not the same as broken Mar 19 03:15:58 why did you do this again anyway? Mar 19 03:16:06 Okay...I like fruit loops as much as the next person but you are not helping. Mar 19 03:16:07 you already knew the outcome Mar 19 03:16:14 Wrong. Mar 19 03:16:16 and the fact that it's a weird thing to do Mar 19 03:16:33 you want tethering enabled, not disabled Mar 19 03:16:36 I was listening to instructions from a "reliable" source. Mar 19 03:16:57 anyway, just stick the sd card into a linux system of choice and fix the config file Mar 19 03:17:05 or reflash, whichever you prefer Mar 19 03:17:17 I reflashed and it still is not responding. Mar 19 03:17:33 Oh...I have to reflash the eMMC. Mar 19 03:17:34 Got it now. Mar 19 03:17:37 what? Mar 19 03:17:42 you were booting from sd card weren't you? Mar 19 03:17:46 Nope. Mar 19 03:17:48 I am now. Mar 19 03:17:51 you've being really confusing Mar 19 03:17:57 That is me. Mar 19 03:18:08 Dazed and confused. Mar 19 03:18:37 if you did this on eMMC, and you've booted from sd card now, then you can now fix the config file on eMMC Mar 19 03:18:47 Okay. Mar 19 03:18:52 See you soon! Mar 19 03:19:24 <<<< on break Mar 19 03:21:29 ooooooh, I just looked at hostnames. Lightbulb just went on. Right right. Mar 19 03:21:42 hmm? Mar 19 03:22:19 oh you mean fortnight == bien_salad == set and probably more nicknames I've already forgotten Mar 19 03:22:25 bingo Mar 19 03:22:36 yeah I don't know what's up with that. it's a bit annoying, fortunately he's really easy to recognize once he starts talking Mar 19 03:22:47 yeah :) this is the first time it took me more than a minute Mar 19 03:23:44 You guys are so fart. Way to go! Mar 19 03:23:50 sorry smart. Mar 19 03:23:52 it generally doesn't take long before I'm staring at irc with a "wha?" expression Mar 19 03:40:43 i'm having a hell of a time tryign to write a dts overlay to get gpio-pins running Mar 19 03:41:14 "gpio-pins" ? Mar 19 03:41:21 you mean gpio helper? Mar 19 03:41:44 https://pastebin.com/CPiC2CnB Mar 19 03:42:12 you can turn that dts fragment into an overlay using my https://github.com/mvduin/overlay-utils Mar 19 03:42:32 cool! Mar 19 03:42:35 this is what i had Mar 19 03:42:37 https://gist.github.com/kenrestivo/6cc6a0f14bfda09a918e873897546fae Mar 19 03:42:46 oh there's actually a gpio demo in my overlay-utils project too... I forgot about that Mar 19 03:43:02 it has plenty of comments too Mar 19 03:43:08 thanks Mar 19 03:43:40 oh lol actually my pastebin paste won't compile in overlay utils since it has different macros for pinmux Mar 19 03:44:12 oh gpio-keys Mar 19 03:44:38 the target you have doesn't exist Mar 19 03:44:48 ah, what would be the correct target? Mar 19 03:45:10 (also there's probably no need to add a global "keypad:" label to your keypad node) Mar 19 03:45:31 thanks, it doesn't need to be referenced anywhere Mar 19 03:46:30 what i'm trying to work from is: https://www.kernel.org/doc/Documentation/devicetree/bindings/input/gpio-keys.txt Mar 19 03:46:41 note the example nodes don't have a target, really Mar 19 03:47:10 I'd say / is fine as target here since your device is a virtual one... I think there's something like target-path for that iirc Mar 19 03:47:22 or if you use my overlay utils you can just write it like this: https://pastebin.com/raw/iNw7dFW1 Mar 19 03:47:23 "/soc" or something? Mar 19 03:47:48 oh! that makes more sense. thanks Mar 19 03:48:16 (my makefile runs sources through a perl script that convert them into the obnoxious verbiage required for overlays before running that through dtc) Mar 19 03:48:17 but, doesn't it need to have "fragment0"? and __overlay___? Mar 19 03:48:25 perfect, thanks Mar 19 03:48:31 that's what my perl script takes care of Mar 19 03:48:35 beautiful Mar 19 03:48:40 honestly I don't understand why dtc doesn't do this itself Mar 19 03:48:47 submit patch? Mar 19 03:49:01 you obviously know how to fix it. Mar 19 03:49:59 I've put a tiny bit of effort into patching dtc, but I always end up with bison complaining about my grammar... I'd honestly rather rewrite dtc as a perl script :P Mar 19 03:50:04 fuck bison Mar 19 03:50:34 but I don't actually use overlays myself, so that reduces motivation Mar 19 03:50:39 and this workaround works well enough Mar 19 03:50:43 cool, thanks Mar 19 03:51:34 do beware that my perl script doesn't attempt to parse the full dts grammar, it expects you use sane indenting (but it does perform some sanity checking) Mar 19 03:52:34 also, you should probably add pinmux declarations to your overlay to ensure the pins are muxed to gpio (and considered to be "in use" by the kernel) Mar 19 03:52:49 even though gpio is usually the default, it's better to be explicit Mar 19 03:53:27 if you use overlay-utils, it includes macros that make pinmux fairly easy to do. just look at the various examples Mar 19 03:54:28 huh interesting Mar 19 03:54:30 cpp -nostdinc -undef -x assembler-with-cpp -D__DTS__ -I include i2c1.dtsi -pipe | bin/dtsi-to-overlay Mar 19 03:54:39 you use cpp, i guess for handling #includes? Mar 19 03:54:49 yes, same as the kernel Mar 19 03:54:55 also to strip comments Mar 19 03:55:07 and macros Mar 19 03:55:20 so i still need pinmux even tho i'm using gpio-keys driver? Mar 19 03:55:36 pinmux is not an implicit part of any driver Mar 19 03:56:03 gotcha. so even if the default settings are right, i should be explicit Mar 19 03:56:13 I would recommend that yes Mar 19 03:56:14 (i.e. read only pin, default pullup settings, etc) Mar 19 03:56:29 thanks Mar 19 03:57:00 yeah, although actually the different between PIN_(GP)IN and PIN_(GP)IO is purely for documentation, there's no actual way to make pins in-only Mar 19 03:57:07 (unfortunately) Mar 19 03:57:30 (GP)OUT is genuinely different since it disables the receiver (input buffer) Mar 19 03:59:43 # this assumes input is CPP processed and properly indented Mar 19 03:59:53 assume "properly" means emacs auto-indent? Mar 19 04:00:19 I mean the contents of a braced-block needs to be indented Mar 19 04:00:26 that's about it I think Mar 19 04:00:42 it just parses Mar 19 04:00:44 TARGET { Mar 19 04:00:46 whatever Mar 19 04:00:47 }; Mar 19 04:00:59 and top-level properties Mar 19 04:02:02 that should work then Mar 19 04:04:38 also, multi-line top-level properties need to have all lines but the first to be indented Mar 19 04:05:07 see TT3201-001-01.dtsi for example Mar 19 04:37:17 what's the difference between P9_15a and P9_15b ? Mar 19 04:37:32 they're two cpu pins connected to the same expansion header pin Mar 19 04:38:56 so when using one of them you should just configure the other one to gpio with pull in the same direction or pull disabled (e.g. PIN_GPOUT_NOPULL) Mar 19 04:39:24 if you use the pin for gpio, it doesn't matter which one you use Mar 19 05:21:39 That software is complicated. I am going to try another night or during the day. That dude can write some software. Mar 19 05:22:02 ...he was talking about being a new person to software or something in embedded development. Not to me! Mar 19 05:22:10 ... Mar 19 05:22:17 and for that, goodnight. Mar 19 05:56:56 I have a beaglbone black and now when i connect it to my pc it is not shown in my pc, why?? Mar 19 05:57:09 I just reset it once Mar 19 05:57:44 Gaman: what are the LEDs doing? Mar 19 05:57:51 The power led and boot leds are working properly Mar 19 05:58:05 only 1 boot led blinking Mar 19 05:58:12 'out of 4 Mar 19 05:58:35 I don't think that's fully booted Mar 19 05:58:49 Do you have a USB2serial adapter? Mar 19 05:59:16 when i plugged in my pc all the 4 leds blinking at that time Mar 19 05:59:20 yes i have Mar 19 05:59:47 make sure it's set to 3.3V and connect it to the debug UART port Mar 19 06:00:17 yes its properly connected Mar 19 06:00:46 actually before reset the beagle is working properly Mar 19 06:01:03 but now i don't know its not showing in my pc Mar 19 06:01:07 then check your terminal software for output from the debug UART Mar 19 06:01:46 how can i check that?? Mar 19 06:02:22 you said you have a USB-to-serial cable connected to the debug-UART port. I assumed that you have used that before. Mar 19 06:03:01 yaa i have but if it not showing in my pc then how can i check it Mar 19 06:03:16 no port is showing connected to beaglbone Mar 19 06:03:55 i have one more beagle with me and it working properly Mar 19 06:03:56 I am NOT talking about a regular USB cable! Mar 19 06:04:20 then?? Mar 19 06:06:04 pleae help Mar 19 06:06:19 please* Mar 19 06:07:20 I'm asking again. Do you own a USB to UART adapter? Mar 19 06:09:11 if you only have a regular USB cable then the answer is no Mar 19 06:15:24 yes i have both Mar 19 06:16:07 usb to uart adapter as well as regular cable Mar 19 06:17:36 so, are you able to connect the UART adapter to the BBB? Mar 19 06:21:03 *shrug* Mar 19 06:21:56 I need someone's help as my beagle is not working after doing the reset Mar 19 06:22:44 before reset it works properly but now i don't know what happen it's not showing in my pc Mar 19 06:23:09 06:17:36< tbr> so, are you able to connect the UART adapter to the BBB? Mar 19 06:27:37 well, I have to leave now. good luck. Mar 19 06:28:53 i just trying to connect Mar 19 06:29:17 actually i used the regular usb cable for beagle to pc connection Mar 19 06:30:24 the boot leds are on for the first time then after only first led i s blinking Mar 19 06:33:28 any one is there for my help?? Mar 19 06:37:42 need help regarding this Mar 19 06:38:09 otherwise i am not able use it there after Mar 19 06:48:34 d'awww Mar 19 06:50:01 My beagle bone balck is not working Mar 19 06:50:12 just reflash it Mar 19 06:50:26 'its not showing in my pc when i connect it to the pc through usb cable Mar 19 06:50:30 just reflash it Mar 19 06:50:41 i did Mar 19 06:50:48 but nothing happen Mar 19 06:50:56 i reset it once Mar 19 06:51:01 http://beagleboard.org/latest-images Mar 19 06:51:07 which steps did you follow exactly? Mar 19 06:51:29 "reset" and "reflash" are very different things Mar 19 06:51:41 i write the image in the sd card and then plug in beaglebone Mar 19 06:51:49 first it work properly Mar 19 06:52:09 but after reset the beagle its not showing in my pc Mar 19 06:52:19 what do you mean with "reset" ? Mar 19 06:52:41 what exactly did you do? Mar 19 06:52:46 there is a button there na in beagle bone Mar 19 06:52:52 i pressed it once Mar 19 06:53:13 okay, what did you do right before that? what made you press the reset button? Mar 19 06:53:14 after that its not showing Mar 19 06:53:43 actually my sd card is not properly working with the beagle Mar 19 06:53:53 so i just reset it Mar 19 06:53:59 you're not making any sense Mar 19 06:54:14 actually i have 2 beagle bone black Mar 19 06:54:31 the same sd card working properly with 1 beagle bone Mar 19 06:54:47 but its not working with other beagle bone Mar 19 06:55:05 so i just reset the beagle boneso that it may start working Mar 19 06:55:37 okay I give up on trying to interrogate you. you're being way too vague, and you're not giving useful answers Mar 19 06:56:10 what you wanted to know?/ Mar 19 06:57:36 what it means if only 1 led is blinking out of 4 boot leds?/\ Mar 19 07:02:06 heartbeat pattern? Mar 19 07:02:34 what? Mar 19 07:02:55 is it blinking in a hearbeat pattern? (two blinks, pause, two blinks, pause, etc) Mar 19 07:03:19 only one Mar 19 07:03:37 * zmatt gives up Mar 19 07:04:14 the first one is blinking continuously Mar 19 07:05:24 yaa actually it like a heartbeat pattern (two blinks, pause, two blink pause) Mar 19 07:11:19 anybody knows how can we do the trouble shooting of beagle bone Mar 19 07:11:32 if its not working Mar 19 07:11:44 ok finally an answer. heartbeat pattern simply means the system is running normally Mar 19 07:12:02 but its not showing in my pc Mar 19 07:12:17 you said earlier that it was working properly initially Mar 19 07:12:27 yes 3 days ago Mar 19 07:12:55 and then something happened Mar 19 07:12:59 actually i buy it 15 day s ago Mar 19 07:13:27 what were you doing when the problems started? Mar 19 07:13:49 reset the beaglebone' Mar 19 07:13:54 before that Mar 19 07:14:00 you must have had a reason to reset the beaglebone Mar 19 07:14:33 yaa actually somehow the image which i insert into the sd card is not working properly with the beagle bone Mar 19 07:14:50 so i reset the beagle bone Mar 19 07:15:01 so that it may start working again Mar 19 07:15:21 but it stopped working after that Mar 19 07:15:27 * zmatt sighs Mar 19 07:16:14 you're not actually clarifying anything, you just keep repeating it is "not working" but that is not a useful way to describe a problem Mar 19 07:16:20 nobody can possibly debug "it's not working" Mar 19 07:16:58 actually when we connect the beagle bone with pc the beagle will shown in the storage device Mar 19 07:17:07 but its not showing there Mar 19 07:17:35 I don't have the energy for this, sorry. it is just too tiresome to try to help you Mar 19 07:17:42 maybe someone else can help you Mar 19 07:17:47 please help Mar 19 07:18:19 actually beagle bone has its own storage which is shown when we connect it to the pc with usb cable Mar 19 07:18:48 but in my case its not showing Mar 19 07:19:29 so i can't do anything in my beagle bone unless it not showing or not connected with putty Mar 19 07:21:31 Also beagle's driver is not showing in my device manager Mar 19 07:51:34 hi every bodu Mar 19 17:44:39 Hi Mar 19 17:45:22 i am looking for BBBL system reference manual Mar 19 17:45:49 can any one help me to get it? Mar 19 17:46:19 I think the wiki is the closest thing it has to an SRM right now... https://github.com/beagleboard/beaglebone-blue/wiki Mar 19 17:48:33 Thanks Mar 19 19:14:40 zmatt, I'm looking over your ddr ping example (the assembly that runs on the PRU). It looks to me like the code loads 4 bytes into register r0 from the memory address in r4, then copies these 4 bytes from r0 into the memory address r4+4. Mar 19 19:15:02 https://pastebin.com/D9K6YTm6 Mar 19 19:16:40 The python code loads r4 with the value pruss.ddr.address, which has a value of 2635333632 in decimal. Mar 19 19:19:21 It then writes to the first shared memory location, then reads from the second memory location. Mar 19 19:19:39 Why is it that there is an offset of 4 bytes added to r4? Mar 19 19:20:03 Is it because the c_uint32 data type has 4 bytes? Mar 19 19:49:02 yes. r4 points to two words (32-bit ints), one at offset 0 and one at offset 4 Mar 19 19:49:24 btw, addresses generally make more sense in hexadecimal than in decimal ;) Mar 19 19:50:17 a more elegant solution would be to use a struct like I do in pruss-intc-test Mar 19 20:02:21 Got it! Mar 19 20:28:13 So what exactly does the function call shmem = pruss.ddr.map( c_uint32 * 2 ) do? Mar 19 20:28:57 It makes a python array of length 2 where each element is a piece of ddr memory? Mar 19 20:31:11 it's not a python list or tuple, it's an instance of the c_uint32 * 2 type, which is basically like a python version of the uint32_t[2] type in C Mar 19 20:31:29 Ok, Mar 19 20:32:23 (but that type behaves mostly like a 2-element array) Mar 19 20:33:43 although it's fixed-length (unlike a python list) and modifiable (unlike a python tuple) Mar 19 20:36:02 but regardless of how it works exactly the end result is what you expect: shmem[0] and shmem[1] directly represent the two words in the pru's ddr memory region Mar 19 20:48:53 Cool! Mar 19 20:49:00 What am I doing wrong with this assembly code? https://pastebin.com/Y8fDuACM Mar 19 20:49:37 I'm a little unsure of the syntal for assembly. Capitalization doesn't matter right? Mar 19 20:49:58 As far as instructions themselves go? Mar 19 20:49:59 *syntax Mar 19 21:00:29 what problem are you having with it? Mar 19 21:00:50 it looks fine to me Mar 19 21:06:24 although this might be nicer: https://pastebin.com/raw/p6tb2uPD Mar 19 21:07:20 uhh, I fucked up the comments Mar 19 21:08:01 https://pastebin.com/raw/yNwBQDYM fixed Mar 19 21:23:48 I looked at the T0 pin and it isn't changing at all, Mar 19 21:24:54 are you sure the program is running? are the pins muxed correctly? Mar 19 21:24:55 This is how I called it https://pastebin.com/k06ju0iT Mar 19 21:25:09 Oh, forgot about pins! Mar 19 21:25:16 :) Mar 19 21:25:20 Is there a way to do that from the python file? Mar 19 21:25:34 My makefile used to do that for me Mar 19 21:25:46 which is a really really weird place to do it Mar 19 21:26:13 *was Mar 19 21:27:14 but yes, since config-pin (which is merely a shell script) just modifies some sysfs attributes it can certainly be done in python too, but I'd need to look at what config-pin does exactly Mar 19 21:27:29 why not just put your config-pin commands in /etc/rc.local ? Mar 19 21:27:32 lol, yeah Mar 19 21:28:44 btw, keep in mind that your modified python program is kinda pointlessly causing 100% cpu load. you can just do core.run() and let the script finish (the pru will keep going) Mar 19 21:28:58 Got it Mar 19 21:34:40 ok, still not working... Let me think what else could be wrong. I'll try your ASM program Mar 19 21:35:18 they should be equivalent Mar 19 21:35:47 (well, yours pointlessly repeated the clr/set of T0 while waiting for DRDY, but other than that they're equivalent) Mar 19 21:38:17 Ok, I'm using your ASM code Mar 19 21:38:30 I make the binary with pasm -b HWL_ping.pasm Mar 19 21:38:36 then run this python code https://pastebin.com/2Z61yULV Mar 19 21:39:31 hm now I'm actually starting to doubt whether the pru core keeps running... there might actually be a chance that prcm kicks in once the device is closed Mar 19 21:40:28 I'll add while True: loop at the end Mar 19 21:40:59 Still not working, Mar 19 21:42:11 Your example with the DDR write and read worked fine, just not my program Mar 19 21:43:17 Ooops, I think I was using PRU1 previously, your code is PRU0 Mar 19 21:43:23 lol Mar 19 21:43:37 I was literally just thinking "is he using the right core?" Mar 19 21:45:15 That was it! Now I have T0 following DRDY step for step. Mar 19 21:45:52 the other suggestion I was going to do was checking whether you can confirm the inputs are working using https://pastebin.com/7mA5c03t ... it might be useful to know you can actually do something like that :) Mar 19 21:46:30 I didn't know that you could do that! Mar 19 21:46:40 So the ARM can modify anything that the PRUs can? Mar 19 21:46:59 yes. you can only access core.r[] when the core is halted though Mar 19 21:47:25 But even when halted writing to r31 makes the pin toggle? Mar 19 21:47:32 r30 Mar 19 21:47:33 yes Mar 19 21:48:29 Interesting, I reallly like your python code. I feel that it helps me understand what is actually going on between the ARM and PRU Mar 19 21:49:14 if you want to know more about how the pru core is being controlled, there are also a lot of comments in ti/icss/core.py Mar 19 21:49:17 I thought the communication between the PRU and ARM was much more limited. Mar 19 21:49:21 Ok, Mar 19 21:58:58 So does pruss.ddr.address always return the same address? If so, is this address listed in the PRU-ICSS Reference Guide? Mar 19 21:59:39 I see the local and global memory maps, but I don't see any entried for anything like DDR or system RAM. Mar 19 21:59:44 definitely not Mar 19 21:59:59 it points to a piece of physical memory allocated by the uio_pruss driver Mar 19 22:00:24 (the size of which can be configured using a module parameter) Mar 19 22:01:15 Ok. Are the range of possible memory addresses for this allocated memory listed in the reference guide? Mar 19 22:01:34 I see an entry for System OCP_HP0 and HP1 Mar 19 22:01:58 anywhere in external ram, which starts at 0x80000000 Mar 19 22:03:14 Is that info in the reference guide (that external ram starts at 0x80000000)? Mar 19 22:03:41 yes, table 2-1 shows the L3 memory map Mar 19 22:03:48 chapter 2 Mar 19 22:06:06 I also have a memory map spreadsheet for the am335x (aka subarctic) and some related SoCs here: https://goo.gl/UHF2Fy Mar 19 22:06:08 Sorry, I don't see that. Table 1 is PRU-ICSS Connectivity Attributes Mar 19 22:06:32 uhh, I'm referring to the am335x technical reference manual Mar 19 22:07:45 Got it! Wrong guide.... Mar 19 22:07:53 Thanks for the memory map spreadsheet! Mar 19 22:10:22 the memory map of the pru cores is simple: everything below 0x80000 is routed to the pruss interconnect, while 0x80000-0xffffffff is routed to the L3 interconnect (hence the L3 memory map applies for it) Mar 19 22:10:38 Cool! Mar 19 22:11:11 I see in your core.py there is a Core class with field "control" Mar 19 22:11:42 I assume this refers to the PRUx control register? Mar 19 22:12:11 For the PRU this is at address 0x002_4000 or 0x002_2000 Mar 19 22:12:41 correct Mar 19 22:12:49 you can see that in ti/icss/__init__.py Mar 19 22:12:53 Depending on the PRU. So does your code just update the corresponding fields and then write to these memory addresses? Mar 19 22:12:54 self.core0 = self.map( Core, 0x22000 ) Mar 19 22:12:54 self.core1 = self.map( Core, 0x24000 ) Mar 19 22:14:13 so reading/writing pruss.core0.control will directly read/write the CTRL register at offset 0x22000 within pruss Mar 19 22:14:18 Cool, that makes sense Mar 19 22:14:33 and .run() and friends are just friendlier accessors Mar 19 22:16:22 So does python allow you to write to a particular memory location easily? Mar 19 22:16:37 By that I mean, for self.core0 = self.map( Core, 0x22000 ) was map() a function you had to write. Mar 19 22:16:56 yes and yes Mar 19 22:17:00 I know with C it is easy just by using pointers Mar 19 22:17:19 ultimately the whole pruss is just an mmap object Mar 19 22:18:52 Ok, it's all making sense now (kind of) Mar 19 22:19:39 self.map( Core, 0x22000 ) is equivalent to Core.from_buffer( self.map(), 0x22000 ) where self.map() returns the memoryview for the whole pruss Mar 19 22:21:06 ok Mar 19 22:21:42 see also https://github.com/mvduin/py-uio/wiki/Memory-access Mar 19 22:22:56 Cool! Mar 19 22:24:55 reload, I just added a few things that were missing :) Mar 19 22:26:45 Nice! I'll give that a read. Mar 19 22:27:21 I'm trying to loop through 32 bytes in ASM. I think I need to load 32 into r0, then decrement it till it's 0 Mar 19 22:27:29 Is there a decrement operation? Mar 19 22:28:05 I guess I can just do SUB r0, r0, 1 Mar 19 22:28:10 that Mar 19 22:28:42 actually, you can also just use the loop instruction Mar 19 22:29:22 I don't see the loop instruction Mar 19 22:29:55 loop end_of_loop, 32 Mar 19 22:30:10 // loop body code here Mar 19 22:30:15 end_of_loop: Mar 19 22:31:19 Interesting, hardware assisted? Mar 19 22:31:22 yes Mar 19 22:31:25 I guess it has less overhead Mar 19 22:31:42 zero per-iteration overhead Mar 19 22:33:24 basically as long as the remaining loop count is nonzero, whenever the processor would normally go to the instruction labeled with end_of_loop, it will instead decrement the loop count and jump to the instruction just after the 'loop' instruction Mar 19 22:34:26 (it will even redirect an explicit jmp to end_of_loop) Mar 19 22:35:04 there is no loop stack, so you can't nest hardware-assisted loops Mar 19 22:41:15 so the loop instruction basically latches "end_of_loop" in some program counter comparator and loads a special-purpose register Mar 19 22:41:25 with the loop count Mar 19 22:41:59 yes, and it has to remember the start of loop (jump target) Mar 19 22:42:56 all three registers are completely internal though, no debug visibility unfortunately :-/ Mar 19 22:43:05 (same goes for the carry-flag) Mar 19 22:43:32 that gives some interesting hint about the architecture of the PRU ;) Mar 19 22:44:20 not really Mar 19 22:45:50 if that is zero overhead, the PRU has to be able to load the pc from the loop-start register and decrement and compare the loop counter in a single cycle Mar 19 22:47:36 most of that can be done in parallel to everything else pru has to do within a cycle... the bottleneck is comparing the candidate pc with the loop end and using that to select between the candidate pc and loop start as actual pc Mar 19 22:48:23 yes, you cannot have a latch, that would cost another cycle Mar 19 22:49:42 but anyway, I guess you would do stuff on a rising and other stuff on the falling edge of the clock Mar 19 22:50:07 so effectively dividing a cycle into two sub-cycles Mar 19 22:50:23 I can't speculate on that. I don't see any urgent need to do such a thing Mar 19 22:52:12 or even any benefit really? Mar 19 22:52:50 it just creates two deadlines that need to be met instead of one Mar 19 23:08:13 So in C I had a data array of 8 32 bit unsigned integers uint32_t data[8] = {0, 0, 0, 0, 0, 0, 0, 0}; Mar 19 23:08:37 With each new bit I left shifted data[0] = (data[0] << 1); Mar 19 23:08:51