**** BEGIN LOGGING AT Fri Feb 16 03:00:02 2018 Feb 16 03:00:36 I just read a book partially, "BeagleBone Black Cookbook." It is from Packtpub from 2015. Feb 16 03:02:31 Sheets be interesting, man, but I would bet people would like to have more info. about random stuff packed together on the BBB.io ideas. Feb 16 03:02:46 Secrets! Feb 16 03:02:59 Do a tell all! Am I right? Feb 16 03:04:52 For instace...bullet points on stuff is still okay. Ideas, ideas, ideas. I just went over this Johnny Five stuff online. Feb 16 03:04:53 ... Feb 16 03:05:17 Why can we not have more and not less? Feb 16 03:05:24 info! Feb 16 03:05:28 <<<<<<<< calming down Feb 16 03:12:44 perhaps looking outside the town box? Feb 16 03:13:46 I had to move because the area I was in was barely making it. Mostly because of NYC destroys the rest of the state. That State is financially bankrupt because of the greed exhibited by NYC for the last 150 years. Feb 16 03:14:34 Oh. Feb 16 03:14:47 I tried. I made it at times and made it barely. Feb 16 03:15:08 I came back home to Louisiana to settle/crap in place. Feb 16 03:15:47 Hey GenTooMan: Is Pioneer still in electronics? Feb 16 03:16:03 ...from general knowledge? Feb 16 03:16:50 ...I ask b/c the damn people sell different names at the store now. Feb 16 03:16:56 off subject. Sorry. Feb 16 03:17:55 set_: they still make stuff if that's what you are asking but it's hard to know. you could make your own beagle music player or beagle X terminal or whatever. It's flexible (if not confusing at times). Integrating things with the beagle board / bone stuff is a bit of a challenge I've found. Feb 16 03:18:29 set_: http://www.pioneerelectronics.com/PUSA/ Feb 16 03:18:39 Yea... Feb 16 03:18:51 I figured those people were still in PUSA! Feb 16 03:19:16 I just found this site that shows the boot sequence before Linux takes over. Feb 16 03:19:36 https://elinux.org/EBC_Exercise_21a_Boot_Sequence Feb 16 03:19:38 Cool! Feb 16 03:20:02 set_: uboot iboot we all boot for uboot! Feb 16 03:20:04 I even think I have a FTDI cable. Feb 16 03:20:10 Boy! Feb 16 03:21:08 "What happens to the bootloaders, stays in the Bootloader!" Feb 16 03:22:00 ... Feb 16 03:22:25 set_: pioneer is Nipponese however. Not much left in the US in terms of audio companies. All have been sold and bought by a few companies. Welcome to Lost wages you will lose here big time. So back to beagle. Lots that can be done. I'm working with the KiCAD OSD335w package thing so hence It hought you might find it fun too look at. Feb 16 03:23:23 GenTooMan: I would set up a bunch of easily accessible links but my "inline," ordered ideas or a bit foggy. Feb 16 03:23:25 Oh. Feb 16 03:23:38 kiCAD...I do not have it. Feb 16 03:24:02 I was going to go w/ first things first and then work my way to a point. Feb 16 03:25:55 https://pastebin.com/pkSAJAG7 Feb 16 03:26:19 set_: don't worry it's not like you are going to be suddenly doing insane things overnight, it takes a bit to be that crazy. I mean to do cool things with a beagle board. I have 2 originals 3 beagle bones 2 panda boards hmmm. Anyhow I need sleep. Feb 16 03:26:35 No! Feb 16 03:26:58 I'm at least an hour later than you set_ Feb 16 03:27:02 GenTooMan: Let me know of a good book to read first! Feb 16 03:27:06 Oh. Feb 16 03:27:25 West Coast! Feb 16 03:27:30 Mountain Time! Feb 16 03:28:19 Something w/ a ton of extra research to be done! Feb 16 03:29:02 i.e. Ch. 1 says uboot and has a bunch of ideas about where to look for future readings. Feb 16 03:29:36 GenTooMan: Forget it. I understand it is bedtime. Must sleep, drool. Feb 16 03:29:43 ... Feb 16 03:31:06 That's better than newfi time (Newfoundland) it's an hour later than here. EST here. If you live near the west coast move away. Uboot is pretty old the first beagle boards used that. https://linux-sunxi.org/U-boot Feb 16 03:31:25 brain dead sleep night. Feb 16 03:36:25 hello all, when I run i2cdetect -r 2 on my beagle bone blue, I cannot see the mpu9250 and bmp280 Feb 16 03:36:47 i ran sudo rmmod inv_mpu6050_i2c, sudo rmmod inv_mpu6050 and sudo rmmod ak8975 Feb 16 03:36:52 and now I can see the mpu9250 Feb 16 03:37:01 but i don't know how to enable white bmp Feb 16 03:37:03 any help pls? Feb 16 03:37:30 Hey bmp: What is a white bmp? Feb 16 03:38:05 enable the* Feb 16 03:38:11 Oh. Feb 16 03:38:16 set_: sorry :p Feb 16 03:38:37 No issue. So, I know you want to enable your bmp280. Feb 16 03:38:57 set_: that is correct Feb 16 03:39:37 I will have to research this idea. I use the Grove Cable for my bmp. Feb 16 03:39:51 And I use it on the BBGW. Feb 16 03:40:14 So, BBBlue, i2c, and bmp280. Got it! Feb 16 03:40:36 set_: if its any help, it works perfectly fine on 4.9 kernek Feb 16 03:40:41 kernel* Feb 16 03:40:49 I am using kernel 4.14 Feb 16 03:41:06 oh...that is out of my realm. I have not gotten into the 4.14 kernel, yet. Feb 16 03:41:20 What is your error code? Feb 16 03:41:28 pastebin it. Feb 16 03:41:33 its just not showing up in i2cdetect Feb 16 03:41:47 Oh...do you have software to run w/ it yet? Feb 16 03:42:25 what do you mean, I have written a driver, but its not being recognised as a device Feb 16 03:42:33 i2cdetect has not gotten me anywhere. I have this cape and the cape's detection from that command shows nothing. Feb 16 03:42:35 Oh. Feb 16 03:43:19 Can you use your bmp280 w/out it being detected (for testing purposes)? Feb 16 03:43:58 i.e. w/out the bmp280 being detected by the i2cdetect cmd? Feb 16 03:44:10 ill have to try but it wasn't working fo rah empu Feb 16 03:44:13 for the mpu* Feb 16 03:45:07 Oh. I am asking b/c my cape states no visible detection of a specific, 4b, alpha-numeric entity but it works. Feb 16 03:45:11 ... Feb 16 03:45:29 I can use the i2c device even though the detection cmd found nothing. Feb 16 03:45:44 ill try iit out and get back to you Feb 16 03:45:49 Cool! Feb 16 03:46:06 In the meantime, I am looking up your ideas on info. Feb 16 03:46:17 Oops. Another got away. Damn. Feb 16 03:49:25 https://www.bosch-sensortec.com/bst/products/all_products/bme680 and something that will take time w/ the BBB! Feb 16 03:49:53 I bet I can find something already typed up. Feb 16 10:06:14 i cant seem to ssh thru putty Feb 16 10:06:42 hello Feb 16 10:08:49 can anbody help me with PRU-ARM communication setup? Please? Feb 16 17:32:19 Hi guys, so I'm looking for some PRU help Feb 16 17:32:47 Is it possible to insert assembly into the pru c code for time critical parts? Feb 16 17:33:21 you can write code in assembly and link it to C code Feb 16 17:33:38 zmatt: so uio-pruss is finally working for me! Inspired by derek molloy's book, I wrote this code that is supposed to blink the LED until mode button is pressed: https://pastebin.com/qcNSrNnM Feb 16 17:34:09 it doesn't blink the LED, but it returns the event number and halts after pressing the button although the LED stays on Feb 16 17:35:21 Ok, because I'm trying to read data out of a SPI bus with a 8MHz clock using the pru. I've been doing this by having a while loop that looks for the clock to transition from high to low and then read the data line. However, it often misses a bit or two because the time it takes to go through my while loop is too long compared to the clock speed. Feb 16 17:36:08 I was thinking writing this portion in assembly might speed it up enough, or perhaps there is some kind of hardware in the PRU that could help with this task. Feb 16 17:37:13 Guest3037: sounds to me like that should work fine in C if written properly, but the PRU C compiler is pretty awful... wouldn't expect it to be *that* awful though Feb 16 17:38:10 at least assuming you're using pru direct inputs Feb 16 17:39:02 Yeah, I'm reading __R31, bit 4 is the clock and bit 3 is connected to the data line. Feb 16 17:39:03 so if I understand correctly you're in spi slave mode ? or trying to a sniff an spi bus? since you don't have control over the clock ? Feb 16 17:40:22 I'm interfacing with an AD7779 ADC, once it is set running it acts as the master sending out conversion results on a bus almost identical to SPI. So the PRU has to be ready to read the data when it appears on the bus. Feb 16 17:44:25 right, so something like https://pastebin.com/Y48w7g60 ? Feb 16 17:45:27 8 MHz is not that much... 25 pru cycles per spi clock cycle Feb 16 17:45:44 does the compiler really mess it up that badly? Feb 16 17:45:53 Yes, exactly. Here is my code https://pastebin.com/GAkVPPmt Feb 16 17:46:35 I don't know if it is the compiler, or my bad code. Feb 16 17:46:42 your code looks less efficient though Feb 16 17:46:51 doing two tests in each wait loop Feb 16 17:47:01 uhh, also, ~ is wrong Feb 16 17:47:06 that tests is never false Feb 16 17:47:16 *test Feb 16 17:47:27 cl6x doesn't give a warning for this? Feb 16 17:50:18 Oh, thanks! I forgot logic not is !, ~ is bitwise. No, it did not give a warning. Feb 16 17:53:06 It works though, most of the time. Here is an example where the code misses a bit: https://pasteboard.co/H7WcVAF.png Feb 16 17:53:41 So I read in the first 32 bits of D0, then begin clocking them back out on DIO 7 (T1_POS) in my code. Feb 16 17:55:02 wow I'm staring at the disassembly of what cl6x produces for your code at the highest optimization level Feb 16 17:55:05 it's awful /o\ Feb 16 17:56:32 Thanks for looking at it! Maybe I can try it at a higher optimization level? Feb 16 17:56:45 I'm already using the highest optimization level Feb 16 17:56:56 change the declaration of i from 'int' to 'unsigned' please Feb 16 17:57:07 in general, avoid doing anything whatsoever with signed integers Feb 16 17:57:34 Good to know... Feb 16 17:57:56 and use separate loops to wait until clock high and wait until clock low, like I did in my example Feb 16 17:58:07 even so, I think the ~ is the main bug Feb 16 17:58:35 since even with all this inefficiency, it's not going to take 25 cycles per bit Feb 16 17:59:51 what optimization level are you using? Feb 16 18:00:59 I think the default, here is my Makefile: https://pastebin.com/vxdDjNCV Feb 16 18:01:20 I copied it from somewhere Feb 16 18:01:38 oh it doesn't really matter much anyway, -O1 up to -O4 all produce the same for your code Feb 16 18:02:39 -O0 is one instruction longer Feb 16 18:02:44 -Ooff is much much much worse Feb 16 18:03:55 you're using -O2 so that's fine Feb 16 18:04:25 why are you doing config-pin as part of your make install and make clean ? that makes no sense Feb 16 18:04:41 Cool, thanks so so much for all of the asistance. I thought 25 pru cycles should be enough, but wasn't getting good results. I'm making your mods right now. Feb 16 18:04:49 config-pin doesn't do persistent settings Feb 16 18:04:53 it should be plenty Feb 16 18:04:55 *assistance Feb 16 18:05:04 like I said I think the ~ bug is probably the main culprit Feb 16 18:28:19 ZMATT, thanks so much! Your suggestions worked amazingly! Feb 16 18:28:36 Here is my new code, https://pastebin.com/GSfkfJEe Feb 16 18:31:00 And here is the PRU reading in 32 bits from the D0 line and then clocking them back out on the T1 line. https://pasteboard.co/H7Wsawi.png Feb 16 18:31:24 The T0 line toggles each time it received a new bit. Feb 16 18:54:45 I'm suddenly seeing a lot of i2s-hifi errors in the kernel log Feb 16 18:55:06 don't remember turning this on - does anyone know how to stop i2s audio from loading? blacklist a module? Feb 16 18:55:21 hdmi-audio-codec hdmi-audio-codec.2.auto: ASoC: can't set i2s-hifi hw params: -19 Feb 16 18:56:22 mattvenn_: if you're using a recent image, you can disable audio in /boot/uEnv.txt Feb 16 18:57:17 I want to use audio, but I can't over i2s as the pins are used by the lcd panel I'm using Feb 16 18:57:27 so I'm using a plugin usb device Feb 16 18:57:52 that won't be affected Feb 16 18:58:02 cool Feb 16 18:58:33 actually, what? if you're using some kind of cape with conflicting pins, it should get disabled automatically Feb 16 18:58:52 or maybe u-boot needs to know about it but doesn't... dunno Feb 16 18:59:17 I'm sure it wasn't there last week! Feb 16 18:59:27 hdmi shouldn't be enabled at all actually if you're using an lcd cape of some sort Feb 16 18:59:30 because now my app doesn't play audio as the first device is the i2s Feb 16 19:00:06 I can see the snd_soc_hdmi_codec is loaded Feb 16 19:00:16 so there's something really weird going on Feb 16 19:00:35 the overlay for your lcd cape should be used *instead of* the hdmi video and audio overlays Feb 16 19:01:25 I did see something in the boot messages that I didn't recognise. Let me just reboot it Feb 16 19:03:28 https://pastebin.com/i4fCHNvr Feb 16 19:03:47 I'm fairly sure this has just started happening Feb 16 19:04:27 I've been messing around trying to get a recent pyqt5 installed so maybe some X related stuff got installed... Feb 16 19:08:30 that can't matter Feb 16 19:08:50 yes that shows the pinmux conflict Feb 16 19:08:57 I don't know why it's happening Feb 16 19:09:19 just disable hdmi video and audio manually in /boot/uEnv.txt Feb 16 19:09:33 maybe the conflict detection isn't as great anymore since u-boot overlays were introduced Feb 16 19:12:31 ok Feb 16 19:15:25 like cape_disable=BB-BONELT-HDMI Feb 16 19:15:25 ? Feb 16 19:15:29 no? Feb 16 19:15:38 unless your image is *that* old Feb 16 19:15:53 what's the current contents of your /boot/uEnv.txt ? Feb 16 19:17:01 https://pastebin.com/vkRzZ2Lk Feb 16 19:17:24 lines 40-41 Feb 16 19:18:03 Hello all, I have written PRU code to write a constant pwm pulse to SERVO1 of the BeagleBone Blue (pr1_pru1_pru_r30_8). The pulse is continuously sent until the PAUSE button (GPIO2_5) is pressed, after which it exits, however the code doesn't exit upon pressing the button, could someone tell me why? Here is the asm: https://pastebin.com/AmKcCCmy and here is the c loader: https://pastebin.com/sSrKsGZ7 Feb 16 19:18:12 thanks zmatt Feb 16 19:19:49 pwm_with_pru: at the very least lines 30-31 can be replaced by qbbs END, r6.t5 Feb 16 19:20:25 can you check whether the pause button's pin seems to be configured okay? https://github.com/mvduin/bbb-pin-utils/tree/blue#show-pins Feb 16 19:22:02 zmatt: I'd still need QBA READ_MEM right? Feb 16 19:22:07 no? Feb 16 19:22:12 oh wait Feb 16 19:22:19 I meant qbbs READ_MEM, .. Feb 16 19:22:21 sorry Feb 16 19:22:36 ok cool Feb 16 19:22:39 since END is located immediately after this Feb 16 19:22:51 so if the bit is cleared (button pushed) it should fall through Feb 16 19:23:02 PAUSE button 39 fast rx up 7 gpio 2.05 Feb 16 19:23:15 ok Feb 16 19:23:36 btw, keep in mind that right now you have very very little off-time Feb 16 19:23:59 oh you mean between the two rising edges? Feb 16 19:24:09 between falling edge and rising edge Feb 16 19:24:19 yeah sorry thats what i meant Feb 16 19:24:26 so ill have to add some off time there hmmm Feb 16 19:24:37 just 5 pru cycles + the time it takes to read gpio2's data-in Feb 16 19:24:59 is there anything wrong with the code as far as you can see? Feb 16 19:25:04 just that Feb 16 19:25:05 ill add that bit rn Feb 16 19:26:02 if you want a pwm signal you'll need to use a timer of some sort to make the rising edges exactly periodic Feb 16 19:26:17 since the lbbo for reading the gpio has variable timing Feb 16 19:26:36 how would I do that? Feb 16 19:27:11 also, right now your on-time is 43 seconds, is that intentional? Feb 16 19:27:24 that also means it checks the pause button only once every 43 seconds Feb 16 19:27:35 wait what..?! Feb 16 19:27:38 how is it 43 Feb 16 19:27:47 you set r0 to 0 Feb 16 19:28:13 each SUB takes 5ns right? Feb 16 19:28:17 so it has to be decremented 2^32 times before it tests equal to zero (since the test is after decrementing) Feb 16 19:28:26 each loop iteration takes two pru cycles Feb 16 19:28:39 each pru cycle is 5 ns Feb 16 19:28:58 so 2^32 * 2 * 5ns = 42.94967296 seconds Feb 16 19:29:15 wait I dint get what you meant by the 2^32 part Feb 16 19:29:24 didnt* Feb 16 19:29:29 two to the power of 32 Feb 16 19:29:47 since r0 is a 32-bit register Feb 16 19:29:48 Yeah but why is it subtracting 2^32 times Feb 16 19:29:57 because r0 is a 32-bit register Feb 16 19:30:04 won't it just subtract 1500*100 till it becomes 0? Feb 16 19:30:22 yes but you're initializing it to zero Feb 16 19:30:34 so the first iteration it will subtract one to make it 0xffffffff Feb 16 19:30:56 MOV r0, 0x00000000 this line? Feb 16 19:31:00 yes Feb 16 19:31:06 wait so how do I read from the SRAM???? Feb 16 19:31:24 wait why did you think that would read from sram? Feb 16 19:31:30 because in the book I read this was given: MOV r0, 0x00000000 // load the memory location Feb 16 19:31:45 oh fuck Feb 16 19:31:46 wait Feb 16 19:31:49 i messed up Feb 16 19:32:00 so how do I read from SRAM? Feb 16 19:32:13 are you sure that wasn't just a placeholder for "we haven't explained this yet so just use a constant value for now" ? Feb 16 19:32:31 yeah probably... Feb 16 19:32:40 so if I loaded it like this: prussdrv_pru_write_memory(PRUSS0_PRU1_DATARAM, 0, &pulsewidth, 4); Feb 16 19:32:46 Where can I read it from? Feb 16 19:33:41 if you're executing your code on PRU1 then lbco &r0, c24, 0, 4 Feb 16 19:34:11 if you're executing your code on PRU0 then you should probably use its dataram, but if necessary it can also access the other pru core's sram by using c25 instead of c24 Feb 16 19:35:12 PRUSS0_PRU1_DATARAM would mean C24 right? Feb 16 19:35:35 c24 = the data ram of the pru core executing this code Feb 16 19:35:43 c25 = the data ram of the other pru core Feb 16 19:35:52 ok cool Feb 16 19:36:10 for code running on pru0, c24 = pru0 data ram, c25 = pru1 data ram Feb 16 19:36:16 for code running on pru1, c24 = pru1 data ram, c25 = pru0 data ram Feb 16 19:37:07 where can I find the docs for this? the TRM for the am335x? Feb 16 19:37:25 yeah that's one decent source of info Feb 16 19:38:18 any better place cuz that stuff is really not inviting for me Feb 16 19:38:32 or if you just want a quick overview of the various constant-registers, here it is: https://pastebin.com/raw/3ebDZUfp Feb 16 19:39:40 could you explain what the pwmss is and does? Feb 16 19:39:51 thanks for that!!! thats so convenient Feb 16 19:41:53 pwmss is a subsystem containing an eHRPWM peripheral (two pwm outputs), an eCAP peripheral (one pwm output or one capture input), an eQEP peripheral (quadrature or pulse-counting input), and some synchronization logic Feb 16 19:42:39 the eQEPs are used for three of the encoder inputs of the beaglebone blue Feb 16 19:44:03 two of the eHRPWM instances are used for the motor outputs Feb 16 19:44:40 i guess implementing pwm by setting high and low is a good enough way? Feb 16 19:44:43 (the third one could be accessed via the spi headers or via the "GPS" header if those are reconfigured from their default functions) Feb 16 19:45:17 is there no pru firmware already for using the servo outputs for pwm? surely there has to be? Feb 16 19:46:05 https://github.com/omcaree/bbb-prupwm/blob/master/src/pwm.p Feb 16 19:46:09 does the same thing right? Feb 16 19:47:29 ok so between falling edge and rising edge of two subsequent pulses I am adding a 1000uS delay, would this do the job: https://pastebin.com/AiqVF345 Feb 16 19:47:56 no Feb 16 19:48:19 please just try to think about what would happen here step by step Feb 16 19:49:04 i don't really know what the SUB instruction does tbh, does it start to subtract one from the right most bit or from the leftmost Feb 16 19:50:30 uhh, did you learn how subtraction works in school? :) Feb 16 19:51:51 since you're not using bitwise operations here anyway you don't need to worry about bits, r1 just contains a number and you're subtracting one from it Feb 16 19:51:54 ah fuck go try mistake Feb 16 19:51:57 got my* Feb 16 19:52:16 this isn't 1000us btw, it's 4369us Feb 16 19:52:36 if you had put the DELAY label in the right place that is Feb 16 19:52:39 right now it's an infinite loop Feb 16 19:54:04 step 1: set r1 to 0x1111 (i.e. 4369) Feb 16 19:54:06 2^20 would do the job right Feb 16 19:54:15 step 2: subtract 1 from r1 Feb 16 19:54:27 step 3: if r1 is not zero, go to step 1 Feb 16 19:54:34 I hope you see the problem with that Feb 16 19:54:52 yeah Feb 16 19:55:15 sorry, I said us above but I meant ns Feb 16 19:55:18 no wait Feb 16 19:55:21 cycles Feb 16 19:55:23 jeez Feb 16 19:55:34 sorry, can't brain today, have the dumb Feb 16 19:56:10 0x100000 would be roughly 1000us? Feb 16 19:56:26 ah im just rushing it Feb 16 19:56:41 ill try it later when im calm prolly just doze off now Feb 16 19:56:51 zenks for ze help Feb 16 19:56:56 it wouldn't be Feb 16 19:56:57 not remotely Feb 16 19:57:14 why are you using hex constants when the numbers you want are nice round numbers in decimal? Feb 16 19:57:44 i can just write in 1000? Feb 16 19:57:48 sorry i mean Feb 16 19:57:51 the number in decimal Feb 16 19:57:54 into the reg? Feb 16 19:57:56 1000us is 200000 cycles Feb 16 19:58:06 each loop iteration is two cycles, so you want 100000 iterations Feb 16 19:58:12 hence mov r1, 100000 Feb 16 19:58:17 oh lol Feb 16 19:58:17 sure, why wouldn't you? Feb 16 19:58:24 you're using decimal constants right below it Feb 16 19:58:32 in the sub and qbne instructions Feb 16 19:58:58 good point Feb 16 19:59:03 idk why i thought that Feb 16 19:59:04 you can even write expressions there Feb 16 19:59:45 mov r1, 1000 /*us*/ * 100 /*loop iterations per us*/ Feb 16 20:00:02 oh Feb 16 20:00:11 sheeeeit Feb 16 20:01:14 sorry for making you deal with a Neanderthal Feb 16 20:03:04 btw, writing lbco r0, ... is kinda deprecated, the preferred form is lbco &r0, ... Feb 16 20:03:22 likewise for sbco, lbbo, sbbo Feb 16 20:03:29 noted Feb 16 20:03:59 since you're loading/storing a byte-range of the register file Feb 16 20:04:19 so LBBO r6, r5, 0, 4 Feb 16 20:04:21 sorry Feb 16 20:04:48 so lbbo &r6, r5, 0, 4 is like doing memcpy( &r6, r5 + 0, 4 ); Feb 16 20:04:53 in C Feb 16 20:05:04 if we'd pretend you can use a pointer to a register like that :) Feb 16 20:05:26 sorry reloaded the page by accident, what did you say after rLBCO r6, r5.. Feb 16 20:05:32 after LBCO* Feb 16 20:06:04 I accidently pressed enter there, apologies, and then said: Feb 16 20:06:07 so lbbo &r6, r5, 0, 4 is like doing memcpy( &r6, r5 + 0, 4 ); Feb 16 20:06:11 if we'd pretend you can use a pointer to a register like that :) Feb 16 20:08:53 ahhh Feb 16 20:10:17 (pru actually does have instructions that can use pointers into the register space, e.g. allowing you to use part of the register space as a very fast stack) Feb 16 20:46:31 zmatt: the PRU is a 6502? Feb 16 20:46:55 zmatt: ah no, the 6502 was the other way round :-) Feb 16 20:54:29 Hey, zmatt, are you about with your sage advice this time? Feb 16 20:54:56 We've upgraded the image to "BeagleBoard.org Debian Image 2018-01-28 Feb 16 20:54:57 " Feb 16 20:55:17 And now all the pins set correctly (again after disabling the unneeded audio cape) Feb 16 20:55:53 And like last time, I get "prussdrv_open(PRU_EVTOUT_0) failed ( == -1)" Feb 16 20:56:31 Last time I fixed this by switching to the -bone kernel, but I missed that you'd said this was an issue with loading overlays previously Feb 16 20:56:46 is there a correct way to fix this, or should I just try loading the bone kernel again Feb 16 20:59:29 Or, is there a way I can fix this that aids in making the downloadable images not have the issue, assuming my understanding is correct that the issue is with the image Feb 16 21:07:32 ... Feb 16 21:07:39 actually, it doesn't work on either kernel Feb 16 21:13:25 zmatt: I noticed that servo1 is not set as output Feb 16 21:13:30 how can i set it to putout? Feb 16 21:13:33 pruout* Feb 16 21:13:51 idt config-pin works for bbblue? Feb 16 21:20:14 also how can I check the current dts being used? Feb 16 21:25:22 would it be the am335x-boneblue.dts? Feb 16 21:30:21 I think config-pin should work Feb 16 21:30:24 yes it is Feb 16 21:30:36 no easy way to check other than by looking at u-boot's output on the serial console Feb 16 21:32:49 so i did config-pin -l p8_27 (for Servo1) Feb 16 21:33:10 i got this: default gpio gpio_pu gpio_pd gpio_input pruout pruin Feb 16 21:33:17 and show pins says its rx and down Feb 16 21:33:41 how do i set it to pruout Feb 16 21:33:48 config-pin p8_27 pruout Feb 16 21:34:19 I thought is was a . instead of _ Feb 16 21:34:36 P8_27 pinmux file not found! Feb 16 21:35:11 try P8.27 Feb 16 21:35:34 its the same Feb 16 21:35:46 Damn. Sorry. I am out of ideas. Hmm. Feb 16 21:36:31 so this, config-pin P8.27 pruout, cmd shows errors? Feb 16 21:36:41 yes Feb 16 21:36:44 Oh. Feb 16 21:36:52 I think its a problem with the dts? Feb 16 21:36:56 zmatt: You know more. Feb 16 21:37:11 zmatt: I don't see th servo pins configured in the bone blue dts Feb 16 21:38:18 Did you read about config-pin on some websites? Feb 16 21:38:44 pwm_with_pru: which kernel are you using? Feb 16 21:39:06 4.14-ti-rt Feb 16 21:39:18 to be precise: 4.14.18-ti-rt-r33 Feb 16 21:39:32 4.14 is for x15, right? Feb 16 21:39:45 set_: ??? Feb 16 21:39:48 set_: why do you keep getting these strange ideas? Feb 16 21:39:52 brb pizza Feb 16 21:40:19 I thought that kernel was only for the x15 says elinux sites. Feb 16 21:40:30 I looked online. Feb 16 21:41:13 I thought since they were still in a testing phase on that kernel (even though it is stable) w/ the BBB and variants. Feb 16 21:41:22 ... Feb 16 21:41:24 forget it. Feb 16 21:41:26 I am wrong. Feb 16 21:42:27 sorry, the 4.14.x kernel is for xM. Feb 16 21:43:01 this is complete nonsense, where did you read that? Feb 16 21:43:40 I mean yeah 4.14 is not default yet for BBB, but that doesn't mean that's a reason to not use it Feb 16 21:43:47 Look here: https://elinux.org/Beagleboard:BeagleBoneBlack_Debian. It shows under Stretch that this kernel is supported for the xM only. Feb 16 21:43:48 Oh. Feb 16 21:43:55 zmatt: Okay. Feb 16 21:44:26 I looked at the rest of the supported kernels. 4.14.x only shows under the xM heading. Feb 16 21:44:53 yeah so like I said, it's just not yet used by default Feb 16 21:44:59 I mean, yea. You could update your kernel to 4.14.x. Right. Feb 16 21:45:00 umm so do I have to reconfigure the dts? Feb 16 21:45:26 pwm_with_pru: no Feb 16 21:45:40 the servo pins should either be reconfigurable or fixed to pruout Feb 16 21:45:44 pruout is their default use Feb 16 21:46:18 I'll check the dts, but I'm a bit slower since I'm also eating pizza Feb 16 21:46:25 Pizza! Feb 16 21:46:31 also im hungry.. Feb 16 21:46:45 oven Pizza from a BBB decorated oven? Feb 16 21:47:14 * n8vi fixes his problem by reordering /boot/uEnv.txt Feb 16 21:47:48 u-boot is now used, right? No more cape_mgr and no more of that other humbug? Feb 16 21:48:08 ... Feb 16 21:48:31 Sorry...on updated kernels, 4.4.x and above? Feb 16 21:48:38 i just wanted to know once and for all, the best way to see a pin setting is config-pin -l and/or show-pins right? Feb 16 21:48:46 and to reconfigure? Feb 16 21:48:50 Oh. Feb 16 21:49:10 I will look it up again while zmatt looks at his gorgeous pizza display. Feb 16 21:50:32 This is my idea: Downgrade to 4.9.x or 4.4.x for your BBBlue. I have had difficulty w/ the 4.9.x kernel but it is a lack of participation at times and a lack of reading for me. Feb 16 21:50:33 ... Feb 16 21:50:39 I say ultimately listen to zmatt. Feb 16 21:50:48 pwm_with_pru: oh lol what, for whatever reason the boneblue's dts for your kernel version doesn't configure the servo pins nor makes any pins runtime-configurable Feb 16 21:50:49 lol Feb 16 21:51:00 exactly Feb 16 21:51:12 for some reason they forgot to forward-port boneblue's dts from 4.9-ti to 4.14-ti ? Feb 16 21:51:32 eesh Feb 16 21:51:52 ... Feb 16 21:51:56 can't we just copy paste the 4.9 pinmux ? Feb 16 21:52:05 Hhaahha. Feb 16 21:52:29 what? Feb 16 21:52:33 z:p Feb 16 21:52:36 :p Feb 16 21:52:39 pwm_with_pru: I think you should be able to just grab the 4.9-ti am335x-boneblue.dts and recompile that with the includes from the 4.14-ti tree Feb 16 21:53:11 so ill empty the contents of the 4.9-ti into the 4.14 one? Feb 16 21:53:33 so, grab the 4.14-ti branch of https://github.com/RobertCNelson/dtb-rebuilder Feb 16 21:54:14 git checkout origin/4.9-ti -- src/arm/am335x-boneblue.dts Feb 16 21:54:20 make src/arm/am335x-boneblue.dtb Feb 16 21:54:21 thats there in /opt/source/dtb-4.14-ti Feb 16 21:54:44 assuming it's a git repo, do git pull and then the commands above Feb 16 21:55:29 the checkout command will replace src/arm/am335x-boneblue.dts with the version from the 4.9-ti branch Feb 16 21:57:35 4.9-ti configures them fixed to pruout -> https://github.com/RobertCNelson/dtb-rebuilder/blob/4.9-ti/src/arm/am335x-boneblue.dts#L85-L92 Feb 16 21:57:48 https://github.com/jadonk/BeagleBone-Robotic-Projects-Second-Edition Feb 16 21:57:55 This will help w/ software and ideas. Feb 16 21:58:30 maybe there's a reason they're not being configured in 4.14-ti though, maybe they're working on splitting the functionality off into overlays just like it's done now for other beaglebone variants Feb 16 21:58:46 u-boot! Feb 16 21:59:09 ... Feb 16 21:59:25 ill have to reboot after running make? Feb 16 21:59:49 Hey...what is that site that shows PandaBoard and BBB/Variants w/ descriptions on Cross Comp. and U-Boot Overlays? Feb 16 21:59:57 ... Feb 16 22:00:00 you need to copy the dtb file to /boot/dtbs/4.14.18-ti-rt-r33/ after making a backup of the original file Feb 16 22:00:22 and then reobot Feb 16 22:00:24 *reboot Feb 16 22:01:04 also, I hope you have a bootable sd card on standby for recovery in case the system fails to boot from this dtb for whatever reason :) Feb 16 22:02:17 where is the dtb file after running make? Feb 16 22:02:47 the exact path you used for the make command Feb 16 22:03:28 oh i missed it Feb 16 22:04:08 save that older image in case you erase the whole kit and kaboodle. Feb 16 22:04:20 Orders! Feb 16 22:04:25 Hhahaha. Feb 16 22:04:29 ... Feb 16 22:04:29 set_: ? Feb 16 22:04:30 Sorry. Feb 16 22:04:34 yeah i have the image saved on an sd card :p Feb 16 22:04:41 Good idea! Feb 16 22:05:01 you can just boot from sd card and move the backup dtb back Feb 16 22:05:02 well its rebooting Feb 16 22:05:20 I once erased all my "good" stuff. I was so pissed off. I gave up breathing for 12 hours. Feb 16 22:05:28 Rebooting! Feb 16 22:05:32 and that day you learned the value of backups Feb 16 22:05:38 Yea. Feb 16 22:06:01 I never thought backing up was a genius way to solve issues. Now, I know. Feb 16 22:06:21 zmatt: once again you have saved the day :p SVO1 56 fast down 5 pru 1 out 8 Feb 16 22:06:34 btw what does that "down" mean? Feb 16 22:06:35 Can I cheer yet? Feb 16 22:06:56 I saw that too. Feb 16 22:07:11 "down" means what? I know in/out but down? Feb 16 22:07:23 internal pulldown enabled Feb 16 22:07:37 Aw! Bingo! Feb 16 22:08:20 zmatt: You are a wealth of info. and all balled up into one name. Thank you. Feb 16 22:08:51 ... Feb 16 22:11:35 eeWiki. I found it again. Feb 16 22:12:12 First you go to DigiKey, look at their resources section, go to the TechForum, and then to Linux on ARM! Feb 16 22:12:13 Boy! Feb 16 22:13:42 I think. Anyway, here is the site: https://eewiki.net/display/linuxonarm/BeagleBone+Black Feb 16 22:14:18 <<<< on break from bragging about me not creating today Feb 16 23:01:08 zmatt: for this python uio (https://github.com/mvduin/py-uio/blob/master/pruss-test.py), what is the correspondence with prussdrv? Feb 16 23:01:17 like, i know only how to use prussdrv... Feb 16 23:01:42 I've never used prussdrv Feb 16 23:02:14 I'm not sure there's a 1:1 correspondence, but that test doesn't do that much anyway Feb 16 23:02:24 alright umm, what are these "settings" https://github.com/mvduin/py-uio/blob/4d7cea2bbc5d01f6d072e5e0452ad41c046ef0e7/pruss-test.py#L9 Feb 16 23:03:54 and im assuming theres more states than "halted"? what are those? Feb 16 23:05:15 unfortunately there isn't a clean set of states, there are actually a bunch of flags. halted is important here since you can't access the pru core's registers unless it's halted Feb 16 23:06:00 halted just tests bit 15 of the core's control register: https://github.com/mvduin/py-uio/blob/master/ti/icss/core.py#L43-L45 Feb 16 23:06:22 most definitions are still missing here, this was just a really minimal example to get some code running Feb 16 23:06:36 here is my C header for the core's registers: https://liktaanjeneus.nl/pdsp.h.html Feb 16 23:06:45 is this your python library?? Feb 16 23:07:03 its frickin amazing if i may say so Feb 16 23:07:52 yeah I made this example last week because someone was trying to use this unmaintained 'pypruss' library or something like that, and had a lot of trouble with it Feb 16 23:07:56 how would I load a bin file in? recursivly read bytes into iram.map?? Feb 16 23:08:21 oh Feb 16 23:08:25 no, don't map it, I just did that to be able to access it as an array of instructions Feb 16 23:08:34 you can... uhh... moment Feb 16 23:11:41 oh right I made a method for it... pruss.iram0.write( data, offset ) Feb 16 23:12:02 offset is optional and defaults to 0 Feb 16 23:12:20 so i read the bin file recursively into data Feb 16 23:12:22 data is anything that supports the buffer interface, typically a bytes object Feb 16 23:12:22 and pass data Feb 16 23:12:24 ? Feb 16 23:12:28 okay Feb 16 23:12:33 il try this ad get back to you Feb 16 23:12:35 and* Feb 16 23:12:36 what do you mean by 'recursively' ? Feb 16 23:13:33 like: with open('somefile.bin', 'rb') as f: data = f.read() Feb 16 23:13:39 with open('somefile.bin', 'rb') as f: data = f.read() Feb 16 23:13:41 oops Feb 16 23:13:43 wait a sec Feb 16 23:14:01 https://pastebin.com/UsL13dDe Feb 16 23:14:02 yep Feb 16 23:14:06 okay cool Feb 16 23:14:08 brb Feb 16 23:14:19 or just call pruss.iram0.write( f.read() ) directly Feb 16 23:26:42 zmatt: i should copy /home/debian/py-uio/etc/modprobe.d to my /etc/modprobe.d? Feb 16 23:32:31 ahh okay from /etc/udev Feb 16 23:36:25 the modprobe rule isn't important for this, although it's also not harmful Feb 16 23:36:34 that's for uio examples other than uio-pruss Feb 16 23:36:51 the udev rule is important Feb 16 23:37:36 the hwdb thing is for being able to give nice names to the various irqs from pruss to cortex-a8, but other than that aren't important Feb 16 23:44:48 oh I actually changed the example to load from file, but never committed and pushed that Feb 17 00:55:35 Does OS Virtualization Software mean from a VMware Workstation or something like VirtualBox, too? Feb 17 00:55:35 ... Feb 17 00:55:58 I am reviewing the eewiki site about the BBB and I came across the info. Feb 17 00:56:17 ? Feb 17 00:56:22 context? Feb 17 00:56:24 Can it mean PuTTY? Feb 17 00:56:43 ... Feb 17 00:57:14 It has to do w/ ARM Cross Compiler: GCC and Bootloader: U-Boot. Feb 17 00:57:15 yes, yes that must be it. I'm sure PuTTY is considered OS Virtualization Software, except by those few weird people who think it's an ssh client Feb 17 00:57:27 See. Feb 17 00:57:42 Just making sure. Someone has to keep the mundane ideas rising. Feb 17 00:57:59 can't you just link to whatever it is you're talking about? because you're sounding really vague again Feb 17 00:58:08 Okay. Please hold. Feb 17 00:58:21 https://eewiki.net/display/linuxonarm/BeagleBone+Black is the link! Feb 17 01:00:28 not sure what he's referring to, using a VM to run a host environment for cross-compiling should work just fine and is done often enough by windows users Feb 17 01:01:07 I thought so... Feb 17 01:01:16 But, I guess it is not easy-peasy. Feb 17 01:01:24 ? Feb 17 01:01:39 what isn't? Feb 17 01:01:43 I thought cross compilation was difficult to newbies like me. Feb 17 01:02:34 regardless there's no difference between whether you're using a VM or not Feb 17 01:02:56 whether cross-compilation is more difficult than native compilation varies very much depending on what you want to compile Feb 17 01:02:57 Oh. Feb 17 01:03:05 Okay. Feb 17 01:03:09 stuff like the kernel and u-boot make it trivial Feb 17 01:03:16 I thought so. Feb 17 01:03:24 and only an idiot would try to compile a kernel natively on a bbb Feb 17 01:03:48 I know already. Are there any better machines to use for compilations? Feb 17 01:04:00 ARM? Feb 17 01:04:13 I looked around but came up empty on my journey. Feb 17 01:04:36 just use some x86/amd64 machine running debian (or perhaps ubuntu) Feb 17 01:04:45 Oh...okay. Feb 17 01:04:47 and cross-compile Feb 17 01:05:42 See...I have an issue. I have a damn Win machine and a VMware Workstation (OS Virt. Soft) running Ubuntu. Feb 17 01:05:52 cross-compilation can mainly be a headache if you have library dependencies Feb 17 01:05:55 I can get Debian. Feb 17 01:06:14 debian in a VM on a fast windows machine is still going to be a lot faster than compiling on a beaglebone Feb 17 01:06:23 Universal OS! Feb 17 01:06:50 zmatt: What ARM devices can you recommend outside of the BBB for heavy tasks? Feb 17 01:07:58 another nice trick is to use 'distcc' to delegate compilation from the bbb to the debian system in your VM. it adds some overhead, but has the benefit of working hassle-free for all software Feb 17 01:08:12 I'm not really in the mood to explain how to set that up though (although it was surprisingly easy) Feb 17 01:08:21 I was reading online on the website, bbb.io, when I found a caption, "beefy system." It was refering to compiling on ARM machines. Feb 17 01:08:21 I have no experiences with ARM devices for heavy task Feb 17 01:08:26 Okay. No issue. Feb 17 01:08:53 I don't see much point since it's much easier to get a beefy x86 system than a beefy arm system Feb 17 01:09:19 well, I guess it would still help Feb 17 01:09:36 I noticed. It seems dificult b/c of the updated versus the not updated software they run on the ARM machines that are on sale. Feb 17 01:09:45 ... Feb 17 01:10:30 I found a site a while back. They had arm machines but not w/ much ram or eMMC. Feb 17 01:11:07 It was like not an option for ARM and SoC or CoM. Feb 17 01:11:34 It pissed me off. Feb 17 01:12:08 So... Feb 17 01:13:15 use usb3 or sata instead of eMMC Feb 17 01:13:21 likely to be much faster Feb 17 01:13:27 Okay. Feb 17 01:14:08 ram is still important, and cpu power of course Feb 17 01:14:12 I saw a Dell Workstation for cheap. It had a Linux Distro "included." Feb 17 01:14:23 but I have trouble believing it's hard to find a recent arm-based system Feb 17 01:14:24 zmatt: in derek molly's book, pg 526, he mentions that he is loading the second value into the "next word location in memory, i.e. 4 bytes later" Feb 17 01:14:31 isn't a word 2 bytes long? Feb 17 01:14:43 does he mean next register in memory? Feb 17 01:14:43 ... Feb 17 01:15:26 pwm_with_pru: the word "word" is context-sensitive, but for both the cortex-a8 and the pru it's definitely 32 bits. Feb 17 01:15:52 I have the book on my desk. Let me look. Feb 17 01:16:20 lol but in the same book he's shown that a word is made up of 16 bits :p Feb 17 01:16:26 thats why I got confused Feb 17 01:16:29 though pru's assembly does use 'w' for 2-byte units for some weird reason... I can't imagine what the hell led to that design choice, since the pru has no 16-bit heritage to explain it Feb 17 01:17:49 so here (https://github.com/beagleboard/am335x_pru_package/blob/83021ac2f64b5ce274c4362aed73f7b0f3a3aa76/pru_sw/app_loader/interface/prussdrv.c#L336) word offset would mean the same as reg offset? Feb 17 01:18:22 what do you mean by 'reg offset' ? Feb 17 01:19:12 wordoffset just means offset in number of 32-bit words Feb 17 01:19:15 this is really weird code btw Feb 17 01:19:27 why the fuck do they use 'wordoffset' instead of byteoffset Feb 17 01:19:32 and just use memcpy Feb 17 01:20:22 this is just awkward to use and less efficient Feb 17 01:20:55 I looked at p. 526. I cannot see anymore! Feb 17 01:20:59 also why the hell do they use a bytelength parameter, but then round it up to an integral number of words? Feb 17 01:21:32 btw i got disconnected before I could find out.. what file do I copy to my /etc for being able to use py-uio? Feb 17 01:22:19 zmatt: idk but maybe it is b/c of the length of 0s and 1s. Feb 17 01:22:53 pwm_with_pru: etc/udev/rules.d/09-uio-pruss.rules is the only one strictly necessary Feb 17 01:23:08 zmatt: how does your library do the INTC thing, where the ARM host is notified? Feb 17 01:23:21 set_: please stop talking. the bizarre nonsensical comments you keep sprouting are getting really tiresome Feb 17 01:23:26 zmatt: I just copy that to my /etc/udev/rules? Feb 17 01:23:31 Otay! Feb 17 01:23:37 pwm_with_pru: yes Feb 17 01:23:49 pwm_with_pru: I haven't implemented irqs yet Feb 17 01:24:24 zmatt: so the PRU will b din a halted state once the code is done right Feb 17 01:24:29 will be in a* Feb 17 01:25:11 for those you'll want to also install etc/udev/rules.d/10-of-symlink.rules and etc/udev/hwdb.d/uio-pruss.hwdb ... in the latter file you can configure names for the irqs. run sudo systemd-hwdb update after updating the hwdb file Feb 17 01:25:45 zmatt: then we can check bit 2 of the core?? Feb 17 01:25:48 zmatt: okay Feb 17 01:26:09 zmatt: but how can I setup the irc in your python lib? like whats the method? Feb 17 01:26:10 pru is in halted state when it executes 'halt' or tries to execute an illegal instruction Feb 17 01:26:20 ok Feb 17 01:27:12 and if you clear bit 1 of the control register, or when single-stepping is enabled, the core halts after execution of the current instruction has completed Feb 17 01:28:19 what is a sleep state? i.e. bit 2 Feb 17 01:29:05 receiving the irq should be pretty simple... it'll be similar to the 'gpio-irq' examples probably, although I should check if irqs work exactly the same for uio_pruss as they do for uio_pdrv_genirq (for which py-uio was originally written) Feb 17 01:29:14 but the pruss intc also needs to be setup Feb 17 01:29:19 that will require more code Feb 17 01:29:41 I'm not sure how much of this I'm going to write... py-uio was actually kind of an abandoned project Feb 17 01:30:01 I just used it to quickly make an example that it's not that hard to deal with pruss using pure python Feb 17 01:30:38 alright, well it seemed like a much better alternative to the am355x_pru_package Feb 17 01:30:42 (the reason it's kind of abandoned is because the more I used python, the more I started to dislike it) Feb 17 01:31:08 hmmm Feb 17 01:31:17 maybe I'll just add the pruss irq support, at least at a basic level Feb 17 01:31:39 that'll make it on par with prussdrv right Feb 17 01:31:40 people who care can then flesh out the details Feb 17 01:31:49 at the very least Feb 17 01:32:03 if you look at the source code in ti/icss you'll see that it's actually quite simple Feb 17 01:34:15 hmmm true Feb 17 01:36:10 damn I really love the -J option added to ssh (since openssh 7.3) Feb 17 01:36:33 ???? what does that do Feb 17 01:36:34 aka ProxyJump Feb 17 01:37:19 ssh -J proxy-host target will ssh to proxy-host, and from there will ssh to target Feb 17 01:38:37 very useful if you want to reach a beaglebone that's not internet-accessible but there's an internet-accessible server on the same network Feb 17 01:39:12 before that I'd use something like ssh proxy-host -t ssh target Feb 17 01:39:45 but quite a few ssh features don't work that way, and this unnecessarily exposes your ssh agent to the proxy-host Feb 17 01:40:15 plus proxyjump can be configured for a host in your .ssh/config, after which you can just 'ssh target' and ssh will know to use the proxy Feb 17 01:40:58 oh ho, thats something nice Feb 17 01:52:43 This book is hilarious, "BeagleBone Black Programming by Example." Feb 17 01:53:04 I just picked it for $3.00. Feb 17 01:54:09 pwm_with_pru: I just updated the gpio-irq example slightly. receiving irqs from pru would be example the same except that calling 'irq_enable' should be omitted Feb 17 01:55:04 zmatt: i tried running pruss-test.py after copying 09-uio-pruss.rules to my /etc/udev/rules, I got this: No such file or directory: '/dev/uio/pruss/module' Feb 17 01:55:37 reboot after adding the file to /etc/udev/rules.d/ or remove and reinsert the uio_pruss kernel module Feb 17 01:55:56 or run udevadm trigger with the right parameters Feb 17 01:56:46 i seriously feel you shouldn't have given up on the python UIO :p Feb 17 01:57:17 even in the very short time I've worked on adding the icss stuff, I've already quickly remembered how much I dislike python Feb 17 01:57:41 lol alright :p Feb 17 01:57:47 I think I'll still add some basic irq handling, but don't expect much more from me Feb 17 01:59:24 it really sucks that python, due to its lack of variable/function declarations, does not catch any sort of typo at compile-time Feb 17 02:00:05 yeah thats one major drawback Feb 17 02:01:01 (that's not the only thing I dislike about python, but it's definitely a big one) Feb 17 02:03:25 what else then :p Feb 17 02:04:12 I'd have to think since it's been a while since I did any significant amount of python programming... I'd rather spend my energy on adding irq support to py-uio and then dump the language again Feb 17 02:06:07 hmm Feb 17 02:12:16 im gonna catch some sleep Feb 17 02:12:24 ill connect back in a few hours Feb 17 02:12:25 lol i just noticed I accidently used semicolons after some statements Feb 17 02:12:36 hahahahaha Feb 17 02:16:37 zmatt: did you get the book yet? Feb 17 02:16:56 ? Feb 17 02:17:10 BeagleBone Black Programming by Example! Feb 17 02:17:18 why the hell would I? Feb 17 02:18:02 It has some cool info, plus you can have a collective laugh at some German's way of translating English. Feb 17 02:18:40 Come on...it only costs $3.00. Feb 17 02:27:02 This fellow is inventive and active. Feb 17 02:27:24 and for the BBB, I give the book six out of 10 Hooligans! Feb 17 02:44:08 ls Feb 17 02:44:11 oops. Feb 17 02:54:21 I'll try not to crack a bad joke. Feb 17 02:54:47 Hey...how to enable UART1, 2, 4, and 5? Feb 17 02:54:56 See...I am reading. Feb 17 02:55:18 config-pin? Feb 17 02:55:35 on kernel 4.14.x? Feb 17 02:56:11 the uarts themselves are enabled by default (assuming default configuration /boot/uEnv.txt and a sufficiently recent image), you just need to setup pinmux using config-pin Feb 17 02:56:12 connect them to 5V? oh that would disable them :D yes config-pin likely normally that happens when using an EEPROM that demands the settings however if the boot EEPROM configures the IO differently you have to override it. Feb 17 02:56:29 uhh Feb 17 02:56:39 there's no config coming from eeprom Feb 17 02:57:36 capes and the main board have EEPROMs correct? Feb 17 02:58:01 in all cases just for board/cape identification Feb 17 02:58:22 in case of capes this should trigger an overlay to be loaded automatically which performs configuration Feb 17 02:58:57 (which you can't override except by modifying or disabling the overlay. but usually you shouldn't do that anyway) Feb 17 02:59:17 which also means that when people ask to enable stuff, I'm assuming this isn't for a cape Feb 17 02:59:42 No cape...I am connecting a Ard. Uno. **** ENDING LOGGING AT Sat Feb 17 03:00:00 2018