TonyMac32

Outdoor use in full sunlight is key. I have a small pile of the OLED's for other uses, but they don't handle field use as well.

@Larry Bank I happened across these again: https://www.aliexpress.com/item/1pcs-White-Backlight-84-48-84x84-LCD-Display-Module-Adapter-PCB-for-Nokia-5110-for-Arduino/32267197519.html They might be used, or they might be quality rejects for actual product, I'm not sure. There are other options from the seller, I haven't gotten any yet so can't speak to the state they're in.

@chwe it's not in UML???? To be honest I think my head would explode if I ever saw anyone actually publish open source code with modelling and flowcharting. My coding experience is x86 and ARMv4t assembly language, C, and Java. Python never interested me in the least, which is why I hadn't been as helpful with these libraries before. Well, on the 3rd/4th one I guess I need to learn the language so I can teach my little ones. For these libraries I'm primarily looking at/commenting on structure and use, so I am an educated "noob" as far as the tool is concerned. @chwe is a bit more knowledgeable, and loves flow charts.

If you look at the configuration of the Tinker board it should be possible implement exactly the same thing using the correct pinout

interesting, 4.4.138 has functional analog out, let me build a new one and take a look.

hmmm, I've seen worse. You could replace the manual override part with a "name your board file", is my first idea...

section 2.4.4 seems to suggest it is checking the SD before the eMMC, no button pushing or anything to boot the SD.

Bumped/Pinned like the others. If I'm going to be in the trenches on these boards, may as well make it count. I want to see this, circuitpython, Larry Bank's and sgjava's libraries all in a subforum (and any I'm missing, authors step forward and be counted. ;-) Also @chwe tossed you a PR for Tritium H2+/H3 and your own Blinky example.

Pinned as this library has come up repeatedly in last weeks, topic was buried entirely.

Awesome, will do.

@Neil Armstrong Well, let's say I start packaging Mali, would I need to set it back? The only reason I ask is that I haven't put it in there because I want to build the driver with the kernel rather than externally, and just haven't taken the time to do it properly. On another note, I have dead USB ports on C2 and K2, if the board is booted with nothing plugged in. It made me think of the dwc2 issues on the Rockchip RK3288's, where booting with nothing plugged in caused a buggy sleep state, but the solution for that issue did not resolve this one (checking to make sure it even translates properly). OK, first time I did it wrong, second time appears to do the trick, but I need more test time, no question. https://github.com/armbian/build/blob/master/patch/kernel/meson64-dev/general-dwc2-partial-powerdown-fix.patch

Current Kernel 4.19 dev images appear to have a "nobody home" USB situation again (brought t0 me by @martinayotte as he works on overlays, and I verified) Just so fewer people are surprised. Hopefully look into this next. [edit] It appears USB hot plug is the culprit, the ports have power and the hubs are brought up during boot, but the peripherals only work if plugged in before boot, not after. I just saw this issue on Tinker Board starting with (I think) 4.17, fixed via https://github.com/armbian/build/blob/master/patch/kernel/rockchip-dev/1008-rockchip-dwc2-usb-partial-power-down.patch (Thank you @Myy for tracking that down) I'll see if that is the same issue here, have you seen anything like this, @Neil Armstrong? I'm not seeing the issue with Le Potato, but it also has a dwc3 controller in the mix.

Calm down, there's no need for yelling. Given the images from yesterday didn't work with displays, I had a valid question for you. You should also see a marked improvement in wired networking, there was an IRQ bug.

How fresh? Today's build should include some fixes that greatly improved (but didn't completely solve) the issue.

Well, it's one of only two with 4 fast cores, the other being XU4. The RK3399 doesn't even have that going for it. It honestly is in the top 3 performers in any case, every time I use any other board I get a rude awakening about how bad a desktop experience can be. RK3399 is somewhat better but is still poorly supported kernel wise by comparison.

acerEDID.bin samsungEDID.bin USB-EDID.bin Acer dri/status: acer dri/framebuffer: USB HDMI dri/state: USB dri/framebuffer:

@Neil Armstrong I'm not really sure how, but just adding the 2 patches (the IRQ for eth and max height/width) and my DVI monitor started on boot... I'll do some more testing and let you know. [update] it booted twice in a row, but it still has all of the bugs other than the boot one...

I get yelled at by my wife because I don't answer the phone when driving unless my car is sync'd over Bluetooth... In reality though I should set up some kind of task list, @jimg isn't the first person who's issue went unresolved for way longer than it should have...

@martinayotte I need to stop checking the forum on my phone, I forget when things like this one come up... Thank you for digging this up!

Thank you for the feedback! Sent from my Pixel using Tapatalk

Interesting, the only monitor I have that works from boot is a USB connected one... The monitors giving me trouble are both powered via their own main line supplies. Perhaps the issue is with the phy not being powered soon enough rather than with the monitor... If a display is plugged in on boot (other than my USB one), it does not recover, no matter what monitor or number of plug cycles are used. for the other, (note my HDMI knowledge is minimal, but from "the old days" of scanline displays), the phenomena I am seeing on unplug/replug *looks* like the vsync is not updating when you plug in the new display. So when a low res display is disconnected and a high res connected, the same number of vertical pixels are displayed and the rest of the screen is black. When going the other way, the horizontal over runs the vertical line and "wraps" causing an interlaced pattern. Ah ok, I had seen it but hadn't looked closely. Thanks!

@Neil Armstrong New patchset rolled out, HDMI is still a problem, this occured when unplugging the monitor that was attached at boot: My 7" is still perfect, the hdmi/dvi adapter and the 4K Samsung are still issues. One strange note: Like before booting with no monitor then adding one works. However switching monitors results in a garbled display on the first plug, then a pull/replug it is fine. So Boot ----> plug in monitor ---> unplug, plug into 2nd monitor (*garbage ensues, no errors though*), unplug -----> replug ---> perfect. From low to high res you get only half the larger screen, on high to low res move it is completely corrupted.

Hmmm, can you boot it from SD? You might be able to just try a tinker board image by swapping out a device tree (if you have one) for the board

I didn't read this the first time, but, I don't follow your logic. RPi hardware has gotten less reliable since the Pi2, not more. Movement to a new SoC will mean no carryover hardware support, and I don't know of any timelines for the availability of this "future Pi". How long did it take to get a 64-bit image for Pi3? How long did it take to get proper software support on the original pi? I see no reason to assume the Pi 4 will have acceptable support within a year of release, unless it is released as an Allwinner, Amlogic, or Rockchip device, at which point it means you should have bought the potato/Frite/Tinker board anyway, since Pi will offer no benefit.

That is sooner rather than later, the patches are being reviewed for merging into mainline, and I see an update on the patchset we use to include it and 4K in the dev kernel.