**** BEGIN LOGGING AT Thu Feb 20 02:59:57 2020 Feb 20 03:01:15 hmmmm rebuilding a new SD card w/SGX isn't working Feb 20 03:24:35 hopefully none of my gross misfortune has attacked you. Feb 20 03:29:36 ARRRRRRRRRRRRRRRRRRRRRRRGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG Feb 20 03:29:43 breathe Feb 20 03:30:03 @#%#@@!$@#%@#$@#@#$@# eglinfo fails if there isn't a real fb defined Feb 20 03:30:35 just force a video mode? Feb 20 03:30:46 (via kernel parameter) Feb 20 03:31:05 yes Feb 20 03:31:18 that was the fix...hence the arggggg Feb 20 03:31:29 no reason for that as it is legit to render to a mem buffer Feb 20 03:31:32 the alternative is shimming the platform glue to make it use vgem instead of tilcdc Feb 20 04:26:39 hmmm about 1/40 of a second to send/compute/receive 256K points Feb 20 12:26:13 Would I look at peak forward current on a datasheet or steady current on that same datasheet when interfacing a LED to a PWM pin on the BBB? Feb 20 13:20:20 bbl! Feb 20 13:25:28 neither. you'd look up the max forward voltage, and then (3.3 - max forward voltage)/0.004 gives you the minimum value for the series resistor Feb 20 13:25:53 unless the led's max forward current is less then 4 mA, but that seems unlikely Feb 20 13:26:15 Why would you say 0.004? Feb 20 13:26:24 For the pin mA? Feb 20 13:26:38 It is less. Feb 20 13:27:04 max 4 mA to avoid damaging the AM335x I/O. this is if you're connect the led directly, if you're using a led driver then the story changes Feb 20 13:27:17 Okay. Got it. Feb 20 13:27:30 As always and forver, thank you! Feb 20 13:27:36 it is less? what's the LED's max allowed steady current? Feb 20 13:27:45 No. Feb 20 13:27:52 Oh. Please hold. Feb 20 13:27:55 Let me go see. Feb 20 13:28:13 30/25 Feb 20 13:28:32 "30/25" ? Feb 20 13:28:48 That is what it says. Maybe it means 30 or 25. Feb 20 13:28:59 link to datasheet? Feb 20 13:29:05 Pleaseh hold. Feb 20 13:33:24 https://drive.google.com/file/d/1O8SXv9-T0lPte0lXE2eq2BzIR2J3U02Q/view?usp=sharing Feb 20 13:33:38 That is the datasheet spec. stuff. Feb 20 13:34:22 red/green Feb 20 13:34:33 Oh. Feb 20 13:34:36 Hahhaha. Feb 20 13:34:41 I was wondering. Feb 20 13:35:12 anyway, in either case it's way more than 4 mA, so you're going to break the AM335x long before the LED, as I'd expect. digital outputs are not meant to drive significant amounts of continuous currents Feb 20 13:35:47 Oh. Okay. Feb 20 13:35:49 at least not on chips like the AM335x. some microcontrollers have more robust digital I/O Feb 20 13:36:08 Okay. So, a driver is needed as usual. Feb 20 13:36:39 LED driver? Feb 20 13:37:17 typically yes, which can be a transistor + a resistor (on the base), sometimes you can find these integrated Feb 20 13:37:34 Do not fret, breadboard to the rescue! Feb 20 13:37:43 you can use the digital outpput directly, but the led brightness will be limited Feb 20 13:37:58 Thank you again. Now, I must do my duty! bbl. Feb 20 13:38:01 it might still be plenty bright though, especially if you use a high-efficiency green led or something like that Feb 20 13:38:12 diffused! Feb 20 13:38:30 Milky, ohm. Feb 20 13:38:58 ideally one would use a constant-current driver for leds Feb 20 13:39:28 constant-current driver. Okay. Feb 20 13:40:12 bbl. Feb 20 13:40:58 (especially if you want consistency) Feb 20 13:41:18 but for a simple led, that is probably overkill Feb 20 13:41:45 it's more important if you're using like high-power leds Feb 20 13:46:54 m Feb 20 13:53:01 two question: if I don't use the ADC GND on a cape, should I tie it to the normal ground or leave it floating? Feb 20 13:54:12 if you're not using the ADC then it won't matter Feb 20 13:54:43 second: if a pin function is available according to config-pin (i.e. I can set the pin function as desired), that means I won't run into a conflict provided the rest of the pin configuration is already established, right? Feb 20 13:56:24 if you mean you're using the ADC then I'd tie ADC GND to whatever ground you're using for whatever is producing the analog signal, regardless of whether that's a separate ground plane or the same as the digital ground Feb 20 13:57:02 background, I have a display cape already connected but I need a few extra I/O lines and I'm trying to find them using config-pin Feb 20 13:57:31 a cape overlay will disable config-pin for all pins used Feb 20 13:57:39 excellent Feb 20 13:57:43 you can double-check this with my show-pins utility Feb 20 13:57:47 https://github.com/mvduin/bbb-pin-utils/#show-pins Feb 20 13:57:53 I think I have that already Feb 20 13:57:57 very handy little tool Feb 20 13:59:17 the last identifier on the line (in parentheses) is the pinmux node, from which you should be able to easily tell reconfigurable pins apart from fixed-function ones Feb 20 13:59:18 I'm mainly looking for a convenient to use pin given that I have a completely routed PCB and discovered now that I need an extra GPIO ... Feb 20 13:59:51 you're using a display cape and a custom pcb at the same time? Feb 20 13:59:56 yep Feb 20 14:00:02 the 4Dsystems cape Feb 20 14:00:04 with a pass-through or something like that? Feb 20 14:00:11 it has a pass-through Feb 20 14:00:15 ah Feb 20 14:00:30 wait, how? normally the led screen would be in the way Feb 20 14:00:40 unless you mean your custom pcb does Feb 20 14:00:40 no, it's flipped ;) Feb 20 14:00:45 they thought of that Feb 20 14:00:59 "flipped" ? Feb 20 14:01:20 they mirror the two sockets so that you can plug an extra cape like you would on the BBB directly Feb 20 14:01:35 like, pass-through would require both sides of the cape to be accessible... BBB on one side, a second cape on the other side Feb 20 14:02:19 it's a 7" screen, they have two sets of connectors side by side Feb 20 14:02:37 pin headers to plug the BBB and sockets to plug a cape Feb 20 14:02:39 ah, that... sounds great for integrity of high-speed signals Feb 20 14:02:46 hah, yes Feb 20 14:03:08 nice extra inductance an capacitance, ready to ring Feb 20 14:03:23 I hope they didn't pass through the eMMC or LCD signals :P Feb 20 14:03:30 I have no idea Feb 20 14:03:35 but the LCD works ;) Feb 20 14:03:53 anyway, to be really certain which pins you can freely use I'd definitely double-check the schematic Feb 20 14:03:55 and I'm adraid it's a parallel interface, too ;-D Feb 20 14:04:06 as opposed to what? Feb 20 14:04:33 hm, the BBB does feature DSI, no? Or only parallel RGB? Feb 20 14:04:40 only parallel RGB Feb 20 14:05:25 well, I didn't look at the layout yet. I guess it would not make sense for them to pass the LCD bus to the other sockets since they're anyway using it Feb 20 14:05:28 and DSI would be a far bigger headache for signal integrity probably, since it's very high speed but iirc still requires low skew between the lanes Feb 20 14:05:46 indeed Feb 20 14:05:58 EMI hell Feb 20 14:06:45 DSI is not differential, is it? Feb 20 14:07:11 it would be nice if they put small series resistors on the remaining pins (as close to the BBB as possible) before attaching a long trace to them to the other connector, but I guess that would be too much to ask for Feb 20 14:08:11 DSI is one differential clock lane + one or more differential data lanes Feb 20 14:08:26 (up to four data lanes) Feb 20 14:09:23 the physical layer is "D-PHY" Feb 20 14:12:10 hm, no layout for the display cape available but if I look at the prints they have on the website, they do pass the LCD bus over to the cape sockets and the resistors are, unfortunately, not near the BBB Feb 20 14:12:14 200 mV differential swing (nominal), source-synchronous clocking, dual data rate Feb 20 14:12:42 they placed them all close to the flex connector to the display... Feb 20 14:12:43 they have series resistors, but didn't place them near the BBB? but why? Feb 20 14:12:48 oh Feb 20 14:12:59 I was talking about the pass-through lines, not the LCD lines Feb 20 14:13:30 the flex cable probably has different characteristic impedance, so it makes sense then to place them there Feb 20 14:13:39 maybe... Feb 20 14:14:31 anyway, not my problem right now... Feb 20 14:14:53 indeed Feb 20 14:19:00 oh gross, D-PHY data lines aren't purely differential pairs... a bit like USB, they're differential during high-speed data transmission but used in a weird single-ended way during low-speed/low-power signalling... Feb 20 14:19:18 (page 10 of http://rfmw.em.keysight.com/mod/pdf/axie_u4421a_mipi_d-phy_protocol_fundamentals_detailed_presentation.pdf ) Feb 20 14:21:13 found the schematics. they don't pass LCD over to the cape sockets. Feb 20 14:26:50 goh! Feb 20 14:27:09 they killed SPI1! bastards! Feb 20 14:28:54 surely they could have used another GPIO than GPIO1_19 for a stupid pushbutton... Feb 20 14:29:49 gpio1_19 is P9.16 which has no spi functionality Feb 20 14:30:54 spi1 requires P9.29/30/31 which isn't claimed by any of BB-BONE-4D*.dts Feb 20 14:37:25 gpio1_19 should have SPI1_D1 if I'm not mistaken. Feb 20 14:37:37 you are mistaken Feb 20 14:38:35 spi1 clk/miso/mosi is P9.31/29/30, pin index 100/101/102, gpio 3.14/15/16 Feb 20 14:40:21 is this a different cape than any of BB-BONE-4D*.dts ? (you just said "4D systems" so I assumed it's one of those) Feb 20 14:41:51 none of those even seem to have a button: https://pastebin.com/raw/AS6szQw2 Feb 20 14:44:22 checking... Feb 20 14:47:12 it's 3_16 :-( Feb 20 14:47:32 they use 3_16, which is SPI1_D1 :-( Feb 20 14:47:49 which cape is this then? Feb 20 14:47:54 which overlay? Feb 20 14:48:05 4DCAPE-70T, don't know which overlay. I was going by the schematics Feb 20 14:49:52 afk... Feb 20 14:52:06 I mean, the simple solution is to just not that button :) Feb 20 14:52:40 and add a patch wire to the passthrough header Feb 20 14:52:57 or much easier, just use spi0 Feb 20 14:53:19 oh Feb 20 14:53:25 they're using that too Feb 20 14:54:20 getting in the way of both spi buses seems a bit unnecessary Feb 20 14:55:34 oh god, and they're passing through the pins used for eMMC... I'm kinda surprised they're not ruining eMMC signal integrity with that Feb 20 15:01:17 integrity, What integrity!? lol Feb 20 15:28:48 Hey everyone. Any one here famailiar with the BB Blue? Feb 20 15:30:41 if you have a question, just ask it and have patience. there's plenty of knowledgable people in chat, but many might be in different timezones or just glance at chat occasionally, since it can take time to get a response. Feb 20 15:31:00 *so it can take time to get a response Feb 20 15:46:46 Hi everyone. I have a beaglebone enhanced V1G. I was just writing some code and it turned off on me. It now will not turn back on. When I plug it in one LED on the USB1 side of the ethernet jack lights for a split second and then goes dark and nothing else happens Feb 20 15:47:05 have any of you experienced this before? and maybe know a solution? Feb 20 15:47:19 I tried to take the SD card I have out and boot it without that. same issue Feb 20 15:47:57 sounds like the hardware somehow got damaged. did you have anything connected on the expansion headers? Feb 20 15:49:51 (the power led blip of doom indicates a short-circuit. assuming there's no external connections that can explain this short-circuit, the most common cause is an internal short inside the SoC caused by an I/O cell damaged by overvoltage or overcurrent) Feb 20 15:51:03 I hadn't hooked any gpio or anything of that nature up yet. I was just developing code. Feb 20 15:51:22 that sounds quite mysterious Feb 20 15:51:42 I was remote ssh'ed over the mini usb and powering it over the 5v plug Feb 20 15:52:06 I just bought the darn thing and I don't have the time to wait for another one to come in.. Feb 20 15:53:10 that sucks Feb 20 15:53:24 you should definitely try contacting SanCloud about this I think Feb 20 15:53:42 (who designed the BBE) Feb 20 15:53:58 Okay thank you Feb 20 16:59:15 zmatt: patch wire sounds like the best solution to me. Feb 20 16:59:43 zmatt: they're really arsing around with IOs just to have a too many buttons on the display Feb 20 17:01:01 or I ditch the display... Feb 20 17:02:02 the display is NRND Feb 20 17:02:07 the cape I mean Feb 20 17:02:09 yep Feb 20 17:02:17 but I have it... Feb 20 17:02:31 patch wire it is Feb 20 17:02:46 yep, then just patch it :) Feb 20 19:32:24 Hi there. I have a beaglebone question. My Enhanced V1G has a weird SPI issue. I am trying to drive stepper motors using a driver that communicates with the bone via SPI. my beagle bone has been configured to utilized both SPI busses on boot. However the operating system isnt exposing them Feb 20 19:32:44 and my C++ code errors out with an open bus error Feb 20 19:32:58 any ideas perhaps on why my spi busses dont show up Feb 20 19:33:00 ? Feb 20 19:33:30 Hello. Feb 20 19:33:42 I actually switched my SD card from one enhanced to this one. the previous enhanced had no issues but this one does Feb 20 19:33:51 Hmm. Feb 20 19:33:57 Did you try config-pin? Feb 20 19:34:02 yes Feb 20 19:34:14 Oh. Are you using all four wires for spi? Feb 20 19:34:20 but I need these to boot that way without having to config-pin Feb 20 19:34:26 yes all four Feb 20 19:34:27 Oh. Feb 20 19:34:28 Okay. Feb 20 19:35:04 So, use a .sh script and a .service if necessary. But...you can also make a .dts file. Feb 20 19:35:40 So, you have an Enhanced BBB that may have a different set of pins already set up for use. Feb 20 19:35:43 well right now I am just developing code so I haven't done anything but ssh into the BB and configure the Uboot Feb 20 19:35:51 Oh. Feb 20 19:36:15 John2424: I usually do not mess w/ u-boot stuff. If it is about u-boot, you may have to wait for another person. Feb 20 19:36:32 on my other BB i have done the same thing and both SPIDEV1.0 and SPIDEV2.0 are enabled on boot Feb 20 19:36:40 Nice. Feb 20 19:36:52 this one not so much for some reason Feb 20 19:36:54 I have done it once w/ SPI. So, did you check your image? Feb 20 19:37:12 uname -a && cat /etc/dogtag Feb 20 19:38:29 John2424: Use that command and please print out your console reference. Feb 20 19:38:59 I talk funny. Sorry. whatever the console reads back, please print it here. Feb 20 19:39:14 Linux beaglebone 4.14.108-ti-r113 #1 SMP PREEMPT Wed Jul 31 00:01:10 UTC 2019 armv7l GNU/Linux Feb 20 19:39:27 what about cat /etc/dogtag? Feb 20 19:39:38 Oh. Feb 20 19:39:39 Okay. Feb 20 19:39:44 I got it now. Feb 20 19:39:45 Hmm. Feb 20 19:40:03 Do you have the updated image already from their site or are you making your own image? Feb 20 19:40:09 the beagle bone that was working well with respect to the spi communication died this morning for no reason Feb 20 19:40:16 Odd. Feb 20 19:40:20 no this is the updated image Feb 20 19:40:24 Okay. Feb 20 19:41:15 Do you have a wiring diagram? Let me tell you something up front. I am not magician but I may be able to help. Feb 20 19:41:50 what type of wiring diagram are you looking for? Feb 20 19:42:30 Just sensors/actuators to specific pins, SPI, that accept 3.1v in/out, can lead to issues if incorrectly wired. Feb 20 19:42:34 Any. Feb 20 19:42:43 If you have a diagram of what you are doing, post it. Feb 20 19:42:59 If I cannot provide support, there are a ton of people here that can help you. Feb 20 19:43:43 John2424: Have you ever used MRAA/UPM w/ the BBB? Feb 20 19:45:30 I ask b/c I am trying to add-apt-repository ppa:mraa/mraa and I am denied access. Feb 20 19:45:31 John2424: you're saying you had your spi buses show up on one BBE but not the other? Feb 20 19:45:46 you mean the spidev devices I presume? Feb 20 19:46:06 yeah zmatt Feb 20 19:46:06 exactly Feb 20 19:46:57 this is almost certainly caused by a difference in bootloader... by default a beaglebone will load the bootloader (u-boot) from eMMC, and a serious version incompatibility between that and the sd card you're booting from could cause all sorts of trouble, especially of the sort you're describing Feb 20 19:47:08 the solution would be to either reflash eMMC or simply wipe it Feb 20 19:47:09 one board the spi communication was perfect on boot. I just had to open the channels in code. That board died (My co-worker talked with you about it this morning) and I pulled my SD card and put it in the other BBE and this is now my problem Feb 20 19:47:44 if no bootloader is detected on eMMC, bootrom will fall back to loading it from SD card Feb 20 19:48:05 could you help me to do this then? Feb 20 19:48:21 I know. Back-up your eMMC and then discard it. Feb 20 19:48:55 I have done that before too. This is what he is decribing. Feb 20 19:48:56 wiping eMMC is easy: sudo blkdiscard /dev/mmcblk1 ... maybe just to be sure double-check that /dev/mmcblk1 isn't somehow the sd card: use "findmnt /" to verify what you're currently booting from Feb 20 19:49:46 or check that /dev/mmcblk1rpmb exists (it only exists for eMMC, not for SD cards) Feb 20 19:50:04 after checking first, here is the result: Feb 20 19:50:05 TARGET SOURCE FSTYPE OPTIONS Feb 20 19:50:14 you can't paste multiline stuff into chat Feb 20 19:50:26 it doesn't work (and it would be spammy if it did) Feb 20 19:50:31 TARGET SOURCE FSTYPE OPTIONS Feb 20 19:50:54 you just pasted the first line of the output Feb 20 19:51:09 anyway, SOURCE should show /dev/mmcblk0p1 if you're booting from SD card Feb 20 19:51:21 dev/mmcblk0p1 ext4 rw,noatime,errors=remount-ro,data=ordered Feb 20 19:51:27 thats the second line Feb 20 19:51:36 i am no linux wizard Feb 20 19:51:39 so indeed, mmcblk0 is sd card, mmcblk1 will be eMMC (which is how it always is) Feb 20 19:51:42 just trying to write code Feb 20 19:51:52 okay good Feb 20 19:51:59 so sudo blkdiscard /dev/mmcblk1 will wipe eMMC Feb 20 19:52:06 okay one sec Feb 20 19:52:17 So, has anyone used MRAA/UPM on the BBB recently? Feb 20 19:52:38 it's always good to double-check such things to make sure you don't accidently wipe your SD card ;) (linux commandline tools do not have a habit of asking "are you sure?") Feb 20 19:52:55 That is the truth! Feb 20 19:52:57 okay let me try this now Feb 20 19:53:04 thank you for the help guys Feb 20 19:53:19 and definitely a good call on checking first Feb 20 19:53:22 John2424: note that booting from eMMC is generally preferred over SD card, it can be up to twice as fast Feb 20 19:54:28 (and the reliability of consumer SD cards can be expected to be considerably worse than that of eMMC) Feb 20 19:54:47 well regardless I am still having the spi open bus error Feb 20 19:55:17 open device I assume you mean? (you can't "open" an spi bus) Feb 20 19:55:28 yeah Feb 20 19:55:33 so I take it /dev/spidev* do not exist? Feb 20 19:55:41 it cant find either of my motor drivers Feb 20 19:55:58 oh just to clarify, you rebooted after wiping eMMC ? Feb 20 19:56:03 that says no such file or directory Feb 20 19:56:11 which the other didnt do Feb 20 19:56:15 it showed the four options Feb 20 19:56:19 reboot! Feb 20 19:56:24 oh Feb 20 19:56:27 lol Feb 20 19:56:30 let me reboot Feb 20 19:56:35 Yea boy! Feb 20 19:56:41 the whole thing was about a bootloader... which is only involved when booting ;) Feb 20 19:56:59 That "pesky" eMMC! Feb 20 19:57:20 i accept the title of idiot on that one lol Feb 20 19:57:23 nothing pesky about eMMC Feb 20 19:57:28 lay it on me haha Feb 20 19:57:40 though I'm not a fan of the default boot script Feb 20 19:57:56 it would be better if it didn't attempt to load linux from a different device than the one where u-boot was loaded from Feb 20 19:58:28 I know. I am highlighting the pesky eMMC as "pesky" eMMC for a reason. I was joking w/ you. Feb 20 19:59:35 Okay. Sorry anyway for chatting while you two get down to business. Feb 20 19:59:54 MRAA/UPM? Anyone? Feb 20 20:00:20 set_: why are you asking about it? Feb 20 20:00:52 oh it actually supports bbb... I've honestly never heard of it before today Feb 20 20:01:04 SPI issue looks to be solved Feb 20 20:01:38 next set of errors to look into... Feb 20 20:01:42 thanks though guys Feb 20 20:03:09 actually doing /dev/spidev* still doesnt return right Feb 20 20:03:15 set_: it doesn't look confidence-inspiring... they claim bbb support but have no instructions for debian, the node bindings apparently only work for node 6 and older (which is extremely outdated) Feb 20 20:03:16 it now says this Feb 20 20:03:26 sudo: /dev/spidev1.0: command not found Feb 20 20:03:31 John2424: ls /dev/spidev* Feb 20 20:03:35 you forgot the ls Feb 20 20:03:54 there they are Feb 20 20:04:09 awesome thanks guys Feb 20 20:04:17 Right. Feb 20 20:04:31 note that if your system is reasonably uptodate, it should also have symlinks in /dev/spi/ that actually use the correct spi bus numbering (i.e. spi0 cs0 is /dev/spi/0.0 which makes a lot more sense than /dev/spidev1.0) Feb 20 20:04:40 I am getting the feeling that MRAA is no longer supported on these boards. Feb 20 20:05:30 set_: the beaglebone page in the docs is talking about kernel 3.8 Feb 20 20:05:39 so yeah, I wouldn't touch this with a ten foot pole Feb 20 20:06:12 Fine. Sheesh. I used to try years ago but never could get it to work b/c of the add-apt-repository command. Feb 20 20:06:24 I think it is an Ubuntu thing. Feb 20 20:06:53 even if you could get it installed, it would almost certainly not work Feb 20 20:07:01 Okay. No issue. Feb 20 20:07:04 Moving on. Feb 20 20:22:50 bbl! Almost helping is as fruitful as helping. I tried. Feb 20 21:30:12 zmatt Yeah that strangeness with the spi port numbering was something someone who writes BASIC code would do (joke) Feb 20 21:31:46 GenTooMan: it was originally caused by a kernel driver bug/misfeature, the omap2-mcspi driver used to assign sequential 1-based bus numbers (using a static global variable with no mutex protecting it, I'm puzzled how that managed to get accepted in the kernel) Feb 20 21:32:19 but after that was fixed, it was found that software relied on the wrong numbering, so now it's maintained (via DT) for bugwards compatibility Feb 20 21:32:47 aka "deprecated" but not removed Feb 20 21:33:37 well there's nothing to deprecate... any code that uses hardcoded /dev/spidev* paths will inevitably break if you change the number assignment Feb 20 21:33:57 that's why, at my suggestion, an udev rule was added that creates new symlinks Feb 20 21:34:37 these are the lines responsible for perpetuating the wrong numbering: https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.14.108-ti-r120/arch/arm/boot/dts/am33xx.dtsi#L39-L40 Feb 20 22:45:49 Well I am careful to the point of parinoia about such things, but truth be told it's often worse to "fix" something that just looks wrong instead of just adding a "correct" interface and leaving what was before alone. Feb 20 22:51:54 I mean, it was and is wrong, and the software that depended on it was doubly wrong because the numbering wasn't fixed to begin with (the kernel would just sequentially assign numbers as it encounted the spi controllers, so if you had only one of the two enabled it used to be bus 1 regardless of which one it was) Feb 20 22:52:36 but I also understand wanting to minimize software breakage, even if it's due to software relying on stuff it never should have relied on Feb 20 22:54:01 the symlinks are an okayish compromise, although there are spi libraries which don't accept paths but only bus number and chip select number, which therefore currently still require the user to specify an off-by-one bus number to get them to work Feb 20 22:54:29 (and such software then subsequently becomes software that relies on this wrong bus numbering, argh) Feb 20 22:56:09 but I'm personally not affected by it anyway, since 1. my DTs don't include this hack 2. I declare my SPI devices in DT and assign meaningful names, and userspace software opens e.g. "/dev/spi/dsp" and doesn't need to know or care which spi bus/cs that is Feb 20 22:58:01 Hmm if this were a Microsoft product one would stubbornly cling to the wrong nomenclature and say "everyone else is wrong". I noticed the strange naming and was genuinely confused by it, however I worked around it without using stupid. Feb 20 23:02:56 by the way thanks for the tip on setting up the GPIO pins in python, that is much cleaner than using a bash script and the command line (too me at least). Feb 20 23:03:53 pinmux you mean? Feb 20 23:04:19 of course doing it in DT is still superior, but that's just my opinion :) Feb 20 23:07:24 yes setting the pinmux, unfortunately I am uncertain the __del__ method is being called when the class is being destructed, however that's not your problem. I suppose I ought to look at using the device tree for that sometime. Feb 20 23:16:27 hmm? Feb 20 23:16:35 the __del__ method of what class? Feb 20 23:17:12 and I mean, __del__ is called when the object is (about to be) garbage-collected... there's not that much to it Feb 20 23:30:44 I'll just mutter about python being a bit too loose and fast with how it does things. When the program closes I wanted to free the pinmux settings to what they were before they were changed is all. Feb 20 23:31:27 I set up classes to handle the LCD control so when the LCD class went away the pin mux could be restored. At least that was the idea. Feb 20 23:31:29 I don't think destructors are guaranteed to be called on interpreter exit Feb 20 23:31:40 it sounds kind of inappropriate to do this though Feb 20 23:32:06 now that I think about it, it's probably not necessary Feb 20 23:32:07 like, normally the hardware attached to the BBB doesn't magically change because your program exited, hence neither should the pinmux Feb 20 23:34:04 typically pinmux ought to be setup as part of device initialization during boot... doing it at runtime is mostly a hack that exists because DTs scare people ;) Feb 20 23:46:30 well if one is adding a cape then DT is necessary. I'll have to check if one can load modules based on the information on the cape. IE a cape can load a linux module with PRU support to efficiently handle controlling a specific device. Feb 20 23:50:51 a cape just contains an identifier that names the overlay that u-boot will load Feb 20 23:51:50 and not all capes have one, some of the newer ones don't have any overlay (yet) hence you still have to setup pins with config-pin to use them Feb 20 23:52:02 I guess some older ones now that I think about it Feb 21 00:04:31 well just setting up the pinmux would help, however it would be handy to be able to load a module also for the device. I'll have to look at the PRU more, as soon as I find that LCD I thought I had. Feb 21 00:04:59 LCD connected to the PRU? Feb 21 00:05:13 GenTooMan: define "module" Feb 21 00:05:34 zmatt loadable module / device driver Feb 21 00:06:02 GenTooMan: DT declares devices, the kernel automatically loads their drivers Feb 21 00:06:25 DT isn't just pinmux Feb 21 00:07:25 ds2 that's a later project, to the McSPI I can't verify my code with a dead LCD and I don't want to take apart the device with the one that works I was thinking of handling LCD commands from the PRU via the processor. Feb 21 00:08:30 cape overlays don't merely enable/configure existing devices or set up pinmux, they frequently add new devices too Feb 21 00:09:10 GenTooMan: what's the resolution? Feb 21 00:09:22 (which will cause modules to be loaded if necessary) Feb 21 00:09:41 zmatt I guess I'll have to look into that sometime too. Feb 21 00:09:58 GenTooMan: I mean, that's what DT is Feb 21 00:10:25 what it does I should say... what it is is just a simple tree-like data structure Feb 21 00:14:31 ds2 320x240 SPI LCD just my idea for experimenting with the PRU to see what I can make it do. I was thinking of abusing the FB to output data to the small LCD via the PRU eventually. Feb 21 00:15:37 monochrome? Feb 21 00:16:27 GenTooMan: where are you find them (at a reasonable price and available in singles)? Feb 21 00:16:52 isn't there a driver that handles those? Feb 21 00:17:02 decendant of the fbtft stuff or similar Feb 21 00:17:32 there definitely is for a bunch of 'em... Feb 21 00:18:41 tiny little ones... lower res Feb 21 00:30:30 ds2 hmmm I am in the US so prices may vary DisplayTech has some ones based on the ILI9341 full color, 2.2" 2.4" and 2.8" with some variations. You can drive the ILI9341 with several different bus types. SPI 9/8 word 3/4 line options. Feb 21 00:31:29 of course the 16 line parallel too with H and V sync but I've been using it with SPI mostly. Feb 21 00:38:24 that size... thought you had some 4" or more Feb 21 00:38:41 parallel is trivial to find...well, sort of Feb 21 00:45:07 the cheapest DT 800x480 7" is $64 us 58 EU however the 1024x600 ones are cheaper but resolution has it's price. Feb 21 00:46:08 but are those parallel or SPI? Feb 21 00:48:42 parallel Feb 21 00:49:40 those are easy to get... 800x480 7" in sub $10 w/SPI interface is the stuff that would be fun to get Feb 21 00:54:04 the SPI ones are more flexible that's for certain. Feb 21 00:56:12 no, parallel is more flexible... the SPI ones are suppose to be dirt cheap Feb 21 00:57:29 we each have different experiences, but being able to connect it to 16 or more different types of buses is my idea of flexibility. Feb 21 01:00:04 ah Feb 21 01:00:18 being able to push the display to do exactly what is desired is mine Feb 21 01:20:40 different goals I guess :D Feb 21 01:26:02 parallel interfaces are pretty universal... SPI interfaces are all over the place Feb 21 01:29:18 configuration is different depending on the controller on the target Feb 21 01:57:31 anyhow I need to look for some replacement... **** ENDING LOGGING AT Fri Feb 21 02:59:57 2020