**** BEGIN LOGGING AT Fri Sep 25 02:59:57 2020 Sep 25 03:10:42 zmatt: my program wont fit in memory Sep 25 03:10:49 =( Sep 25 12:25:21 what on earth did he do Sep 25 12:25:36 who? Sep 25 12:28:12 05:10 < MattBoone> zmatt: my program wont fit in memory Sep 25 12:28:20 (PRU program in C) Sep 25 12:28:34 well, he used C Sep 25 12:28:39 and probably wrote too much of it Sep 25 12:28:58 I'm pretty sure he barely started Sep 25 12:29:10 maybe he made a huge array Sep 25 12:29:20 or made all functions inline Sep 25 12:30:05 at least I haven't seen anyone trying to compile qt for the pru yet Sep 25 12:30:18 I did notice that clpru seems to have no intelligence in inlining... trivial tiny static functions won't get inlined without "inline", I'm guessing the converse is true as well Sep 25 12:32:05 why is the compiler saying my program won't fit Sep 25 12:32:15 MattB0ne: because you did something stupid? Sep 25 12:32:21 lol Sep 25 12:32:24 probably because it's bigger than available ram Sep 25 12:32:27 that's the most logical explanation Sep 25 12:32:52 let me post it Sep 25 12:38:15 I put a LOT of code in a PRU using C. It's not much of a restricion in my book. Sep 25 12:38:38 yeah I have trouble imagining how you'd fill it up Sep 25 12:38:53 char foo[1<<20]; Sep 25 12:39:09 without doing something obviously terrible Sep 25 12:39:28 like including too much code/data Sep 25 12:39:39 is it tautology day already? Sep 25 12:39:54 Data most likely. C compiles down pretty small. Sep 25 12:40:53 reminds me of one time at work when we ran out of space Sep 25 12:41:08 obviously we went looking for things to trim back Sep 25 12:41:25 So they reformatted the intern with a smaller inter-track gap. Sep 25 12:41:28 someone found an unused 2MB array in code managed by another team Sep 25 12:41:42 lol Sep 25 12:42:00 their explanation: "yeah, we added that a few years ago in case we'd need the space later" Sep 25 12:42:09 Sep 25 12:42:14 ... Sep 25 12:42:40 sounds like those people should not be writing code for pru Sep 25 12:42:53 that wasn't pru, obviously Sep 25 12:42:57 ah Sep 25 12:43:15 2MB. I bet not. Sep 25 12:43:18 well, writing code in general possibly. Sep 25 12:43:27 There you go. Sep 25 12:43:29 it was some satellite box with 16MB ram Sep 25 12:43:49 https://pastebin.com/BLjULHcy Sep 25 12:43:58 is the compiler yelling at me Sep 25 12:44:44 https://pastebin.com/vKnxfXbz Sep 25 12:44:49 is my program Sep 25 12:45:11 don't use sscanf Sep 25 12:45:25 That was my gut reaction but I wasn't sure. Sep 25 12:45:29 +1 Sep 25 12:46:24 also wtf is *(&msg + 1) - msg; Sep 25 12:47:07 why are you copying the message to a second buffer, and in such a bizarre way? Sep 25 12:47:23 you've also got a buffer overflow Sep 25 12:48:13 and what's with the crazy indentation? Sep 25 12:48:23 And indentation is inconsistent. (wink) Sep 25 12:48:31 Too slow! Sep 25 12:54:14 MattBoone you might want to use simpPRU if it's a simple use case Sep 25 12:54:46 MattB0ne: https://pastebin.com/7VhZFKTp (untested) Sep 25 12:54:56 https://github.com/VedantParanjape/simppru Sep 25 12:56:29 vedant16[m]: I don't see how using a weird custom language is helpful... it will create even more distance between the programmer and what pru is actually doing Sep 25 12:57:24 zmatt For beginners its easier. Rather than going through PRU voodo Sep 25 12:57:39 I also don't see how it is simpler than C, it seems basically C but with some gratuitous changes to make it syntactically unlike anything Sep 25 12:57:48 In the end it compiles down to C, so I am not adding any distance as such Sep 25 12:58:28 umm, maybe take a look at the example? Sep 25 12:58:48 like, I'm reading through the language reference now... how is this simpler than C ? it seems to be literally a subset of C with weird syntax Sep 25 12:59:16 It's not a subset of C, syntax is more like python Sep 25 12:59:23 it's not remotely like python Sep 25 12:59:28 even a tiny bit Sep 25 12:59:31 I use sscan to go from string to int Sep 25 12:59:38 MattB0ne: yes, don't. Sep 25 12:59:43 yawn... Sep 25 12:59:44 MattB0ne: https://pastebin.com/7VhZFKTp Sep 25 13:00:03 vedant16[m]: in what way does is resemble python in your mind? Sep 25 13:00:19 zmatt's example should work nicely. I'd use strtoul, but I'm lazy. Sep 25 13:00:25 syntax wise, a bit similar Sep 25 13:00:28 so basically you cannot use helper functions I. oru code? Sep 25 13:00:42 MattB0ne: you can, like Ragnorok said strtoul should be fine Sep 25 13:00:43 You can but ssanf is *fat*. You don't have the RAM for it. Sep 25 13:00:44 in pry code* Sep 25 13:00:53 MattB0ne: just not sscanf or sprintf Sep 25 13:00:58 ok Sep 25 13:01:34 MattB0ne: but in this case parsing manually is not significantly more complicated than strtoul, especially with error-checking added Sep 25 13:01:44 zmatt Not even close to C, doesn't even have main function. Sep 25 13:02:00 ok Sep 25 13:02:41 strtoul also requires you to add a nul-terminator Sep 25 13:02:43 is there a header file that has all the address to the rest of the beagle bone like pru_uart.h Sep 25 13:02:50 so the total amount of code would actually be bigger Sep 25 13:03:03 no Sep 25 13:03:40 so if I want to hit the ecap and ehrpwm I would need to manually put the write address in myself =[ Sep 25 13:03:46 ok Sep 25 13:04:54 like, here's the version with strtoul: https://pastebin.com/eQyP8wF8 Sep 25 13:05:41 I had written one for ecap. this might be useful: https://github.com/VedantParanjape/pru-ecap-pwm/blob/master/include/am335x/pru_ecap.h Sep 25 13:07:41 you can find that header in /usr/lib/ti/pru-software-support-package/include/am335x/ Sep 25 13:07:48 on the beaglebone already Sep 25 13:07:57 same for the other pru peripherals Sep 25 13:08:32 oh, and it seems a few system periphreals: mailbox, mcspi, pwmss (ecap, eqep, ehrpwm), and the adc Sep 25 13:09:20 It doesn't have bitfields. Sep 25 13:09:31 * zmatt doesn't have bitfields. Sep 25 13:10:42 it's a bad idea to use bitfields in volatile variables Sep 25 13:11:11 every bitfield write will generate a separate load-modify-store sequence Sep 25 13:12:23 I needed those, as TRM described register values to use ecap to generate pwm. Sep 25 13:12:44 But it wouldn't work, I guess I will try with this suggestion Sep 25 13:12:53 ?? Sep 25 13:13:13 I'm describing the code the C compiler generates when you're doing this Sep 25 13:16:43 especially do NOT use a bitfield for ECCLR, that will break your code Sep 25 13:19:37 actually I'm not sure what it does since it's a write-only register Sep 25 13:19:53 (yet writing a bitfield of it will cause a read-modify-write) Sep 25 13:20:25 many peripherals (but not ecap) combine it with the interrupt status register, in which case writing a bitfield will as a side-effect clear all other interrupts Sep 25 13:27:24 vedant16[m]: and here's one of your code examples (from the language ref) together the equivalent in C and in python (with type annotations): https://pastebin.com/p4Ei1USh Sep 25 13:27:51 vedant16[m]: the only thing in your language that is pythonesque is the word "def", literally no other part of the syntax resembles python Sep 25 13:28:52 zmatt: how did you find a buffer overflow in my code without even running it? Sep 25 13:29:19 MattBoone: because you're copying 24 bytes from offset 2 of a 24-byte buffer Sep 25 13:29:26 He ran it in his *mind*. Sep 25 13:29:58 (even though there was no reason to copy bytes to a second buffer even if you did use sscanf) Sep 25 13:30:00 Ragnorok: lol would not surprise me if he had linux partition in is brain =) Sep 25 13:30:22 I see Sep 25 13:30:29 or, said differently: the overflow is just *that* obvious Sep 25 13:30:35 lol Sep 25 13:30:59 the only part that makes it harder to see is the bizarre expression length = *(&msg + 1) - msg; Sep 25 13:31:07 which is just length = sizeof msg; Sep 25 13:31:20 I wanted to get the length of the string i found that on stackoverflow Sep 25 13:31:27 well, sizeof msg / sizeof(*msg); but msg is a char-array here Sep 25 13:31:50 Kinda what I was thinking. We know the length up front. Sep 25 13:31:53 MattBoone: and you failed the notice the "len" being returned by it Sep 25 13:31:59 u8 len = uart_recv_line(msg, sizeof msg ); Sep 25 13:32:06 there's your actual string length Sep 25 13:32:16 your 'length' is the size of the buffer Sep 25 13:32:35 doh Sep 25 13:32:38 your right Sep 25 13:32:47 oh an another bug in your code is that sscanf requires 0-termination which is not provided here Sep 25 13:33:09 (see my example that used strtoul) Sep 25 13:33:33 But we aren't using sscanf any more, so that's not *really* a bug. (wink) Sep 25 13:33:48 strtoul has the same requirement Sep 25 13:33:58 or any other function that expects a C-string Sep 25 13:37:34 is *end special ? Sep 25 13:37:58 vedant16[m]: also, in both C and python, using a bitwise operator like & or | on a boolean operand yields an integer result, not a boolean Sep 25 13:38:12 mastermind_: ? Sep 25 13:38:31 char *end; Sep 25 13:38:45 does end initialize to 0 Sep 25 13:38:55 that declares a variable named 'end' of type char * Sep 25 13:38:59 it does not initialize it Sep 25 13:39:07 strtoul initializes it Sep 25 13:39:44 oh Sep 25 13:41:07 last questino before i rest my brain Sep 25 13:41:10 const char *str, char **endptr Sep 25 13:41:19 ohk agreed. Sep 25 13:41:31 if you have trouble understanding how to use strtoul, just parse manually ( https://pastebin.com/7VhZFKTp ) since that entirely avoids pointers Sep 25 13:41:31 TRM tells to set the specific bitfields, so I should concat them into a single 32 bit value? Sep 25 13:41:40 yeah I am Sep 25 13:41:50 just trying to learn a bit since I see that a lot Sep 25 13:41:51 const char *str, char **endptr Sep 25 13:41:54 the ** Sep 25 13:42:00 vs * Sep 25 13:42:02 means pointer to pointer Sep 25 13:42:18 in general C declarations read from right-to-left and inside-out Sep 25 13:42:36 "char **endptr" reads as "endptr is pointer to pointer to char" Sep 25 13:42:46 why would you want to do that if you already have a pointer Sep 25 13:43:16 strtoul needs a pointer to your char *end variable since it writes a result there Sep 25 13:43:30 (namely where it stopped parsing) Sep 25 13:43:50 zmatt it is my gsoc project, it's purpose was to make pru programming simple for beginners, I forgot to mention that it isn't useful for advanced use cases. Sep 25 13:44:01 It takes care of loading firmware, setting pin mux and start/stop pru as well as reading writing to rproc. Sep 25 13:44:21 one more really last question Sep 25 13:44:43 MattB000ne: basically a pointer argument can be used as a way to return a value: https://pastebin.com/0Tw90NyS Sep 25 13:45:02 MattB000ne: strtoul already has a return value, so they use a pointer argument as second "return value" Sep 25 13:45:42 ok that makes sense a way of sneaking around the return value limitation Sep 25 13:45:58 one last question for you and I will stop and let my brain recover Sep 25 13:46:11 the uart code it will wait for the EM100 to put a value in right Sep 25 13:46:27 or should I put an internal loop that reads until i get a non blank result? Sep 25 13:47:13 right now I am assuming it will sit and wait for the next value Sep 25 13:47:31 before going to the next line of code Sep 25 13:48:00 MattB000ne: do you have anything else to do? Sep 25 13:48:28 no i hope it waits Sep 25 13:48:38 as written it will wait for the next measurement yes Sep 25 13:48:42 perfect Sep 25 13:48:55 so that basically becomes the timing of your entire control loop Sep 25 13:49:04 that is what I need Sep 25 13:49:20 that's what I understood, which is why I wrote it like that Sep 25 13:49:34 you are good but you probably already know that lol Sep 25 13:50:55 vedant16[m]: my py-uio library ( https://github.com/mvduin/py-uio ) is also designed to make pru easier to work with by allowing python code to work with pru, though not just load and run programs (both pasm and clpru executables) but also map shared memory, receive interrupts, and directly inspect/debug the core Sep 25 13:51:59 vedant16[m]: as for avoiding bitfields, I think you need to work on your understanding of how integers are represented as bits and how bitwise shifts and bitwise operators work Sep 25 13:52:32 e.g. you can set bit 5 of something with variable |= 1 << 5; Sep 25 13:53:11 mine uses remoteproc, uio is not shipped with new kernels, right? Sep 25 13:53:22 uio is shipped with new kernels Sep 25 13:53:42 you select between remoteproc and uio via a variable in /boot/uEnv.txt Sep 25 13:53:51 right Sep 25 13:54:10 remoteproc is very limited and not a suitable replacement for uio Sep 25 13:54:30 I know how it works. Sep 25 13:54:45 well the confused questions you were asking suggest otherwise Sep 25 13:55:25 but remoteproc is a standard linux way to handle co processor Sep 25 13:55:30 * but remoteproc is a standard linux way to handle co processors Sep 25 13:57:13 uio is the standard linux way of mapping devices into userspace to allow direct interaction between a userspace program and a device (e.g. when it has no sensible driver or the needs of userspace exceed the driver's capabilities) Sep 25 13:57:42 I understand the motivation and design of remoteproc Sep 25 13:58:26 it just doesn't work well for this use case, where pru is a development target of the user rather than some black box onto which you load firmware and that's it Sep 25 13:58:42 ohkk, I had read a old heated thread rproc vs uio. Sep 25 13:59:06 and I understand non-embedded linux people would be horrified by uio Sep 25 13:59:07 but since we can mmap pru memory, why do we need the extra functionality Sep 25 13:59:13 * but since we can mmap pru memory, why do we need the extra functionality? Sep 25 13:59:22 does remoteproc allow mmapping pru memory? Sep 25 13:59:36 I am a UG student, and yes I am horrified Sep 25 13:59:49 no but I can do it externally, right Sep 25 14:00:04 how? via /dev/mem? that's way, way worse than using uio Sep 25 14:00:15 yes Sep 25 14:00:21 that's awful, please never do that Sep 25 14:01:00 that requires root privileges and doesn't allow the kernel to ensure the device is actually accessible (resulting in a bus error if pru is halted by the remoteproc driver) Sep 25 14:01:28 I don't, I used devmem2 Sep 25 14:01:35 * I didn't, I used devmem2 Sep 25 14:01:43 that's a tool that uses /dev/mem Sep 25 14:01:45 I think, it uses /dev/mem Sep 25 14:03:02 on current beagleboard.org images there are actually separate uio devices for mapping pru shared memory for remoteproc users... the irony of that should be obvious :P Sep 25 14:03:10 it just shows that remoteproc is too limited Sep 25 14:03:34 it doesn't do what people need Sep 25 14:03:49 Agreed Sep 25 14:03:58 and if you're gonna use remoteproc+uio (or worse, remoteproc+/dev/mem) then you may as well just use uio Sep 25 14:04:21 using sysfs to control pru seems very neat. Sep 25 14:05:11 but also extremely limited, and it's not significantly more convenient than using a library that provides the same functionality Sep 25 14:05:51 Right, I think for basic uses cases remoteproc would be enough, atleast for me Sep 25 14:07:19 I think you went through simpPRU, if you do have any feedback/suggestion please let me know Sep 25 14:07:27 * I think you went through simpPRU docs, if you do have any feedback/suggestion please let me know Sep 25 14:07:58 my feedback is that the language is pointless: anything simple enough to be written in it is just as simple in plain C Sep 25 14:08:49 I disagree, I didnot know a thing about PRU 4 months back, and It took me a lot of time to get started. Sep 25 14:08:50 there's no benefit or purpose to its syntax changes relative to C Sep 25 14:08:58 It shouldn't be that hard. Sep 25 14:09:14 like, if you want to make C simpler, look at what Arduino does Sep 25 14:09:20 which is at least still compatible with C Sep 25 14:09:34 don't make random syntax changes Sep 25 14:09:45 that's just bad from an educational perspective Sep 25 14:09:57 Ok.. Sep 25 14:11:20 and it also seems a bit misplaced to do a project like this without first having a deep enough understanding of programming in general and pru programming in particular Sep 25 14:12:06 anyway, I gotto go, afk Sep 25 14:12:34 Well, this was project by beagleboard in gsoc, and it felt good, so did it. Sep 25 14:56:38 hi yall, Can mcasp axr[0..3] be configure arbitrarily for input/ouptput of data? as in i wish to do a channel in on 0 and an out channel on axr1. Doable? Sep 25 14:57:16 direction can be independently configured for each data pin Sep 25 15:06:29 Could anyone confirm if the BBB Wireless board supports Industrial temperature range? Sep 25 15:10:25 define industrial temperature range Sep 25 15:11:18 zmatt: does the PRU already have the source code for CT_UART.THR and so it only needs the header? Sep 25 15:12:37 all I needed to compile is that header file but I do not have the code for CT_UART.THR directly Sep 25 15:14:44 zmatt: nevermind Sep 25 15:14:52 looked at the file more closely Sep 25 15:15:40 MattB00ne: there is no "source code", the header describes the registers of the pru uart as a C structure Sep 25 15:23:47 Woot., thank you ! Sep 25 15:25:52 douglas36, you could make a python script that parses each entry of the bom to check its min max and max min ranges for each component. Heres a good start: Sep 25 15:25:55 https://github.com/gunslinger/Python-Electronic-Component-Scraper.git Sep 25 15:36:39 why does the TRM say this Sep 25 15:36:41 For clarity and ease of use, below are useful #defines which will help in the Sep 25 15:37:17 why are defines easier ? Sep 25 15:49:39 Temp range of -40 to +85C, however, low end temp may be ok at -30C Sep 25 15:53:21 Thanks, Konsgnx. I'll check it out. I'd like to find a manufacturer of the BBB Wireless board that may have extended temp range or simply a manufacturer of that normal temp range board to start with. Sep 25 15:55:03 call up seeed Sep 25 15:55:05 ... I think there is only 1 manufacturer, and I doubt they have different options of temp chips picked out. too much to account for. you can certainly make your own though from the files they provide Sep 25 15:55:34 is it seeed or octavo that made that design? Sep 25 15:55:40 bbb wireless is not seeed Sep 25 15:56:00 octavo? why would octavo be involved? Sep 25 15:56:02 bb green wireless is seeed Sep 25 15:56:13 as advertisement for their chip? Sep 25 15:56:24 would make sense. Sep 25 15:57:05 looking at both designs right now actually.. comparing wireless connections. Sep 25 15:57:19 the green actually does connect the bluetooth audio... Sep 25 15:57:22 wireless connections are totally different between bbbw and bbgw Sep 25 15:57:24 Octavo is the SIP (processor) Sep 25 15:57:42 besides pins, its actually not much differences Sep 25 15:57:52 the bluetooth audio connection is not really useful Sep 25 15:58:09 douglas36, yup, and it's used in the bbb wireless design Sep 25 15:58:41 yea, but for my breakout i have some pins available so im adding it, for the lols Sep 25 15:59:07 Any feedback about the BBB Enhanced board from SanCloud? Sep 25 15:59:19 Konsgnx: the wl18xx only supports the basic low-quality codecs, so for high quality audio you'd need software decoding anyway Sep 25 15:59:34 I don't need audio Sep 25 15:59:42 douglas36: I was replying to Konsgnx, not you Sep 25 15:59:57 that's why I prefixed my line with "Konsgnx: " Sep 25 16:00:43 hmm, doesn't it do aptx.... Sep 25 16:01:16 merrrr Sep 25 16:01:20 Konsgnx: SBC Sep 25 16:01:20 lame a2dp Sep 25 16:01:25 if the ecap is a 32bit counter with units of ns how can I use it as a absolute time stamp Sep 25 16:01:41 MattB0000ne: units of 5ns Sep 25 16:01:50 MattB0000ne: define "absolute time stamp" Sep 25 16:02:31 I want a time elasped timer running, like a stop watch. Sounds like that is not a job for the ecap Sep 25 16:02:34 i don't think thas enough resolution in 5ns increments from start of big bang Sep 25 16:02:47 a counter *is* an absolute timestamp until it wraps. if you need absolute timestamps with a larger range than 2^32*5ns then there are easy ways to extend the range of the timestamp Sep 25 16:02:49 but I also need the PRU to follow a function of time Sep 25 16:02:52 Konsgnx: no Sep 25 16:03:08 it's 21 seconds Sep 25 16:03:28 I just reset and increment another variable in like seconds? Sep 25 16:03:46 zmatt, close enough Sep 25 16:04:04 lol Sep 25 16:04:57 if you need to measure timespans longer than 21 seconds then there are a variety of solutions Sep 25 16:07:22 for example https://pastebin.com/CLEQigMP Sep 25 16:15:11 actually don't declare that function as static Sep 25 16:15:46 ok Sep 25 16:18:16 the code generated by clpru is, unsurprisingly, terrible Sep 25 16:20:05 lol Sep 25 16:20:55 as soon as I issue pruss.ecap.config = 1 << 15 | 1 << 20 in python the ecap will run right Sep 25 16:21:07 in capture i see bit 20 is enable Sep 25 16:21:15 capture mode* Sep 25 16:21:40 for my purposes and the way you wrote time stamp it can be runnning Sep 25 16:21:54 bit 20 enables the counter Sep 25 16:22:10 i.e. the counter is running if and only if bit 20 is set Sep 25 16:22:14 ok Sep 25 16:22:29 how would you do that in C i am looking at the header Sep 25 16:22:40 I do not see that control register Sep 25 16:22:53 just curious Sep 25 16:23:21 unless i need to look at the pwmsss header Sep 25 16:23:22 maybe? Sep 25 16:23:50 they inconveniently declare it at two 16-bit registers (ECCTL1 and ECCTL2) instead of one 32-bit register Sep 25 16:24:06 so it's bit 4 of ECCTL2 Sep 25 16:24:34 ok Sep 25 16:24:38 thanks Sep 25 16:24:52 CT_ECAP.ECCTL1 = 1 << 15; CT_ECAP.ECCTL2 = 1 << 4; Sep 25 16:25:16 like the TRM says, you may want to define named constants for those instead of using magic numbers, to increase readability Sep 25 16:25:23 or at least add a comment Sep 25 16:28:04 for example this is a style I often use when writing a register with a bunch of bitfields: Sep 25 16:28:07 https://pastebin.com/GnXyeFbp Sep 25 16:53:37 I like that Sep 25 18:47:07 what would be the easiest way to hook up an array of buttons to the beaglebone? charlieplexing? Sep 25 18:47:17 or is there some great serial chip? Sep 25 18:48:40 with regards to charlieplexing, is there a driver that triggers on interrupt of a button being pressed down, then goes into a polling state to see which are pressed until all are released? Sep 25 18:51:00 TIL: charlieplexing implied led's Sep 25 19:06:22 Has anyone used a power cape with a Beaglebone AI? It only boots 50% of the time. Does AI need too much current? Sep 25 19:40:58 Konsgnx: you could in principle use charlieplexing for other purposes, e.g. replacing the leds by opto-couplers Sep 25 19:41:48 but you need something that blocks reverse voltage, has a minimum forward voltage, and doesn't use more current than a gpio can handle Sep 25 19:45:16 why diodes? for a basic array of size NxM wouldn't enabling /disabling pullups be enough to scan each row? Sep 25 19:45:40 ah, buttons, didn't read up far enough Sep 25 19:45:46 yup yup Sep 25 19:46:16 diodes would allow you to do a NxMx2 with alternation of pullup/pulldown tests Sep 25 19:47:08 you also need to consider whether you need to support multiple keys being pressed at the same time Sep 25 19:47:44 and whether you really want software to do that keyboard scanning instead of just getting an i2c keyboard scanner Sep 25 19:51:14 yea, i2c is how i plan to go, but regarding the multiple keys, i dont think the ghosting can happen... Sep 25 19:51:49 if you scan by applying a pullup to one row at a time, what combination would cause an issue? Sep 25 19:52:23 I say that hesitatingly, i remember coming to the opposite conclusion, but i don't see it now. Sep 25 19:54:11 ahhh, yea i see it now. Sep 25 19:54:34 you can short together 2 rows and 2 columns with only 3 keys Sep 25 19:54:47 scan twice alternating pull-up and pull-down tests, then take the xor of the 2 scans, you won't have ghosting. Sep 25 19:55:07 nothing short of a diode per key will avoid this Sep 25 19:56:36 the problem can only occur once 3 keys are pressed so it's not relevant in all applications, it's mainly a concern when modifier keys are involved Sep 25 19:56:51 yea, was thinking 2 pressed, not 3 Sep 25 19:57:03 true true. Sep 25 19:58:19 or when typing really fast, or in applications like gaming Sep 25 20:03:22 some keyboards support >2 keys pressed only for keys expected to be modifiers Sep 25 20:03:34 yep Sep 25 20:03:47 and when you remap capslock to control, say, things break Sep 25 20:03:52 very annoying Sep 25 20:04:07 hah, hadn't thought about that, makes sense that capslock isn't designed to be used as a modifier Sep 25 20:04:32 good keyboards support any combination Sep 25 20:05:24 and then you can get this from emacs: A-C-H-M-S-a is undefined Sep 25 20:05:34 it's got a little lite, just have it detect the keycombo and auto-turn it off, now you can toggle the modifier Sep 25 20:05:59 iirc, there's up to 7 modifiers.. Sep 25 20:06:34 there's also super, but I don't have that mapped Sep 25 20:06:47 capslock and numlock also count as modifiers Sep 25 20:06:51 but they're toggles Sep 25 20:07:46 oh, and Mode_switch aka AltGr Sep 25 20:08:31 traditional X11 supports shift, capslock, control, and 5 other modifiers Sep 25 21:53:14 how can you find out the start address of the peripherals? Sep 25 22:00:05 TRM Sep 25 22:02:15 I've also got spreadsheet covering the am335x ("subarctic") and some closely related TI SoCs: https://goo.gl/UHF2Fy Sep 25 22:03:54 oh I see, 2. Memory Map Sep 25 22:04:33 thanks Sep 26 00:07:01 zmatt: if I want to map an entire struct in python how do I do that Sep 26 00:11:33 MattB000ne: declare the struct using ctypes.Structure and map it as usual. examples of declaring a struct can be found in several examples: stream.py, intc-test.py, and intc-test-asyncio.py Sep 26 00:12:22 intc-test.py is simpler to read Sep 26 00:50:57 also for the clpru the file I load is the out file Sep 26 00:51:18 the pru make gave me a dbg and bin Sep 26 00:51:23 i guess it doesnt matter? Sep 26 01:30:09 I keep getting the same number back from shared memory Sep 26 01:32:30 hello Sep 26 01:33:09 hi Sep 26 01:35:38 am I missing something with the mapping Sep 26 01:35:39 https://pastebin.com/RGHUrKfy Sep 26 01:39:12 pastebin Sep 26 01:55:12 renrelkha: I just saw the video of the bbblue flying! Sep 26 01:55:30 :) Sep 26 01:55:34 it does fly Sep 26 01:55:39 finally Sep 26 01:55:42 nice Sep 26 01:55:43 It caught me by surprise. The video must have had to download first. Sep 26 01:55:44 Nice. Sep 26 01:56:10 I found someone to fix the bbblue. $65.00! Sep 26 01:56:14 Trippin' Sep 26 01:56:24 I am going to get a new one. Sep 26 01:56:45 as soon as I save up...bbblue time! Sep 26 01:56:49 now i am researching the intel sr300 modules inside the now defunct amazon echo look Sep 26 01:57:02 Oh. For? Sep 26 01:57:25 For flying? Sep 26 01:57:30 experiment with cv Sep 26 01:57:42 Oh. I thought for speech recognition. Sep 26 01:57:45 maybe see if it can do like ground mapping or something Sep 26 01:57:51 Oh. Okay. Sep 26 01:58:01 If it has a lidar in it, yes. Sep 26 01:58:02 oh sorry its a 3d depth sensor Sep 26 01:58:06 Oh. Sep 26 01:58:13