**** BEGIN LOGGING AT Tue Dec 17 02:59:58 2019 **** BEGIN LOGGING AT Tue Dec 17 07:51:24 2019 Dec 17 19:00:06 What is the advisable approach in debugging PRU assembly code? Preferably something simple (as gdb) that I can run from a console window on BBB Dec 17 19:01:56 prudebug seems to be the only option for that currently Dec 17 19:02:41 I think CCS can only be used for pru debugging via jtag, but I'm not 100% sure about that Dec 17 19:02:48 Back In The Day (tm) I used the shared memory space as a rolling log and had tool that dumped that. It wasn't ideal, but it got the job done. I don't recall prudebug exissting then, but that doesn't mean much. Dec 17 19:03:39 py-uio also allows inspecting and manipulating the code, and has an example that single-steps through a program while printing any changed registers after each instruction Dec 17 19:03:43 *the core Dec 17 19:05:05 prudebug is quite old, and hasn't been updated in many years Dec 17 19:05:57 like, it was originally written for the omap-L1xx SoCs, which were the first SoCs to have a PRU Subsystem (although it was substantially different) Dec 17 19:06:05 zmatt, is your suggestion to use prudebug, py-uio, or maybe to rely on some kind of logging? Dec 17 19:06:20 whatever suits the purpose Dec 17 19:06:53 what do you use? Dec 17 19:06:54 logging and invasive debugging suit different needs... invasive debugging tends to be incompatible with anything real-time Dec 17 19:08:00 of course. 'invasive' debugging is needed for correctness. Dec 17 19:08:21 not sure what you mean by that Dec 17 19:08:33 Actually, currently the correctness and learning pasm is the main purpse Dec 17 19:08:45 zmatt: I see it was available back then. Like said, havn't seen it doesn't mean much. (shrug) Dec 17 19:08:56 like, breakpoints and single-stepping can be quite convenient, but obviously obliterate any real-time properties Dec 17 19:09:07 yes Dec 17 19:09:22 so for debugging real-time code, logging may be the only option Dec 17 19:09:37 yes Dec 17 19:10:01 I was doing "real time". Logging even caused problems, but I got it going. Dec 17 19:10:14 I am talking about the single-stepping and setting some break-points to see if the code is correct Dec 17 19:12:18 dreamhiker: I'd suggest you just try prudebug to see if it fits your needs and maybe also try out py-uio's debugging.py example... the former is more a ready-to-go conventional debugger like you asked, while the latter is more just example code you can build on if you have more custom debugging needs Dec 17 19:13:08 Thanks! I will do it. Dec 17 19:13:24 (disclaimed: I've never tried prudebug so I don't know how well it works) Dec 17 19:13:27 *disclaimer Dec 17 19:15:30 lol It looks so nice I want to just run it and see... Dec 17 19:16:00 Thanks zmatt! Dec 17 19:16:19 Ragnorok: what does? Dec 17 19:16:29 prudebug Dec 17 19:16:31 ah Dec 17 19:16:38 so, go for it? Dec 17 19:17:33 I don't have a need, it just looks so nice. (shrug) Kinda joking anyway. Dec 17 19:19:10 ah, I do see one advantage of py-uio's debugging.py over prudebug: prudebug just disassembles pru iram, while py-uio understands .dbg output files as produced by pasm, hence it can show the original source line, which can matter a lot if you're using constants, macros, structs, etc Dec 17 19:35:32 also helps to not get confused by the different synonyms for the same instruction Dec 17 19:46:34 indeed Dec 17 20:38:56 I just got an Adafruit USB-to-TTL cable. Dec 17 20:39:18 It has 4 connectors, but everything online says to not use the red one because it delivers power. Dec 17 20:39:37 How can I connect it to my Beagle to power it on? Dec 17 20:43:22 The only barrel connector I've been able to find around my house is 9V. Dec 17 20:43:37 refusenick: that sounds like an awkward way to power it, but in principle you can connect ground to P9.01 and/or P9.02 and connect 5V to P9.05 and/or P9.06 Dec 17 20:46:18 zmatt: I don't know what that means. I have it plugged in like this: https://www.dummies.com/computers/beaglebone/how-to-connect-the-beaglebone-black-via-serial-over-usb/ Dec 17 20:49:54 the black wire is ground, the red wire is 5V Dec 17 20:50:33 https://insigntech.files.wordpress.com/2013/09/bbb_pinouts.jpg shows the P9 and P8 headers, and in particular where you can find P9.01/02 (DGND) and P9.05/06 (VDD_5V), which is where the black and red wires should go respectively Dec 17 20:52:03 note that I don't know if it can deliver enough power this way, it is not a recommended way to power the BBB Dec 17 20:54:17 the usb-serial cable you have specified up to 500 mA can be drawn, while the BBB can draw more. That's also why two expansion header pins are supposed to be used for GND and 5V each: a single expansion header pin technically has insufficient current rating in situations where the BBB draws max power (although it's typically not a problem) Dec 17 20:57:40 I founda 7.5v barrel connector. Is that safe to use? Dec 17 20:57:47 no Dec 17 20:58:22 what is the tolerance? 5v +/- 10% ? Dec 17 20:59:27 probably 5V ± 5% Dec 17 21:02:37 I connected the default USB cable for power and attached the USB-to-TTL cable to the J1 pins as in the link I posted. Dec 17 21:03:05 Should it be accessible via /dev/ttyUSB0? Dec 17 21:04:37 on your computer? dunno, might depend on what chip is in that thing exactly. but it's probably /dev/ttyUSB or /dev/ttyACM ... you could check your kernel log to see what device showed up when you plugged it Dec 17 21:05:43 (keep in mind that some computers will also have internal usb-serial devices, for example my laptop has a /dev/ttyACM0 that's internal) Dec 17 21:06:15 running "dmesg", it logs something new on /dev/ttyACM0 towards the end of the output. Dec 17 21:06:35 well there ya go Dec 17 21:07:45 Well, it works! Dec 17 21:07:47 Thanks! **** ENDING LOGGING AT Wed Dec 18 03:00:35 2019