Date: Tue, 18 Nov 2025 08:12:19 +0200 From: Sulev-Madis Silber <freebsd-hackers-freebsd-org952@ketas.si.pri.ee> To: freebsd-hackers@freebsd.org Subject: Re: addressable led driver Message-ID: <677E3CFD-91A4-4A46-AC15-1CAD49F891F5@ketas.si.pri.ee> In-Reply-To: <CAFYkXjnqqfmO7zWv4-diFa99ZsDc2Dor2DK4qowLzhh_=a=v8g@mail.gmail.com> References: <BB74B308-9501-4DA0-89E9-4DA0AE553AA5@ketas.si.pri.ee> <4DE06290-81C0-4D21-8919-5A39B1DB3949@dons.net.au> <CAFYkXjnqqfmO7zWv4-diFa99ZsDc2Dor2DK4qowLzhh_=a=v8g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On November 17, 2025 7:54:56 PM GMT+02:00, Tomek CEDRO <tomek@cedro.info> wrote: >On Fri, Nov 14, 2025 at 4:31 AM Daniel O'Connor <darius@dons.net.au> wrote: >> > On 14 Nov 2025, at 11:27, Sulev-Madis Silber <freebsd-hackers-freebsd-org952@ketas.si.pri.ee> wrote: >> > i want to create a proper driver together with userland tools to control all addressable leds directly from fbsd >> > >> > they all have different cursed protocols that don't fit spi at all >> > most popular is ws1812 which would mean if you want actual spi it would be clockless and this all kind of sucks >> > >> > i found gpiospi.c which is entirely undocumented. unsure how to get it working, i tried and failed >> >> gpiospi.c does bit banging - I think you will struggle to meet the timing requirements for WS2812 with it unless you do something horrible like disable all IRQs, send the bit stream and then enable them again. >> >> What actual SoC do you have? >> >> For example, the Beaglebone has PRUs which are simple coprocessors which can do this sort of bit banging (I have done it in Linux using LEDScape). >> >> If you don’t have something like that then SPI is probably the most reliable but be aware that you have to care a lot about the clock speed it uses so if the SoC changes clock speed for power saving it might make your clock speed wrong (I ran into this in the RPi4 for I2C). > >Yup, very hard to accomplish these timings for WS2812B with GPIO on >MCU, especially when some sort of RTOS + SDK is in use. Usually SPI or >RMT peripheral is used to generate these pulses with correct timings. >The smallest and cheapest MCU is AtTiny series but not much >peripherals. Also note that "bare" WS2812B needs 5V on the data line, >but WS2812B-MINI works with 3.3V data logic :-) > >On the other hand I found some "AURA LED Controller" on my >motherboard. It shows up as the USB Device: > >% usbconfig -d1.2 dump_device_desc >ugen1.2: <AURA LED Controller ASUSTek Computer, Inc.> at usbus1, cfg=0 >md=HOST spd=FULL (12Mbps) pwr=ON (16mA) > > bLength = 0x0012 > bDescriptorType = 0x0001 > bcdUSB = 0x0200 > bDeviceClass = 0x0000 <Probed by interface class> > bDeviceSubClass = 0x0000 > bDeviceProtocol = 0x0000 > bMaxPacketSize0 = 0x0040 > idVendor = 0x0b05 > idProduct = 0x19af > bcdDevice = 0x0100 > iManufacturer = 0x0001 <AsusTek Computer Inc.> > iProduct = 0x0002 <AURA LED Controller> > iSerialNumber = 0x0003 <XXX> > bNumConfigurations = 0x0001 > >Maybe this is the best generic way to support these leds over USB and >let some dedicated hardware (i.e. STM/ESP/whatever has USB) do the >rest? And maybe there is already some standard protocol? > >-- >CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > judging from https://openrgb-wiki.readthedocs.io/en/latest/asus/ASUS-Aura-USB/ these are simply uc's but yeah i can't choose one. there are tons of them. all that hw is too complex but i don't want to buy anything ready made either unfortunately if i want to max out the ws2812 features i need beefy uc. likely over usb. and run into same issues there too with having to use dma and whatever. it's fast enough data that one needs that eh. together with pcb, that uc costs some fraction of full sbc cost but that's fine. or maybe it's because bigger socs have gotten so powerful and cheap i wonder if i could use something with some actual open rtos in it so it would be understandable. or i could use some of that existing led driving code that's around what i image i will be doing is like make_data > frame.curr cp -a frame.curr frame.out led_bitbanger --data frame.out --device /dev/ws2812 --0-bit-high-time 350ns or so unfortunately in order able to get so simple, there needs to be ton of complex stuff below it. i image dma memory update part being like cp here if all hw would come equipped with realtime cores as standard issue, it would be easy i guess and likely would also need my first actual scope or logic analyzer so i can actually see what's on lines. dso138 doesn't help also, i tried to get hw spi working in h3 but apparently it won't work. if it would even help me. like unsure what speed uart apparently won't support those speeds after trial i actually have mpsse hw around, provided this possibly fake device even works as specified otherwise i have to get uc of some kind i don't know after all eh while there, i found https://cpldcpu.com/2021/02/27/the-transistorpixel/ https://github.com/cpldcpu/Gen2-Addressable-RGB/blob/main/docs/Gen2_ARGB_protocol_analysis.md and others so in the end i need uc after all system layout ideas i got from https://bitlair.nl/Projects/Ohm_led_strip_sleeves it was also awesome to look irl there they didn't have any local code at all. init / no signal was low intensity white in the end i did write ws2801 controlling code but now i have issue where i can't simply control it with ways i'm used to i heard about bad methods like disabling interrupts. what would it do? would it freeze the system for a moment? i mean there is nothing important running in that anyway. unless this also makes ssh unusable. all the even cheapest socs have multiple cores, so why it can't be running on it's own core? that would make my life simpler by not using extra hw. bbb actually allows it but somehow we don't like it here anymore yes, using uc makes me absolutely free. i can choose uc i want and connect it where i want, as usb and serial are everywhere. to be honest i could just use ethernet enabled uc but that doesn't feel so cool actually many those custom solutions pass the official stage lighting standards in fps. which is logical as dmx was never meant for this i actually don't have much interest in spending time sequencing stuff either kind of like, i want to run things on them. put them eg on a tree outside, connect them up, not having to think how many leds each controller got on it. tho, have to put power there according to led consumption. then take editor and start playing with values. like what happens if i send every 10th led an increasing value from 0 to 255, then decreasing from 255 to 0. update 60 times per second something like that
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?677E3CFD-91A4-4A46-AC15-1CAD49F891F5>