**** BEGIN LOGGING AT Fri Oct 04 03:02:52 2019 Oct 04 07:10:18 hey zmatt, thanks for your help eariler in the week Oct 04 08:40:11 i (only lately) had a recurring (1 out of 4-5 boots) problem with ethernet phy not initialising at boot on bbbs. i then came up to this: https://wp.josh.com/2018/06/04/a-software-only-solution-to-the-vexing-beagle-bone-black-phy-issue/ . it sounds quite weird to me because i have dozens of bbbs out in the world (literally) almost unattended and didn't spot that very issue until few days ago. is it really of concern or have i just been lucky until now Oct 04 09:05:59 samael: the phy issue is real unfortunately. I'm pretty sure josh's "software only workaround" is a recipe for hardware damage Oct 04 09:07:54 thats a bit of an 'annoying' issue Oct 04 09:08:18 yes it is Oct 04 09:08:54 it should be quite rare in practice though... 1 in 4-5 sounds very dod Oct 04 09:08:57 *odd Oct 04 09:11:16 does it impact on Beagle Greens? Oct 04 09:12:54 an idea I've had to work around it is by using an external reset extender to keep the reset low a bit longer after power-on, preferably with some added pull-up to make it rise faster afterwards (although unfortunately not much pull-up can be added without potentially causing too much current when the PMIC is holding reset low) Oct 04 09:13:11 the green does not fix any of the BBB's issues Oct 04 09:13:26 it's been quite rare for me indeed, to the point that i had no complaints (probably it happens sometimes but so rarely that the client just try a cold reboot by itself and everything comes up again). it is worth noting that almost half of the bbb i have in the wild are cape powered, which seems to increase the probability, nonetheless i survived until today. Oct 04 09:14:01 zmatt: why are you saying that such software workaround is riskful for the hardware? Oct 04 09:14:47 interesting.. i'm about to think about deplolying 600 of these... Oct 04 09:15:02 my bbg are not using ethernet. Oct 04 09:15:09 wifi.. Oct 04 09:17:15 because it's entering the defeatured RTC-only mode (which causes suspicious current flow in the am335x) which also triggers the 3.3v regulator bug so vdd_3v3b remains active while vdd_3v3a is powered off, creating excellent opportunity for damaging I/O cells Oct 04 09:19:07 i see, thanks. the main question would still be why this did not get addressed by a hardware revision, being it well known since longtime. but i think there are reasons for that Oct 04 09:19:17 I do not know Oct 04 09:19:55 the easy and proper fix would have been to use a spare gpio for the ethernet phy reset, but none may have been available Oct 04 09:22:03 seems like the easiest way could be the hardware fix suggested on that page: "use a custom cape or wire jumper to connect the header reset pin to a GPIO pin so you can make the board reset itself under software control." Oct 04 09:24:36 does that actually work? it sounds iffy to me since it'll stop pulling reset down the moment the chip goes into reset, so you'd get that it will go low very briefly and marginally, and whether or not it'll reset the phy will depend on the input switching level of the phy's reset pin compared to that of the am335x's reset pin Oct 04 09:27:55 i don't really know if that would actually work. that's why i'm asking. :) for sure i can't use these BBBs of any real purpose so i need to solve it in some way. Oct 04 09:28:49 I hope the reset extender trick works... it's in our current hw design, but still needs to be tested Oct 04 09:29:23 and we plan to move away from the bbb and use a custom osd335x-based design at some point in the future Oct 04 09:31:10 unfortunately i have no such choice (if bbb does not fit, i have to opt for other ready boards) Oct 04 09:32:23 i'll be able to use the green, because i dont' need ethernet Oct 04 09:33:14 if you don't need ethernet then obviously there's no problem (black vs green doesn't matter) Oct 04 09:38:12 is this issue addressed on the AI? Oct 04 09:38:46 nothing on the AI even remotely resembles the BBB, so I expect no overlap between BBB issues and BBAI issues Oct 04 09:40:18 it has a different pmic, different power-up timing, different ethernet phy Oct 04 09:41:54 hmm, there's a comment on josh's page with an interesting analysis Oct 04 09:42:38 good to know (although there will be new bugs and flaws for sure :)) Oct 04 09:44:22 suggesting that the problem is that the resistor between ethernet shield and digital ground may get destroyed (due to ground potential differences), causing the REGOFF pin to become highly susceptible to pick up noise/EMI due to capacitvely coupling to the ethernet shield Oct 04 09:45:58 it might be interesting to measure R136 (i.e. the resistence between ethernet shield and digital ground) on your affected BBB to see if this is also gone in your case Oct 04 09:47:11 I'm pretty sure we've seen this issue without putting a BBB in the sort of situation that creates the opportunity to induce current flow between ethernet shield and digital ground Oct 04 09:47:38 i'm not an hardware expert and probably don't have all the right instruments, but i do have a tester and i can try to if properly guided Oct 04 09:47:57 you don't have a multimeter lying around? :P Oct 04 09:48:02 first off, where can i find the position of that resistor on the board? Oct 04 09:48:13 just measure between ethernet shield and BBB ground Oct 04 09:48:19 no need to hunt for the resistor Oct 04 09:48:33 oh, that way seems easy :D Oct 04 09:49:15 should i do that while the board is on but the phy is not correctly initialized? i guess it doesn't really matter (if the resistor is gone, it's gone!) Oct 04 09:50:18 it shouldn't matter whether the board is on or not, but it should be tested without any ethernet cable inserted preferably (definitely not a shielded one) Oct 04 09:50:43 testing it with the board unplugged and unpowered seems like the safest option Oct 04 09:51:39 usb should definitely not be connected Oct 04 09:54:53 the REGOFF pin also doesn't have a separate pull-down resistor (relying instead on the internal pull-down in the PHY) ... probably also not a great idea Oct 04 09:57:26 jkridner: why was this issue never properly solved? even if rare, occasionally having no working ethernet (requiring power-cycling or manual reset to fix) really sucks pretty hard Oct 04 09:59:35 zmatt: https://imgur.com/a/51KZRA0 Oct 04 10:00:58 why are you linking to an image instead uf just saying "I measure 0.6 ohm resistance, so the resistor seems to be fine here" :P Oct 04 10:04:40 so yeah I can imagine that getting the shield-ground connection destroyed will make matters worse, but it's not a prerequisite Oct 04 10:04:44 although extremely simple, i wanted to show the entire setup to be sure of its correctness :D Oct 04 10:04:53 fair Oct 04 10:19:52 eventually it's not entirely clear to me if a cold-reset of the board would actually solve the problem 100% of the times (without rebooting multiple times until it goes up by pure luck, i mean) Oct 04 10:20:42 well it's rare enough that just retrying seems like a functional workaround Oct 04 10:29:39 i almost always have a plc around the bbb, they usually communicate via ethernet connection which i obviously cannot use in such case, but i could think about some serial or gpio-based communication to make the plc manage a controlled cold reset using a relay and properly halt the board in the meanwhile Oct 04 10:30:27 it still seems too much of a hassle, though Oct 04 10:31:29 it could also pull reset to ground for long enough, or use the power button pin to power cycle the board Oct 04 10:31:39 (reset seems like the best option) Oct 04 10:32:29 using the reset line (rather than power cycling) should also ensure you only have to do it once Oct 04 10:33:20 good point. after reading so much forum posts and comments, i was quite confused about that Oct 04 10:33:50 in fact you could just do it preemptively: e.g. have it pull reset low for a while on power-up Oct 04 10:34:26 which is basically the same solution as we've come up with (except we use a voltage supervisor IC) ... like I said, we haven't yet tested it Oct 04 10:35:08 so to sum up, using a relay to link SYS_RESET_N and DGND would be the best solution, correct? Oct 04 10:37:16 a relay sounds odd to me because i'm used to external logic already interfacing via digital logic with the BBB, but it sounds like your PLC is basically isolated from the BBB, so yeah then I guess a relay makes sense :P Oct 04 10:42:30 though I'm not sure why that would be an acceptable solution when using an external voltage supervisor (which basically just means one IC connecting to GND, 3V3, and reset) is not Oct 04 10:57:53 plcs work at 24V, there's no easy direct interaction with bbb signals. the latter solution you suggest would probably be better, but i'm not proficient with electronics while plenty of us actually are with plcs, so i tend to prefer walking on a well known path :) Oct 04 11:00:10 although given the amount of time and hassle required by both solutions, they are probably not worth: i often can just use different boards which costs a little bit more, and that's it Oct 04 11:00:57 if you don't need any particular feature of the BBB then there are lots of options, probably many of which better or lower-priced than the BBB Oct 04 11:02:02 it sounds like you basically just need "some small linux system with an ethernet port" ... which doesn't exactly constrain much :P Oct 04 11:05:08 let's say BBBs are a good platform for my lower-end projects, but a higher speed CPU would be much appreciated. i'm about to test BB-AI and i can't wait to evaluate it Oct 04 11:11:07 Hi, I am using BBBW/BBB. How do i find name of the board using shell script? Oct 04 11:12:46 Raj16: sudo /opt/scripts/tools/version.sh would probably show what you need. you can also use its code as an example Oct 04 11:12:49 read model puts the model in $model Oct 04 11:14:22 Thanks Oct 04 11:14:27 oh never mind, that doesn't split on NUL-byte Oct 04 11:14:28 zmatt Oct 04 11:14:45 there might be a way to do it with pure shell script Oct 04 11:16:18 this /proc/device-tree/model works ok. Thanks. **** BEGIN LOGGING AT Fri Oct 04 13:15:59 2019 Oct 04 13:35:09 Hi, I'm looking for a way to dynamicly load device tree overlay. Oct 04 13:35:22 I found cape manager, and a link to a old repository (5 years at least) Oct 04 13:35:27 https://elinux.org/Capemgr and https://github.com/beagleboard/kernel/tree/3.8 Oct 04 13:35:36 I was wandering if anyone know about it. Is it upstream in the mainline kernel ? Oct 04 13:35:45 Is it possible to use this mechanism with an other board ? Oct 04 13:36:03 notoriousPig: it's in rcn's 3.8 kernels and I think it might still be supported in current 4.x kernels, but it never reached mainline, has always been buggy, is deprecated, and will be removed in the future Oct 04 13:36:10 there's nothing board-specific about it Oct 04 13:36:32 Okay, thanks for the quickness zmatt =D Oct 04 13:36:44 Do you know some alternatives if it's buggy ? Oct 04 13:36:48 basically the kernel just doesn't expect the DT to change at runtime, and too much stuff breaks when it does Oct 04 13:37:06 that depends on why you want to dynamically load an overlay... generally speaking, hardware doesn't change dynamically Oct 04 13:37:21 Okay, let me explain =D Oct 04 13:37:59 I wish I could at boot time detect what kind of cape/hat is plug on my board and load the good device tree overlay. Oct 04 13:38:10 I use u-boot as bootloader Oct 04 13:38:39 that should work out of the box Oct 04 13:38:59 current u-boot includes cape autodetection and applies DT overlays before passing it to the kernel Oct 04 13:39:32 if you use a recent image from https://beagleboard.org/latest-images that should just work Oct 04 13:43:22 Really ?! Fc*k I didn't knew that ... Is this mechanism board-specific ? We can switch on DM if you prefer. Oct 04 13:43:53 I will dig in u-boot anyway =D Thanks Oct 04 13:44:35 it is somewhat... the notion of capes are beaglebone-specific in the sense that it defines the physical headers to use, which pins are used for the i2c bus, which i2c addresses are scanned for cape eeproms, and what the format of that eeprom is Oct 04 13:44:58 the u-boot overlays code itself isn't board-specific, although I'm not sure if it's in mainline yet Oct 04 13:46:01 and no please don't send private messages Oct 04 13:46:59 No problem, I asked because my question is not really beaglebone-specific. I prefer not `spamming` the channel with it. Oct 04 13:48:21 https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2019.04/0002-U-Boot-BeagleBone-Cape-Manager.patch this is the patch that adds cape autodetection Oct 04 13:48:47 Already found it ;] Oct 04 13:48:51 ok! Oct 04 13:49:25 I'm unfortunately a bit too used to people having seemingly little or no capacity to google shit for themselves Oct 04 13:50:56 I'm doing lot of OSINT, so I know my search engine. I like lmgtfy-ing people (it's old but I still really like it) Oct 04 13:51:24 :D Oct 04 13:56:54 Okay, I think my best shot is to use this mechanism. It look pretty complexe to add my own configuration but it does exactly what I want to achieve. Oct 04 13:57:17 Do you have some developper feedback on u-boot overlay ? Oct 04 13:57:26 ? Oct 04 13:57:59 Do you ever add your own overlay for this mechanism ? Oct 04 13:58:14 s/for/on Oct 04 13:58:17 if it is necessary to autodetect platform devices (which are normally intrinsically not autodetectable) then u-boot is the right place to do so Oct 04 13:59:05 no I've had no need for it, we just have a single monolithic DT per device (by which I mean BBB + external hardware) Oct 04 13:59:29 also my god C++ is such a horrific mess sometimes... https://youtu.be/IAdLwUXRUvg?t=871 Oct 04 14:03:02 Yep, okay. Thanks a lot zmatt. You helped me a lot. Oct 04 14:03:32 I'll watch this alu-guy later xP Oct 04 14:07:12 basically in current C++ there's no way to construct an array of objects in a buffer you allocated that's guaranteed to work by the standard.. as far as the speaker could figure out, all options are either non-portable or result in undefined behaviour Oct 04 14:09:46 (I suspect using array = std::launder((T*)buffer) will work in practice but I don't actually know what the standard's opinion is on this...) Oct 04 14:10:00 (after constructing the element individually that is) Oct 04 14:10:03 elements Oct 04 14:10:06 typing is hard -.- Oct 04 14:25:58 zmatt yes C++ is a big mess these days. All due to "I can fix my problem" vs "Are you solving a real problem" issues. I am dismayed how easily we people can get caught up in solving unnecessary problems, instead of solving necessary ones. Oct 04 14:26:55 in this case it's just that placement new for arrays is specified with a certain freedom that ends up making it completely useless, and I think this was done just to accomodate MSVC but I'm not sure **** BEGIN LOGGING AT Fri Oct 04 14:38:48 2019 Oct 04 16:52:36 Hi, I want to show a tty on a spi lcd screen on my PocketBeagle using Debian. However the /dev/fb* files are missing and I can't find any way to get a framebuffer running. I already tried to modprobe a few fb-related modules such as fbtft, to add myself to the video group and I even tried to install xorg. However none of these gave me a /dev/fb0 Oct 04 16:52:36 file to use. Does anyone know what I should try ? Thanks in advance Oct 04 16:54:45 To be more precise I'm using the Debian IoT image Oct 04 17:15:54 maxime: you're not going to magically get an fb0 device just by modprobing a kernel module Oct 04 17:16:43 you'd either need to specify the correct parameters to the fbtft_device driver or use an overlay Oct 04 17:17:02 see for example the fbtft-adafruit18 example in https://github.com/mvduin/overlay-utils Oct 04 17:42:54 Thanks, however I don't quite get everything. From what I understand following this https://github.com/notro/fbtft/wiki/BeagleBone-Black I should be able to get an fb0 right ? Then will I be able to change the resolution & depth via fbset or is it fixed in the drivers ? Oct 04 17:48:18 once you've created the appropriate device it will appear as /dev/fb0 or /dev/fb1 yes (dunno which) Oct 04 17:48:26 note that a lot of info on that page appears to be old Oct 04 17:48:50 width/height has defaults in the driver and can be overridden Oct 04 17:49:35 what spi lcd screen are you using? Oct 04 17:52:00 (can be overridden using module parameters or DT I mean, I'd guess not via fbset but I'm not sure) Oct 04 17:52:39 ok great, could you point me to infos on how to overwrite via those methods ? Oct 04 17:52:47 I'm using this screen Oct 04 17:52:47 https://www.sharpsma.com/products?sharpCategory=Memory%20LCD&p_p_parallel=0&sharpProductRecordId=1504547 Oct 04 17:53:00 Maybe two of them if I get one working Oct 04 17:54:07 this doesn't specify any useful information Oct 04 17:54:36 to configure an spi display you need to know what display controller IC it uses Oct 04 18:00:19 without additional documentation the display is pretty much a paperweight Oct 04 18:03:11 maybe here https://media.digikey.com/pdf/Data%20Sheets/Sharp%20PDFs/LS044Q7DH01.pdf digikey has the data sheet it has enough to do something with the device. Oct 04 18:03:41 why don't manufacturers have that on their product page -.- Oct 04 18:04:41 Yeah sorry ! I have the datasheet here, however there's no controller IC specified, but there is enought info to display things definitely Oct 04 18:04:44 https://drive.google.com/file/d/1g-PYcCC6i50j7bJTqKsmxi0mlWuMBdCO/view?usp=sharing Oct 04 18:06:16 the other datasheet is for a slightly different screen, it has 240 lines which makes it a bit easier to talk with (mine has 536 so the line numbers are encoded on 10 bits) Oct 04 18:06:46 It should be pretty doable to do things once I get an fb0 Oct 04 18:07:45 this thing requires you to manually deal with COM inversion? ouch Oct 04 18:09:06 I'm not sure whether fbtft can handle this sort of display, I doubt it Oct 04 18:11:14 this documentation seems very sparse and unclear to me Oct 04 18:17:12 okay it's not that unclear, it does however look really annoying Oct 04 18:18:25 for a "smart" display (in the sense of having an integrated framebuffer), this has to be the dumbest "smart" display I've ever seen Oct 04 18:19:20 zmatt as one person put it "just enough to get it to work" documentation. The display itself is the controller so that's why they call it a smart display. Oct 04 18:19:47 I mean it *has* an integrated framebuffer Oct 04 18:20:09 but you can only update single complete lines of it (or clear it) Oct 04 18:20:40 and you have to manually toggle COM, that's the part I find especially bizarre Oct 04 18:22:39 maxime: you can try digging through the three dozen fbtft kernel drivers to see if there's one that resembles this kind of display :P Oct 04 18:23:56 and you may want to use some PWM pin for the COM... iirc an lcd display can get damaged if this line stops toggling, so you probably want that to be done by hardware rather than software Oct 04 18:30:53 looks like there's some out-of-tree kernel driver for it... which uses a kernel thread that every 50 ms converts the 8bpp framebuffer to 1bpp (in an inefficient way... why don't they just use a 1bpp fb to begin with?), diffs against the previous version, and on change writes it via SPI. it also has a second thread for toggling vcom (no support for using a PWM pin). it also won't support two displays ... Oct 04 18:30:59 ...like you were hoping for since it uses global variables Oct 04 18:32:23 god this driver looks awful Oct 04 18:32:58 maxime: if you want to get things working easily, I suggest finding a display that already has a working driver in mainline linux Oct 04 18:48:22 I'll look that way but I want to try first as I already have a screen Oct 04 18:48:37 then get comfy with linux kernel driver development I guess :P Oct 04 18:48:49 that's a good way to learn I believe :p Oct 04 18:49:30 Well I would suggest as a start is to get a 1bpp bitmap and send it to the display. That is if you haven't successfully displayed anything yet. Oct 04 18:49:30 for Com inversion I planned on using a 555 Oct 04 18:49:51 that's silly, the BBB is perfectly capable of generating a suitable signal Oct 04 18:50:15 just use any pwm output Oct 04 18:51:42 idk I feel like if there's a software bug on my BB I'll just have to throw the screen Oct 04 18:52:15 GenTooMan: yeah i will definitely go this route, I thought it would be easier to get the fb working Oct 04 18:52:20 maybe the kernel driver I found ( https://github.com/kylehawes/Sharp-Memory-LCD-Kernel-Driver ) works for you, as disgusting as it is, but you'll at least want to get rid of its COM suff Oct 04 18:52:43 well it's relatively easy if you use a display that's actually supported by linux already :P Oct 04 18:53:31 you've got a point x) Oct 04 18:53:39 maxime: I mean, software bugs can also fry the AM335x itself by messing up voltage setting in the PMIC Oct 04 18:54:10 you're right Oct 04 18:54:22 I think I'd trust it to do one-time setup of a pwm output done by the kernel driver based on DT config Oct 04 18:54:34 I wouldn't trust it to manually toggle COM using a thread :P Oct 04 18:55:16 so then I have to get the thing working with a 555 and then learn kernel stuff for the fb & com Oct 04 18:55:31 (since then kernel panic = dead display) Oct 04 18:55:44 how quickly does a display die anyway if COM stops toggling? Oct 04 18:56:21 idk for lcd Oct 04 18:56:33 I managed to burn a few e-ink displays pretty fast Oct 04 18:56:35 since a kernel panic will obviously also cause a watchdog reset soon after (provided you enable one), which means the display would disable Oct 04 18:57:16 it doesn't really matter, manually toggling is a pointless waste of time anyway Oct 04 18:57:36 yas but those memory lcds are cute Oct 04 18:59:11 I really don't understand why the panel doesn't handle COM toggling itself Oct 04 18:59:26 like basically every other smart display Oct 04 19:00:29 it makes things funnier Oct 04 19:02:23 fixed pwm setup in a kernel driver is just devm_pwm_get() + pwm_apply_state() Oct 04 19:06:20 I'll check that then Oct 04 19:07:14 I have another (probably silly) question : can I just install another screen driver, say for an uart screen just to get an fb0, and then do everything from userspace ? Oct 04 19:07:34 (a "uart screen"??) Oct 04 19:07:35 and no Oct 04 19:08:06 i had an e-ink screen that used uart Oct 04 19:08:19 funky Oct 04 19:09:08 anyway, I guess if there's a "dummy fb" driver or something that just allocates a framebuffer in memory without doing anything with it you could have a userspace process periodically scrape that Oct 04 19:16:14 the protocol for that thing is kind of funky. I can see the "dumbest" smart display comment kind of holds. Oct 04 19:19:17 maxime: https://pastebin.com/kkrGctwt Oct 04 19:20:30 definitely easier than spawning a kernel thread to toggle a gpio :P Oct 04 19:22:06 haha thanks a lot Oct 04 19:22:11 it might actually be tempting to use pwm_get instead of devm_pwm_get so that if for whatever reason your device gets destroyed (e.g. unbind) the pwm is leaked and doesn't get cleaned up (which would stop the pwm) Oct 04 19:23:01 although a better solution is to just ensure the display is disabled in the driver's remove function Oct 04 19:34:45 I'll research the difference then :P Oct 04 19:35:52 devm_ calls are resource-tracked for your device Oct 04 19:36:05 so they're automatically freed/released when your device is removed Oct 04 19:36:25 so they simply things, especially for error-handling cases in probe Oct 04 19:36:28 *simplify Oct 04 19:39:49 ok Oct 04 19:40:05 when you say removed Oct 04 19:40:11 you mean physically ? Oct 04 19:41:00 I mean when the device is removed in the kernel... which for hotpluggable devices happens for example when the device is physically removed, but spi is not hotpluggable Oct 04 19:41:10 it also happens if probe fails Oct 04 19:41:28 (though in that case you don't get an actual "remove" call) Oct 04 19:41:50 another way to get a remove is by manually unbinding the driver via sysfs Oct 04 19:44:45 zmatt: alright I get it Oct 04 19:52:06 thanks a lot for the help ! I'll dive in now :D Oct 04 20:26:42 I have an I2C device that has a default address of 0x7d. This is outside the I2C-2 address range of 0x03-0x77. Is there a way to modify the range so I can see/interact with this device? Oct 04 20:27:12 ehh Oct 04 20:28:05 what do you mean by "the I2C-2 address range of 0x03-0x77" Oct 04 20:28:14 every i2c bus supports every valid address Oct 04 20:29:10 Well, running the i2cdetect command shows a list of devices connected from 0x03 thru 0x77 Oct 04 20:29:20 (valid addresses are 0x08 - 0x7b) Oct 04 20:29:27 0x7d is not a valid i2c address Oct 04 20:29:39 what device is this? Oct 04 20:29:57 Sparkfun RIFD sensor Oct 04 20:30:06 "#define RFID_ADDR 0x7D // Default I2C address" Oct 04 20:30:23 RFID* Oct 04 20:31:23 sometimes people will inappropriately include the R/nW bit in the address, maybe that's what's going on here Oct 04 20:31:59 you presumably mean an rfid reader, not an rfid sensor, but even then it would be nice if you could be more specific Oct 04 20:32:44 the SparkFun RFID Qwiic Reader ? Oct 04 20:32:45 SparkFun Qwiic RFID-IDXXLA Oct 04 20:32:49 bingo Oct 04 20:33:03 was his name-o Oct 04 20:34:21 Actually, this may be a non-issue. I can initialize the RFID reader using the 0x7d address, I just can't see it with the i2cdetect command Oct 04 20:35:16 0x7d is however definitely _not_ a valid i2c bus address, and I'd consider it a kernel bug if it allows you to try to use it Oct 04 20:35:47 lol, actually the firmware in the qwiic also has a command that lets you change its i2c address Oct 04 20:36:05 and it actually performs the correct check: https://github.com/sparkfun/SparkFun_Qwiic_RFID_ID-XXLA/blob/master/Firmware/ATtiny85_Firmware/Qwiic_RFID_IDXXLA/Qwiic_RFID_IDXXLA.ino#L188-L189 Oct 04 20:36:47 Ok thank you zmatt! I'll check it out Oct 04 20:37:05 so once you change it to a valid address, you can't change it back to its default address since the default address is an invalid address Oct 04 20:37:08 brilliant Oct 04 20:39:20 (addresses 0x7c and 0x7d are used by the i2c device ID protocol... which almost nobody implements) Oct 04 20:39:39 wait no Oct 04 20:40:46 device id just seems to use 0x7c, but 0x7c - 0x7f are reserved for it in the i2c spec Oct 04 20:42:59 The libraries that are inlcuded in the firmware repository are for arduino (wire.h) Any tips on converting this for BBB use? Oct 04 20:43:29 Not sure if EEPROM.h is as well - I've historically had issues with these libraries and BBB Oct 04 20:45:09 this is the firmware of the microcontroller on the Qwiic itself Oct 04 20:45:15 not relevant Oct 04 20:45:23 other than for understanding how this thing works Oct 04 20:46:06 Ok, not sure how I interface with it then to change that i2c address? Oct 04 20:46:15 via i2c Oct 04 20:47:30 Seems like a conundrum -- can't access it because of it's invalid address Oct 04 20:49:07 well you just said "Actually, this may be a non-issue. I can initialize the RFID reader using the 0x7d address" Oct 04 20:50:08 It sets up an i2c device object with a memory address without an error message, but any writes or reads to it comes back as a 0 Oct 04 20:50:24 hmm Oct 04 20:50:36 Actually I've tried another arbitary address and it works the same. I'm using the Adafruit_GPIO.I2C library Oct 04 20:53:18 this sounds really odd, I'd expect it either works or fails with an error Oct 04 20:53:36 not sure what you mean by a write "coming back as a 0" Oct 04 20:53:49 lemme check what commands this thing has Oct 04 20:53:59 isn't the adafruit GPIO lib broken? or unsupported or something? Oct 04 20:54:22 actually, just kidding. I do get an error with other addresses - it works with the 0x7D address Oct 04 20:54:28 one of theirs is dead .. Oct 04 20:55:04 bRitch022: okay, so you can communicate with it? Oct 04 20:55:10 a lot of adafruit libraries are broken Oct 04 20:55:14 I'd suggest avoiding them Oct 04 20:55:18 Yes, I can Oct 04 20:55:38 just use the smbus2 module or something like that Oct 04 20:56:00 It works ok with a PCA9685, serLCD, and a TCS34725 Oct 04 20:56:25 does it work with python 3 ? Oct 04 20:56:43 Python2 Oct 04 20:56:47 (which you should always use, python2 is obsolete, deprecated, and very close to end of life) Oct 04 20:56:51 don't use python 2 Oct 04 20:56:56 especially not for new projects Oct 04 20:57:27 * veremitz sits back and nibbles on the channel popcorn :p Oct 04 20:58:09 It hasn't been broken for me yet, and it's what my Cloud9 IDE is running by default. Oct 04 20:58:29 a ton of major python libraries have pledged to drop python2 support in or before 2020 Oct 04 20:58:53 wait .. I just woke up and its still 2019 . damn... Oct 04 20:59:05 I coulda sworn it was 2021 in Freenode .. >,< Oct 04 20:59:19 Oct 04 20:59:22 (including numpy/scipy) Oct 04 20:59:29 Yeah, i'll take the suggestion and upgrade. Oct 04 20:59:39 python3 is installed by default Oct 04 20:59:51 I don't know anything about cloud9, but outside of it there's no reason to not use python3 Oct 04 21:00:01 Anecdotally, my email redirect stopped working on Monday. I have new email today .. >,< Oct 04 21:00:03 -shrug- Oct 04 21:00:18 rcn-ee[m]: is there some way to fix cloud9 to use python3 by default? Oct 04 21:00:38 probably unsupported *laughs* :/ Oct 04 21:00:44 kidding . it might be. Oct 04 21:01:34 Gotta run, thanks again @zmatt, I'll let you know how it works out after this weekend Oct 04 22:35:54 * mrpackethead hands out $100 fine for use of python2 Oct 04 22:36:08 please pay the fine at your local court house Oct 04 22:36:54 zmatt, i found a lot of the adafruit modules were broken as well Oct 04 22:36:55 :-( Oct 04 22:37:07 been finding it just about easier to create your own. Oct 04 23:11:28 python2 should port to python3 easily. The main reason python2 crap is still around is because they have given lazy programmers a decade to fix that. That ends in January of 2020 of course. Oct 04 23:19:57 GenTooMan, some of it has been beause there are managmeent structures that wont' fix what still works. Oct 04 23:20:04 there will be python2 for years Oct 04 23:24:43 relying on an unmaintained compiler/interpreter and unmaintained libraries is of course great for the maintenance of your own stuff when inevitably you do need to change/fix/improve stuff Oct 04 23:33:57 not having 100% backward compatbility is just a bad idea Oct 04 23:34:10 no it's not Oct 04 23:34:21 then you get that mess Oct 04 23:34:40 if the ARM architecture still had backward compatibility with ARMv1 it would be awful Oct 04 23:34:52 IIRC, it had that for the longest time Oct 04 23:34:55 that 26bit mode thingie Oct 04 23:35:19 100% backwards compatibility means you can never fix the mistakes of the past Oct 04 23:35:27 hmm? Oct 04 23:35:49 it could be as simple as adding python2 compat; Oct 04 23:36:00 ARMv4 made it optional, ARMv5 removed it Oct 04 23:36:17 so all one has to do is add a line and you have the 100% compat... now even python3 is not compatible with python3 Oct 04 23:36:23 it is just one messy mistake Oct 04 23:37:04 I don't see any plausible way to do that, nor any use to do so.. it would basically mean having to maintain python2 and python3 but just rolling them into one executable Oct 04 23:37:29 yes, essentially that Oct 04 23:37:44 it sounds awful Oct 04 23:38:04 it is the pragmatic thing to do Oct 04 23:38:36 people had 5 extra years to migrate on top of the original EOL date for python2 Oct 04 23:39:10 people who are still using it after being deprecated for 5 years are just being dumb Oct 04 23:39:21 migrate from one mess to another? python3 is not compatible with python3 Oct 04 23:39:27 I don't know what you mean by that Oct 04 23:39:43 they changed the async crap around Oct 04 23:40:03 can you be more specific? Oct 04 23:40:57 I don't recall the specifics, it has been 4-5 months since i looked at that. some version of python3 added async handling but there are at least 2 ways that is done within python3 but afaict, no single way will work with ALL of python3 Oct 04 23:42:10 "async handling" is rather vague, especially if you're referring to something that was already present in 3.0 Oct 04 23:42:48 ah yes... async/wait stuff vs asyncio Oct 04 23:42:52 and complaining loudly about something but not knowing what you're complaining about is a pretty dumb thing to do Oct 04 23:43:10 either be able to explain the problem, or shut up about it Oct 04 23:43:12 python is just a major PITA Oct 04 23:43:57 I don't like python either, but I don't see how my dislike of it is relevant for keeping people from migrating away from an obsolete and unmaintained version thereof Oct 04 23:44:57 note btw that asyncio was introduced in 3.4 (so definitely wasn't available in "all versions" in the first place) with a big warning that it was provisional and still subject to change Oct 04 23:45:11 calling python2 obsolete is silly at best when python3 not python3... python3.4 and python3.5 require different thing Oct 04 23:45:57 ds2, you're complaining in a way that makes you look clueless, please stop that Oct 04 23:46:16 i don't think get the point Oct 04 23:46:44 asking people to move from what is reasonably stable to something that is less stable is just a bad idea regardless of you calling it obsolete, X years old, etc Oct 04 23:47:58 give people a stable target... like migrate to python3 and do new dev in python4...something to provide a level of stability Oct 04 23:48:23 building embedded target with 3-4 versions of python just to keep the rest user space happy is just idiotic Oct 04 23:48:42 you keep repeating the same claim instead of providing an example of what you're talking about Oct 04 23:49:00 what did they break? Oct 04 23:49:53 (as in, which part of the python3 language or standard library, excluding anything explicitly marked as provisional and subject to change, did they break in a later version of python?) Oct 04 23:50:15 like maybe I can agree with you if I had any idea what you were talking about, but I don't Oct 04 23:50:24 one more comment and then enough from me - just look at the number of questions of 3.4 vs 3.5 on the async io stuff. provisional or not, they are all "python3" a moving target. Oct 04 23:50:42 with that, I shall comment no more on this. Oct 04 23:51:25 sorry but if a module has an explicit warning that it's still subject to change, and then changes, you have absolutely nothing to fucking complain about Oct 04 23:52:01 that's not the same thing as a stable part of python changing Oct 04 23:52:43 and I'm not going to try to search the internet for examples of what I think you might be talking about based on an extremely vague description Oct 04 23:52:51 back to fighting USB and UVC for me Oct 04 23:53:19 Probably more profitable. Oct 04 23:56:14 well their is a reason for python 3 to overcome the limitations and annoyances of 2. Most libraries directly port from 2 to 3 however their are some things you need 3 for. All I can say. I prefer 3 now that I've been using it more and forcing 2.7 off my system. Oct 04 23:58:14 I think the point stands that "what is python3" ie . python3.4 python3.5 python3.6 or python3.7 .. there are subtle breaking changes between *minor* versions :/ Oct 04 23:58:35 I get that that was his point/claim, I was example for examples Oct 04 23:58:51 *was asking for examples Oct 04 23:58:53 I'm not gonna go trawling google either, but I've heard the argument from several sources Oct 04 23:59:16 since I want to know if they're legitimate claims or just people being dumb Oct 04 23:59:19 cf. I accept the argument as valid Oct 05 00:01:32 (also, were these breaks more significant than any breaks that happened between python2.6 and python2.7 ?) Oct 05 00:06:13 idk .. its a bit like kernel bugs .. its not so much the size, as the increasing quantity :/ Oct 05 00:06:27 or frequency .. however you wish to measure. Oct 05 00:09:48 anyway. i'm happyly using 3.7 and its doing a great job. Oct 05 00:10:06 all my 2.x code is migrated or killed off. ( most of it was killed off! ) Oct 05 00:12:35 I wish I could rely on 3.6/3.7 stuff yet, but I'm trying to keep backwards compatibility with python3.5 for now Oct 05 00:13:45 zmatt, i got GreenGrass running and happy. Have the sensors connected and collecting data. Oct 05 00:14:07 its sending up 6min collection data via MQTT. Oct 05 00:14:36 I love the way that you can remotely deploy your lambdas Oct 05 00:28:39 zmatt I do feel your pain when it comes to the changing nature of python 3 I think they should get a hint from the Perl Crowd who were told "sorry you can NEVER have a standard cert" because they kept changing things. Oct 05 00:29:28 hehehe perl6 yeah :D Oct 05 00:29:41 GenTooMan: I think you're confused, I have no experienced any such pain, I was just trying to get people who claimed they did to explain / give examples Oct 05 00:29:50 *have not Oct 05 00:30:19 (I don't use python much so my lack of experiencing any upgrade-pain is not really indicative of anything) Oct 05 00:33:20 my experience tends to be of projects that have been slow to port to python3 .. same as with qt4 to qt5. qt4 has been completely killed from Gentoo linux, for example Oct 05 00:33:35 but many still regard it as 'stable' qt Oct 05 00:34:03 yeah I'm sure something is very stable is nobody is working on it anymore :P Oct 05 00:34:07 *if Oct 05 00:34:07 that said, I admit to being behind the curve Oct 05 00:34:32 zmatt: its like qmail .. if it ain't broke .. ;) Oct 05 00:34:47 qmail is 'dead' .. but half the internet still runs it Oct 05 00:34:55 those that aren't running M$ or google. Oct 05 00:35:22 or postfix or exim, ofc. Oct 05 00:55:04 zmatt Well I can see why people could be concerned. However syntax wise I haven't seen anything since past 3.5 the underlying functionality might be a different thing. Oct 05 01:13:26 Are people liking the new images? Oct 05 01:14:50 ah... YUV Oct 05 01:15:53 I am about to grab it for the motor cape attachment to an older board, i.e. BBBW! Oct 05 01:21:36 Oh. It is still Stretch. Nice! Oct 05 01:53:38 what's "nice" about that? I'm kinda disappointed it's still not buster Oct 05 01:54:31 zmatt: we all know you insist on running 'sid' :p Oct 05 01:55:00 I do on my laptop, not on beaglebones Oct 05 01:55:12 and why not?! Oct 05 01:55:16 keep in mind buster is debian stable atm, which is typically already old :P Oct 05 01:55:18 I am used to it. Oct 05 01:55:28 set_: what do you imagine would change? :P Oct 05 01:55:35 Everything! Oct 05 01:55:55 I very much doubt most users would notice any difference at all, other than less old versions of software being installed Oct 05 01:56:03 Oh. Oct 05 01:56:04 Okay. Oct 05 01:56:37 I figured w/ new releases, new ideas are then maintained. Can I get a whoo-ya? Oct 05 01:56:52 For some reason, I am still on 4.14? Oct 05 01:56:59 Is that correct? Oct 05 01:57:14 4.14 is the kernel version, that has nothing to with the debian release Oct 05 01:57:20 Aw! Oct 05 01:57:44 I understand but I figured w/ the new image from BBB.io, the new kernel would be put in too. Oct 05 01:57:50 Should I let go of this idea? Oct 05 01:58:06 why would it be? Oct 05 01:58:27 B/c...people would like to stay up-to-date on Debian ideas. Oct 05 01:58:43 debian has nothing to do with the kernel version Oct 05 01:58:51 Me, no issue. Oct 05 01:58:59 But... Oct 05 01:59:08 and presumably something is still blocking to the switch to the 4.19-ti kernel series Oct 05 01:59:14 *blocking the switch Oct 05 01:59:22 Oh. Oct 05 01:59:28 So, the kernel was updated? Oct 05 01:59:28 but I'm not sure what, that would be a question for rcn-ee[m] Oct 05 01:59:33 Okay. Oct 05 01:59:34 ? Oct 05 01:59:40 Sorry. Oct 05 01:59:51 I asked the same question in four different formats. Oct 05 01:59:54 My bad. Oct 05 02:00:16 Updating the kern. Can I call the kernel a kern. in here? Oct 05 02:00:24 no Oct 05 02:00:27 Fine. Oct 05 02:02:40 I guess I will manually change the kern...el. Ooh. Almost fooled ya. Oct 05 02:03:47 Also...the LXQT image takes a year to download. Is this correct? Oct 05 02:05:16 I got the IoT image done and booted. The LXQT is taking one day, i.e. feedback from my google download page. Oct 05 02:18:09 Why is nginx the only "real" server on the BBB images these days? Oct 05 02:18:28 ? Oct 05 02:18:36 I know I can add them. Oct 05 02:18:45 did the BBB images finally move from apache to nginx? about time Oct 05 02:18:51 I only have nginx on the BBBW right now. Oct 05 02:18:52 Oh. **** ENDING LOGGING AT Sat Oct 05 03:01:28 2019