**** BEGIN LOGGING AT Mon Jul 06 03:00:57 2020 **** BEGIN LOGGING AT Mon Jul 06 03:06:49 2020 **** BEGIN LOGGING AT Mon Jul 06 06:28:57 2020 **** BEGIN LOGGING AT Mon Jul 06 06:42:32 2020 **** BEGIN LOGGING AT Mon Jul 06 10:24:08 2020 Jul 06 11:15:28 hello, I am trying to use RPMsg on the beaglebone black, while writing the code on code composer studio i get the following error Jul 06 11:16:15 https://pastebin.com/V5hPimis Jul 06 11:16:55 I included all the header files necessary for pru_rpmsg and still get that problem Jul 06 11:19:38 amine7: sounds like you're missing the linker flags. Jul 06 11:23:55 I also added all the .lib files found in thye pru software support packages Jul 06 11:24:06 to the linker configuration Jul 06 11:26:16 i've never used CCS, so really can't tell for sure. its jsut how the error message looks like. Jul 06 11:29:14 okay thank you I ll keep looking and tweaking the code for the solution **** BEGIN LOGGING AT Mon Jul 06 11:49:32 2020 Jul 06 13:21:55 can you authenticate on two devices simultaneously? Jul 06 13:22:12 like in the room on my cell and computer Jul 06 14:42:08 hello i want to use the shift in and shift out capabilities of the PRU Jul 06 14:42:32 in pinmuxing what's the device that i'am supposed to declare Jul 06 14:42:35 for example Jul 06 14:42:42 if i want an output Jul 06 14:42:49 I use the command Jul 06 14:43:10 config-pin P9_27 pru_out Jul 06 14:43:24 but now i want to use the P8_45 with the mode 6 Jul 06 15:01:16 amine43: ? Jul 06 15:01:31 MattB0ne: authenticate what? Jul 06 15:02:16 amine43: shift in/out is configured in the pru subsystem config, the pinmux is still the same as for normal pru i/o Jul 06 15:02:39 hes back! Jul 06 15:02:42 i.e. config-pin P8_45 pru_in for mode 6 Jul 06 15:03:16 so i just have to configure them as gpio ? Jul 06 15:03:25 no, as pru_in / pru_out Jul 06 15:03:43 pruin / pruout I mean Jul 06 15:03:48 there's no underscore in the mode name Jul 06 15:04:27 ah okay thank you it worked Jul 06 15:08:04 wanted to be MattB0ne on my phone and lappy at the same time Jul 06 15:10:06 MattB0ne: well you can't have two irc connections with the same name at the same time... however there are ways to have one irc connection yet use it from two places, e.g. by running a terminal-based irc client in a screen session on one machine and ssh'ing in and attaching to that screen session from the other (that's what I do with irssi running on a personal server) Jul 06 15:10:14 or using an "irc bouncer", which acts kind of like a proxy Jul 06 15:10:28 to which you can connect with a regular irc client Jul 06 15:26:10 hmmm need to look intot hat Jul 06 15:26:27 anyways i have been staring at the py-uio Jul 06 15:26:46 and I am trying to puzzle out a way of getting the FIFO data from the uart from the PRU Jul 06 15:26:58 i think i need to do something with the cache_getter Jul 06 15:27:16 well there is some object in the cache_getter i need to reference Jul 06 15:27:40 I was looking at the TRM and I have an offset value too but I am not sure how that relates to what you have set up in py-uio Jul 06 15:28:52 so the TI manual says the UART offset is this 0x0002_8000 Jul 06 15:34:26 cached_getter is python stuff hence irrelevant for pru Jul 06 15:34:38 pru accessing the uart is just... pru accessing the uart, has nothing to do with python Jul 06 15:34:53 and there's a constant register for the pru uart base address Jul 06 15:35:13 c7 Jul 06 15:37:18 so for example lbco &x, c7, 0x0c, 1 (where x is some byte-register) will read LCR Jul 06 15:49:15 though honestly, since your code is fairly complex (dealing with uart, implementing a control algorithm, interacting with host) and doesn't require tight timing at all, it's probably more sensible to write it in C rather than assembly Jul 06 15:59:58 ok Jul 06 16:00:55 I will give it a shot. i Jul 06 16:01:38 when I read from that register it will give me anything that came in or do I need to request a size Jul 06 16:03:07 and am335x.cmd Jul 06 16:03:07 is like a header file that I should always include Jul 06 16:14:24 https://pastebin.com/EK0XbPh7 example C++ file Jul 06 16:14:51 you can just save it as "whatever.cc" in the fw-c directory and do "make" Jul 06 16:14:58 oh actually Jul 06 16:16:11 the pru_uart.h header should be obtained from eh... **** BEGIN LOGGING AT Mon Jul 06 16:18:57 2020 Jul 06 16:19:20 my example assumes the simple case where your entire loop is synchronized to the periodic transmissions from the load cell Jul 06 16:23:01 ok Jul 06 16:23:06 let me give this a go Jul 06 16:52:27 I think I would wind up at that implementation. the load cell will be limiting not the pru. Is a c compiled FW compatible with the debugger.py code? Jul 06 16:53:55 also do I need a resource_table_ empty file? most the examples online have more includes Jul 06 16:55:20 no Jul 06 16:55:54 debugger.py only supports .dbg files produced by pasm Jul 06 17:27:03 is there a easy way to output variables from a c compiled pru program. I suppose cout to the screen won't work lol Jul 06 17:32:22 morse code on a gpio connected to a led Jul 06 17:33:11 or if you're a viking, norse code Jul 06 17:33:36 funny Jul 06 17:34:36 i am not well versed in morse code Jul 06 17:34:40 so I will pass on that Jul 06 17:35:35 zmatt: say I want to write to shared memory no offset from the PRU. I think I know how to do that in C. Jul 06 17:35:59 If i wanted python to map to the same spot using py-uio how would I do that Jul 06 17:36:42 also do I have to worry about the PRU and py-uio both accessing the same spot in memory. The pru would be interacting with that spot more frequently than python but would I ever run into a problem Jul 06 18:13:37 MattB0ne_: I just pushed a complete overhaul of doing I/O via the UART from python... pruss.uart.io now yields an I/O object that implements the standard io.BufferedIOBase interface, so you can do pruss.uart.io.write(b'foo\r') and pruss.uart.io.readline(newline=b'\r') Jul 06 18:14:03 hopefully that works a bit better (for the purpose of setting up the load cell) Jul 06 18:15:32 cool I will take a lokk Jul 06 18:15:34 look Jul 06 18:16:55 MattB0ne_: and pru-examples/elf-test.py + pru-examples/fw-c/test.c show an example using shared memory Jul 06 18:17:45 ew, though I could fix that C example to not abuse "far" for that purpose Jul 06 18:18:04 *should Jul 06 18:20:14 yeah, bad example, let me fix that Jul 06 18:35:56 actually no it's not that weird Jul 06 18:36:02 I get now why I did that Jul 06 18:38:36 at least you do lol Jul 06 18:44:31 well "near" variables are those whose address fits in a 16-bit value (i.e. those below 0x10000) while "far" variables are those that don't (i.e. address >= 0x10000). pruss shared memory starts at 0x10000 hence any variable allocated there is necessarily far Jul 06 18:45:18 and since there's really no other far memory where the linker could reasonably allocate variables, it makes sense that I made the linked script place "far" variables into pruss shared memory Jul 06 18:48:04 though, I should probably change things so that shared mem isn't initialized by the ELF executable, hmm Jul 06 18:48:13 but wouldn't placement be determined by the offset you use so near or far is irrelevant? Jul 06 18:49:10 well the offset in this case is determined by the linker (though I'm relying on the fact that there's only one "far" variable in that example so I know where the linker will place it: at the start of shared memory) Jul 06 18:49:23 C has no way for specifying the absolute address of a variable Jul 06 18:49:32 that can only be done in the linker script Jul 06 18:54:36 I used #pragma LOCATION to lock a struct to a location the PRUs. Seems to be working. Jul 06 18:55:42 ah, interesting... though I'd use the __attribute__ version instead of #pragma Jul 06 18:55:59 I wonder if that's compatible with using the cregister attribute Jul 06 18:57:35 (shrug) Dunno. I did keep at as simple as possible. Jul 06 18:58:12 what is #pragma I have seen that in a few web examples Jul 06 18:58:15 warning: section ".TI.noinit" cannot be noinit in RAM model Jul 06 18:58:17 o.O Jul 06 18:58:23 wtf does that even mean Jul 06 18:58:30 lol If YOU don't know... Jul 06 18:58:35 #pragma is a compiler specific directive Jul 06 18:58:40 very nonportable Jul 06 18:58:55 Very. But I knew that and didn't need portable, so it worked for me. Jul 06 18:59:23 In this case it's also compiler specific for the PRU, which isn't liable to be ported. (grin) Jul 06 19:04:16 why the fuck do noinit sections not work in ram model, that makes no sense Jul 06 19:06:08 and the linker also happily ignores omitting the "I" (can be initialized) attribute on a memory region Jul 06 19:06:24 god I hate linker scripts Jul 06 19:06:28 and linkers in general Jul 06 19:09:18 and the example linker scripts use "PAGE 2:", which is completely undocumented Jul 06 19:09:22 \o/ Jul 06 19:09:53 fuck this, maybe I'll dig into it some other time **** BEGIN LOGGING AT Mon Jul 06 19:24:35 2020 Jul 06 19:25:28 okay maybe I actually do understand the error Jul 06 19:25:48 but first, food. Jul 06 19:26:30 Eat safe. Jul 06 19:36:39 okay, location does not combine with cregister, and location+noinit also doesn't work, so I'm starting to lean back towards "fuck this, maybe I'll dig into it some other time" :P Jul 06 20:12:06 lol Jul 06 20:12:38 I hope this has more to do with Ragnarok than what I am trying to do Jul 06 21:22:57 MattB0ne: it has nothing to do with Ragnorok, it's about declaring shared memory variables in C (preferably in a way that allows optimized access using a constant register) Jul 06 21:24:47 which is not too bad when the memory is to be initialized by the elf executable, but seems impossible when the shared memory should not be initialized (e.g. because it is already initialized by py-uio or the other PRU core) Jul 06 22:10:22 so when C is compiled is that when the spacing in memory is set. Like you said normally you cannot write to a specific address Jul 06 22:10:35 so is it that determined at compilation, linking or runtime Jul 06 22:10:45 i think reading your comments it is done by the linker Jul 06 22:10:52 so I could control placement there Jul 06 22:10:59 if I am understanding the conversation correctly. Jul 06 22:11:11 I didn't say you can't write to a specific address, you obviously can Jul 06 22:11:40 but, in plain C, you can't specify the location of a variable, though as Ragnorok pointed out there is in fact an attribute for doing so Jul 06 22:12:06 (specific to TI's compilers) Jul 06 22:12:46 I see so if I forgo variables then it will be more like assembler Jul 06 22:13:58 you can just access a specific address, which is the most straightforward way to access something external to your code (e.g. the counter variable written by the decoder running on the other PRU core) Jul 06 22:14:27 e.g. *(uint32_t volatile *)0x2000 Jul 06 22:14:59 now in this instance I would not have much else in there. But if I did I would have to add an offset and keep track of it Jul 06 22:15:08 for each item Jul 06 22:15:30 0x2000+5*uint32 or something like Jul 06 22:15:34 that Jul 06 22:15:44 for the 2nd item etc etc. Jul 06 22:16:00 you could either access each variable individually by absolute address, or define a struct for the whole collection of variables Jul 06 22:16:16 or you can index into ((uint32_t volatile *)0x2000) like an array Jul 06 22:16:42 the struct approach would be the most readable Jul 06 22:16:48 yes Jul 06 22:18:18 would it be better to flip all of the PRU firmware to C if I am going that way Jul 06 22:18:20 e.g. https://pastebin.com/UegEJ3aa Jul 06 22:18:24 no? Jul 06 22:18:45 the encoder code I have is pasm Jul 06 22:18:56 so is my eCAP Jul 06 22:19:21 the decoder is well-optimized assembly to be able to support high motor speeds Jul 06 22:19:32 eCAP would be controlled by your C code Jul 06 22:19:51 but there's zero benefit from changing the decoder to C Jul 06 22:19:51 ok Jul 06 22:19:55 ok Jul 06 22:46:00 TypeError: 'UartIO' object is not callable Jul 06 22:46:52 zmatt: I initialize the uart and then I need to use the UartIO? Jul 06 22:47:46 if you want to communicate with the uart from python (e.g. to perform initialization / start auto-transmission) you use the pruss.uart.io object yes Jul 06 22:50:08 which is designed to behave like normal python IO: it implements io.BufferedIOBase (https://docs.python.org/3/library/io.html#io.BufferedIOBase) and also has a readline method which allows you to specify the newline char, i.e. pruss.uart.io.readline( newline=b'\r' ) Jul 06 22:51:30 when you're done with it (i.e. before starting the PRU core that uses the UART) I recommend calling its .close() method Jul 06 22:51:39 ok Jul 06 22:59:00 very nice Jul 06 22:59:11 i can get rid of my loops and cruddy error catching Jul 06 22:59:18 now for the heavy lift the C Jul 07 01:52:27 Is the BBBW still a decent product? It's hard to find one (Sparkfun $90). I only found 1 company that makes a case for it but they are in the U.K. Deems the demand for these is drying up... Jul 07 01:57:04 hard to find? the site lists a whole bunch of distributors, and all of them have the BBBW in stock. arrow has 1175 in stock, element14 has 1067 in stock, digikey has 417 in stock, mouser has 1215 in stock Jul 07 01:58:06 the BBB is still used very much, and I'd assume ditto for the BBBW (which is essentially equivalent apart from having wifi/bt instead of ethernet), and there's not really anything that replaces them Jul 07 02:17:13 ""and there's not really anything that replaces them"" BBGW, BBGG, BBBE? Jul 07 02:23:20 BBGW is a piece of crap, BBE is somewhat interesting but it's more expensive and has some funkiness Jul 07 02:23:43 I got dropped Jul 07 02:23:54 sounds painful Jul 07 02:24:40 I timed out... Oh boy Jul 07 02:27:00 all of the greens have weirdness, the green-wireless did dumb stuff with its pins and isn't BBB-compatible as a result, the green destabilizes its clock and iirc has some weirdness with power, and I don't quite get the green-gateway, it seems to be like a BBBW without HDMI + usb-ethernet adapter Jul 07 02:31:05 I just hope the BBB WiFi works better then a BBB with a WiFi dongle.. The little C.H.I.P. WiFi works great. Hasen't failed yet. Jul 07 02:32:11 you're repeating yourself. and like I've said several times before, usb wifi sticks on linux are often a headache Jul 07 02:32:59 (and the fact that usb on the BBB is meh probably also won't help) Jul 07 02:33:06 I found out. Using a supported dongle didn't help Jul 07 02:33:15 "didn't help" ? Jul 07 02:34:08 and what dongle was it, and in which sense did you determine it to be "supported" ? Jul 07 02:34:20 I tried supported WiFi dongles. All kept going up/down. Jul 07 02:34:52 RTL8188EUS ? Jul 07 02:36:39 okay so something that needs an iffy out-of-tree driver? Jul 07 02:37:34 Well it loaded the driver automatically and kept going up/down Jul 07 02:38:18 So the BBBW is no issue and it stable? Jul 07 02:39:17 I use the BBB USB to flash the C.H.I.P. Jul 07 02:42:27 well I make almost no use of the BBBW, but wifi seems to work fine on it, and we also use the same chipset in a another device Jul 07 02:44:32 as for the unstable wifi dongle, could either be driver issues (did you check kernel log?), usb power stability (try inserting a powered usb hub between BBB and wifi stick to see if that fixes it), or just poor reception Jul 07 02:44:49 The company NTC that made the CHIP is OOB. Jul 07 02:45:01 or perhaps the crappiness of usb on the AM335x, although I don't think that should cause the link to drop Jul 07 02:45:04 yes I know Jul 07 02:45:27 it's also a terrible name for a product, almost impossible to search for Jul 07 02:45:51 They have kind of like this on Discorce Jul 07 02:46:30 ? Jul 07 02:47:04 https://discord.gg/AGTWQs Jul 07 02:47:55 invalid link, also I'm not interested in discard Jul 07 02:48:00 *discord Jul 07 02:48:51 ok **** BEGIN LOGGING AT Tue Jul 07 02:51:46 2020 Jul 07 02:52:08 Yea then click on the third icon on the left down NTC Lagecy. Users of CHIP meet there Jul 07 02:53:14 1. that's one of the discords _you_ are in, not something anyone else will see 2. I don't like discord 3. I don't care even a tiny bit about the CHIP Jul 07 02:53:16 What's wrong with Jul 07 02:53:22 discord? Jul 07 02:54:10 I'm just puzzled why are you trying to get me into some random communication medium about some random dead board Jul 07 02:54:38 I'm not Jul 07 02:54:46 okay, then what? Jul 07 02:55:08 forget discord **** ENDING LOGGING AT Tue Jul 07 02:59:58 2020