Re: addressable led driver

On November 17, 2025 6:16:03 AM GMT+02:00, Bertrand Petit <elrond@phoe.frmug.org> wrote:
>On Sat, Nov 15, 2025 at 05:44:32AM +0200, Sulev-Madis Silber wrote:
>> 
>> i don't like the small messages. this would mean that it's fixed inside uc.
>
>	Design your protocol so that you can load "lighting setups" with some
>messages and swtich from setup to setup with more messages. The idea is to use
>each ICs (CPU & µC) for what they are good at.
>

i could do also that. most do that. load and play

but live proxying isn't also unheard of

in the end i probably attempt to do that in non-realtime os that a fbsd is. even if just one led. but then move off to some uc. unfortunately joys of big computer comes with this drawback and realtime cores are only in few socs

was also told to check sbc's paired with fpga's which is option but it's huge overkill and expensive here. i'm not making artificial sun here

but, i mean, transmitting <1mbit/s data stream over wired network isn't something that's big nowadays

i find it funny that we have complete dmx to led controllers in single chip. yes, i was surprised, rs485 a & b go into pins and just bare led is driven from others... yet noone wanted to create translator asic that could be sold along leds. maybe uc's took over or so. you did get them for 1-wire funnily. maybe it also had hw reasons

in the end i would still like more ability to run what i want in "actual machine". the only issue is that i wanted to have led nodes also have fbsd in them which they could have, they just need extra "realtime coprocessor" somewhere

and also whole thing isn't that crazy. 20y ago i thought many things around "computers" weren't possible, yet here we are

but in the end how sad that bitbanging 200ns pulses out of gpio isn't actually possible. i hoped i could. plus precision. was told gpio latency itself could be xxxns. indeed. and other bitbang drivers simply do slower stuff as it seems. gpiomdio tho?

so i guess that concludes the "fbsd" part of that story