**** BEGIN LOGGING AT Fri Feb 12 02:59:57 2021 Feb 12 12:15:52 set_: i have it working before your reply but thank you so much for helping out :) Feb 12 12:16:52 i got it to name the lines and consumer correctly Feb 12 12:17:04 through the device tree that is Feb 12 12:22:21 know that feeling when you have many many tabs open and close them all just to get rid of them and then realize there was this one page you were looking at with excelent source matterial xD Feb 12 17:20:58 Good morning folks. I posted a question last night then immediately started having internet problems and couldn't see if anyone responded. So, I'll just post it here again. Feb 12 17:22:27 Question! I'm trying to use a BBB to interface with a PCB which controls a bunch of relays. Feb 12 17:22:27 I was previously able to make it work by putting a separate relay board in between the BBB and the PCB I'm trying to control. Now I'm trying to simplify the circuit and get rid of the intermediary relay board. I'm convinced I can make it work with a few well placed transistors between the BBB and the PCB. Has anyone tried anything similar or have any ideas for me? Feb 12 17:23:29 Each relay input on this PCB is fitted with an optocoupler which isolates them from the logic. Normally, each input on the PCB is left open. Sending a 12v signal to an input activates that relay on the PCB. I'm trying to build a circuit that sends the 12v signal to the PCB inputs in response to me pulling a BBB GPIO high. Feb 12 18:05:37 uncletammy: 12V ? for opto-coupler inputs? o.O Feb 12 18:07:31 zmatt: Yep, 12v and yeah for optocoupler inputs. Feb 12 18:08:35 like, an opto-coupler input is essentially a LED... though I suppose they could easily have been made 12V resistant by using bigass series resistors Feb 12 18:13:34 regardless, if they are incompatible with the digital outputs of the BBB, simple NPN transistors can probably do the job yes, as can MOSFETs Feb 12 18:20:47 zmatt: That's what I was thinking as well. Any chance you point me to an example circuit? No pressure if you're busy. I'm not sure how to go about searching for it. Feb 12 18:31:37 uhh I guess I could sketch it but I'm eating food right now Feb 12 18:40:22 No biggie Feb 12 21:04:14 <_austin> afternoon everyone Feb 12 21:05:28 <_austin> i'm trying to debug a .py file in cloud9 on my bbb and can't seem to get it to work.  I just have a simple print statement even and I get error "spawn /opt/cloud9 support/bin/tmux ENOENT" when trying to run it. i can run the file fine in the bash window doing python3 app.py, but can't seem to run/debug without that error. Feb 12 21:06:23 _austin: didn't see your private message earlier.. sorry, we've recently had problems with spambots, hence the requirement to have a registered nickname Feb 12 21:06:44 <_austin> np, i figured so i thought i'd try this to check and sure enough./ Feb 12 21:06:53 shouldn't apply to the webchat though, odd Feb 12 21:07:11 <_austin> it did! but again, it's all good. minor inconvenience to make sure it's secure. Feb 12 21:07:47 hum Feb 12 21:08:42 that's annoying, it seems they no longer mark webchat connections using @gateway/web/* Feb 12 21:10:19 <_austin> again it's all good, i got it figured out:D Feb 12 21:10:25 <_austin> Either way, any ideas on that error? Feb 12 21:10:38 I don't know anything about cloud9 Feb 12 21:11:14 let's see if the spambots are still active Feb 12 21:12:02 <_austin> yea typically i wouldn't mess with it. it's the built in ide for the beaglebones, but i've got antoher guy on the project team that isn't quite as code savvy and thought it might help if i'm away so he can debug and try to fix his own issues Feb 12 21:13:57 test Feb 12 21:36:21 this is so weird... trying to set mode +e $r:*webchat* and it's just doing nothing, it's not setting it nor giving an error Feb 12 21:51:14 <_austin> gah my computer blue screened. not sure if someone else had anything to say on the cloud9 thing for about 20 minutes Feb 12 21:52:01 nope Feb 12 22:28:04 I've been working on my project for the past weeks and decided that attempting to port SDL2 is the most straightforward strategy. Currently SDL and demos compile, but SDL_CreateWindow fails at runtime. What I've done so far: https://termbin.com/twbg. What I'm wondering about is if there Feb 12 22:28:39 .. is if there? Feb 12 22:29:27 ah, I see SDL has hardcoded pixel format assumptions, like qt5 used to have Feb 12 22:29:54 (I originally patched qt5 for that myself, though nowadays it looks like qt5 is more flexible about pixel formats) Feb 12 22:31:22 is any way to make use of previous attempts. Someone claimed in the google group that he had used SDL2 (with SGX530 rather than software rasterizer) on Beaglebone Black, but he never gave any further details https://groups.google.com/g/beagleboard/c/DVu2-HVDAmU Feb 12 22:31:24 if you're using hdmi output you can also change the DT in a way that makes lcdc support XRGB8888 instead of RGB565 although the least significant bits will be ignored and using that format is a waste of memory and memory bandwidth Feb 12 22:31:39 sorry i accidentally sent before finishing paragraph Feb 12 22:33:09 well in theory little or no "porting" should be necessary if it is already written to use EGL and GLES2 Feb 12 22:33:32 like, the patch you showed has nothing to do with GL and would apply just as much if you don't use the GPU at all Feb 12 22:34:13 I'm curious, what is the GPU being used for anyway? I'm not sure how useful GLES2 is for accelerating 2D graphics Feb 12 22:36:52 yeah I've only been able to use RGB565 with demos I have functioning like kmscube. A major point of concern though is that SDL2 is intended for use with upstream libgbm, not the libgbm we use here, so I've bene trying to find some way to port SDL2 the same way the special kmscube we use has been ported to work with this libgbm. Feb 12 22:37:03 like, with qt5 iirc the EGL backend was actually slower than the (gpuless) linuxfb backend... the only reason we used it is because it didn't have a backend for using drm/kms without using egl/gles, so using gles was the lazy way to get double-buffering Feb 12 22:43:17 my ultimate goal is porting the game Super Mario 64 decompiled version to Beaglebone Black, so that is why I have been working with the GPU this whole time. SDL2 is a 3D graphics library wrapper for OpenGL and OpenGL ES intended to make this easier, but this isn't the only option I have Feb 12 22:43:28 ah right, I remember now Feb 12 22:44:00 so SDL would perform the role of EGL then or something? Feb 12 22:46:22 and input stuff I guess Feb 12 22:47:05 well, SDL backend actually is intended to use EGL, GBM and OpenGL ES the same or similar way the kmscube fork we have working does to initialize the KMS/DRM display Feb 12 22:47:09 https://github.com/libsdl-org/SDL/blob/main/src/video/kmsdrm/SDL_kmsdrmvideo.c Feb 12 22:50:58 I'll admit I don't know a great deal about this... I thought egl allows you to just specify the default display and not have to deal explicitly at all with GBM or DRM/KMS ? Feb 12 22:51:07 like: https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglIntro.xhtml Feb 12 22:51:22 oh, never mind Feb 12 22:51:23 hmm Feb 12 22:52:18 whenever I have to deal with opengl and friends, I always wonder what the klingons have to do with it all Feb 12 22:52:24 lol Feb 12 22:52:55 although lately the vulcans seem to have become involved too Feb 12 22:53:35 the naming scheme is probably not a coincidence Feb 13 01:20:17 GenTooMan: Are you around? Feb 13 01:20:50 Oh and are you bored to death? If either/or, maybe we can chat about the FLIR and BBG. Feb 13 02:27:00 Anyway...I found a python lib/SDK for Lepton. Nice! Grayscale. Feb 13 02:34:28 Okay. Anyway, since the room is quiet now, here is a photo to view that is not grayscale but is oddscale w/ the Python Lib/SDK. Please wait for photo from the FLIR Lepton v2. Feb 13 02:38:08 https://i.imgur.com/XRUcWsm.jpg is an image of my 'hand' but it is not showing it well for now. **** ENDING LOGGING AT Sat Feb 13 03:02:54 2021