Re: addressable led driver

On November 14, 2025 6:56:55 PM GMT+02:00, Bertrand Petit <elrond@phoe.frmug.org> wrote:
>On Fri, Nov 14, 2025 at 06:21:12AM +0200, Sulev-Madis Silber wrote:
>> so i did read the chatgpt driver
>
>	Drop those bots, they are producing crap; use your own judgement
>instead, make errors, learn from them.

oh it's a tool. why i went there, was because i hated the amount of information i had to process

in this case, i was surprised. seems like it was generated from drivers. but from all of them. in 12s

i already said probably going to use real brain

btw that's second time i tried to generate code from there. many others use it all the time they say. to which i say what's the joy, quality and control

anyway, why that way is because i can't read all that. maybe i found wrong information. maybe kernel drivers are actually hard. reading fat books also don't work for me. reading drivers wears me out. maybe talking others helps. tried to ask in several irc channels if anyone wants to explain drivers also didn't get anyone's attention yet

i did write ws2801 driver from scratch so i don't really have problems with understanding that part

the problem is that my favorite language, perl doesn't just allow me to do nanosecond precision

i actually tried to pwm dim a led from perl too. this tool all the cpu in bbb and as fast as it went, still looked as if i could see it. i probably was seeing it

but turning to other languages and platforms is very hard. maybe if you have been in uni, you find it easy. i did all this on my own. i didn't go there because i hate people but amount also looks too much at once. i had this entire life. schools probably actually teach things in a way that not everybody gets it

anyway...

>
>> looks like drivers i read (where this info probably came from, including
>  spkr i didn't look yet), character device for data, ioctl for config,
>  bitbanging and sleep that i don't really get (binary math and cpus are hard)
>
>	Binary math is not as complicated as it sounds, it is, at least not as
>difficult as CPU programming. Directly programming CPUs is a difficult talk
>because before being able to do anything you need to absorb at once a large
>quantity of informaiton.

yeah and what if i can't do that, i installed 4.6. still can't do it now. went into embedded in 2013, still hard nowadays. electronics i did pretty much entire life, that's bit better. i'm 42. unless we extend life, i die before understanding of this. just can't

with trial and error, i was able to write lpt control program once. i hated the way that port was represented as address while i wanted to control pins

i had to use all << >> | & operators in c because i just didn't get how they actually modify bits which then cause hw to turn transistors on and off, resulting in voltage on port pins

meh i once had like gf who explained cpus to me but she ran away as i wasn't able to constantly deal with her or people at all

>
>> soc is h3, i don't know how well it keeps timings. it's ability to keep
>>  actual wall clock time without is bs. or is it it's rtc
>
>	Date and calendar computations is a set of hard problems; timekeeping
>is a very hard problem sitting on the frontier of electronics and physics. For
>dates, use external proven libraries, for the second, don't sleep, use
>hardware timers or those provided by an operating system.

forgot the "without ntp" here. but yeah, but what if i don't get it?

>
>> there's always option to go dedicated uc way and use (usb) uarts or usb
>>  direct
>
>	I don't know the problem you're trying to solve, you sound like
>chasing several foxes at the same time. Is it an ad-hoc development or shall
>it be generic? For the ad-hoc route, a microcontroller is probably the easiest
>solution. There are tons of libraries tackling the adressable led strips. Have
>a look at this introductory resource:
><https://learn.sparkfun.com/tutorials/addressable-led-strip-hookup-guide/all>
>
>	Make the microcontroller drive the LEDs *and* run the animations.
>Command the microcontroller actions from the main CPU with small infrequent
>messages.

i don't like the small messages. this would mean that it's fixed inside uc. and you at best write that in c. at worst in asm, which is horribly hard to get as you don't have any visible tools there. it's as if you have atoms when you need screwdriver. i bet you can make screw turning with them

if i go uc way i would need to put a dynamic wrapper there that i can command from "actual computer" i understand

even a puny cpu nowadays should be able to generate data in speeds that human eye misses. especially considering my screen resolution is like 32*32?

existing led projects are weird too. i don't want to use existing things as there's no fun taking code, flashing it and looking results

many run like displays and so on

i mean you can get dmx controllers for leds, but that's not fun either

it's not fun to poorly translate my ideas to c, flash into uc, see result

>
>> but what are realistic results i could get from direct control? i'm aware that somehow spi and dma could help
>
>	Use whatever is supported by the microcontroller you choose, RS232,
>RS485, I2C, SPI, etc.
>
>> i mean i could run out of real hw spis but those signals don't travel that
>> far anyway so maybe it's enough. my idea is not driving screen amount of
>> leds right now
>
>	I2C is a bus through which you can talk to several to several slaves,
>some SPI slaves can be daisy chained. Each slave microcontroller can drive
>several hundred LEDS. The limit would then be how well you synchronize the
>microcontrollers against each other.
>
>> if cpu speed changing would make it bad, could i lock it? would that cause
>> too much heat?
>
>	Again, don't sleep, halt instead and use hardware timers.
>

so, could i get some out of fbsd or not?

i already know uc's can do it. and i already know existing, eg, artnet proxys exist

seems too much for me

i want to do my own. unsure how. probably works. would work

but my idea was to do that direct

if i use uc, this isn't much of a fbsd problem anymore

unsure what's generic or ad hoc too, just want to play with those things

probably need to use faster serial than 115 too

anyway i wanted to skip this rube goldberg of serials and uc's and all those and go direct os control

but now i have issue. this is not realtime

actually i don't know how much i need. how accurate a bitbang would be. is nanosecond a issue? if yes, i can't use cpu indeed

i also totally hate how everything in cpu is somehow some "address". while i want to control some individual pin electrically

unsure how i sync multiple uc too, actually. i assume. and i have tried, that i should be able to send data via ethernet, via non-realtime os, out to hw fast enough that eye doesn't notice it

how many i need, no idea i plan to try out

but the original idea and question was, can you use fbsd and armv7 h3 to bitbang a ws2812 protocol? if no, no problem, i take a uc. if yes, how much, how fast?

i looked into gpio section of kernel and found several bitbang drivers. many seem fast. unsure what hw they need but i don't recall many amd64 machines with user gpio pins. so it must be for rpi class machines

so precision is there probably

if i go uc way, i want to be able to tell uc everything i want dynamically

just like with future fbsd driver

i don't know how. i don't want to program hw. i don't want that hard code. i find it sucks. it's too hard. it pisses me off. i want to make code so i don't need to touch it again. possibly need others because i can't figure it out

that's why i got llm involved at all. i was unable to read out from drivers, google, man, what i need

i know how that protocol works, it's in pdfs

i want to send that spec to driver or uc along with data

the wled kind of does that but i want my own way. it's not that hard even

also i realize there are different "sleeps". but i don't want to know them either. that much. it's mindboggling to get. all i want is nonaction for certain time. how cpu does that efficiently, no idea. chatgpt proposed asm pause. you tell me if it's bad or not. tried to google too. seems good? bad? unsure, maybe wasn't like that in those other drivers

it's also very hard to read drivers. i need to know c as well as all the other function names in order to read that like english. it took me ages to figure out the totally assbackwards way the drivers actually toggle a pin. it was complete wtf. i don't get any of this

and addresses again. sorry. i hate this. all the date about cpus is very hard and i can't read a single page of that

i don't know how many years it would take for me. i feel like i die first. looking the drivers, i could probably make my own driver which i then could share to get reviews. likely this gets it better as i don't get any of this

reading spkr was similarly hard. like don't get it at all. too hard

i don't know how to make my task happen

i just want to run things. except it's not how i want

getting leds is easy

actually maybe not

all i know is that led has a ic in it which turns short and long pulses into bits it then stores. it stores what it needs and rest it forwards out. there's extra reset pulse that's about 50 times longer, that's when it takes bits and puts them to it's second part, where it pwms the leds. supposedly it's all hw. which is fun. actually hw is sw and sw is hw so you can make this all happen in hw if you want. supposedly that led chip is elaborate shift register. but i don't even know what that is. i bet it shifts bits

i also don't get gates. i get it's circuit of transistors

transistor is bit easier. it's a switch. i don't like to think how quantum physically it works. i find it hard

actually i started coding on my own, i just used mirc.exe, it hard high level scripting language in it. so i learned that. didn't took any class on hw. and in 1999 it probably was too late as computers ran high level code already

anyway, i know how it it works

lets see:

bit_0()
{
gpio_on;
sleep 350ns;
gpio_off;
sleep 800ns;
}

bit_1()
{
gpio_on;
sleep 700ns;
gpio_off;
sleep 600ns;
}

reset()
{
sleep 50us;
}

while()
{
}

whatever

it's all so complex. i need to turn 1 byte into 8 bits. which is hard to get if you know that byte is number from 0 to 256 or 00 to ff in hex

and 128 is half of it

anyway i hate it all, i hate computers, i hate binary, fuck this

i never learn any of that. but that was not the point here even. i just wanted to simply send those pulses

but apparantly i can't send it but i need to massage hw the right way

so it's prohibitely expensive in my brain to comprehend the sheer amount to shit i need to understand in order to do this one simple task

and yes, the higher level the code is, the easier it is to read. because you can simply command the computer to do the task

so no idea how to do this. those existing led projects look bad. most use wifi, i would need extra ap for that, etc. and who needs complex, high latency or insecure things

if i want arduino, i would have used it. but i find it boring. or hard or. or fixed. or whatever

i just want to run code. on leds. i connect hw up. tell it what to do, it does it

unfortunately i first need to make something below this code before i can run the "real" code

and that's very hard. or i don't know

it's also like fun to learn but it gets hard fast. that's why i hated even school math

it's also harder if i don't get it

and i don't, i probably spend reading all that until i actually die

books won't work, reading drives won't work. unsure what works. it just gets me all pissed and nothing good happens

from what i somehow see, sleeping below 1us is next level task in kernel? i mean that is short time after all

oh well. but yeah, flashing fixed code into uc won't work for me

has to be better

anyway, of course if uc is only option, i will use uc. but hell with connecting to it. and it ALSO needs code. it won't just execute my task to turn voltages on and off

i bet that's why whole arduino happened too. people don't like to do hard tasks. i don't like arduino because it makes c harder than it actually is, tho

so i don't know what i do. i probably try anyway

i also spent ages of cursing on how to set gpioths and ow pins via fdt overlays. to me it was super frustrating. it's as long and complex path as it can get

actually there's nothing human readable in computers. but humans don't work in binary. at least easily

so yeah i hate it all. i don't understand it. i'm unable to find right information. sometimes i find it. no existing ones seem to work. i don't know how others did it

the sleep, pause, delay, noop, whatever it is that stops action for time period, it just causes me to have breakdown

yet drivers do it

that ths is much slower i see. in ms, while leds do us and ns eh

all i know is that iirc gpioths driver writer said that it should be possible to drive leds there

anyway, no idea what i will do. all is hard. existing is wrong. need to make own so it's better right and fits me. but i can't. i don't know how. all i have is some fet in some hw that i need to turn on and off in nanosecond precision in order to send data. i get that. on. wait. off. wait. repeat

just how to do that is wtf

so yeah seems like i can't read any driver because i don't get it

gpioths.c seems easiest but it doesn't have the sub 1us

anyway i don't have honest idea how to make it right. anything i read about big or small cpus quickly overwhelms me and i haven't found anything that doesn't

i understand that sleep is wrong term but to me sleep is a period of wait

just like sleep(1) sleeps. sleep 1 sleeps for 1s. i haven't looked how it actually "sleeps". same in kernel. i don't know how kernel "sleeps" while also "running"

in fact i don't even know what kernel IS. i consider it an elaborate while(1) { } loop that somehow has "subcode" "programs" in it. but it also has like interrupts which i don't get

i looked what ccc guys did for r0ket and it was a bit easier but still hard

anyway, i don't get it

i hope i don't need whole hw course for just gpio pin control

i don't know where the information i need is. often it's in form i don't get. i mean most of fbsd manpages are very well written

anyway i don't get this all at all now

might as well give up

at least in bigger computer it feels better. you can use actual tools. run actual code. without all that hw. if it were slow task, it would be already working

just look into gpioctl -l, it even has names in case of h3. even if no, it would be possible to find which is which

once you find it, it's easy, then you find a hw pin

and you could even write shell script for toggling that

then comes the big issue. you can't shell script the ws2812

it's too big and complex os there

in uc you can do that but you don't have tools anymore. the tools you have are so primitive that you don't even recognize them. but you can have precise control eh

i hate that

so i had idea. even if this only controls small amount of leds. to make a driver. so i can shell script a ws2812. tell it pin, timings, and just give it data

if os kernel really sucks at it, i would need to tell uc it. actually the wled project is pretty much it. but i want my own

i also attached the files that the mechanical marvel of the ten thousand gpus (or fuck knows which *pu's), created for me. it builds. it looks like normal driver for me. had to fix wtf's and probably it has many more

files here are direct tho, without any fixes

but you have to admit that ability to read *AND* compile gpu "pipe dream" is wonderful. even if it sucks

also it probably got it from human written fbsd drivers

i was curious if it can

i have no idea why char dev was created. or ioctls. didn't ask

if that was wrong, well what's right then?

i mean if i could, i could write driver on my own. but i can't. i don't understand it all

i give up

now, of course, i don't know if that approach works. god knows where it eve came from. it's not in fbsd drivers i saw. linux drivers? nowhere? that's the power of llm as well. creates thing from thin air. it has no "logic"

i mean i agree i should make driver myself. just like all other code i made. but it's too complex. maybe kernel driver interface itself needs improvement. maybe it can't be improved. maybe i will learn it, maybe i won't

in any way, i don't feel like any learning has been happening and i only get angrier

i looked into drivers and couldn't figure out the one which i can base my new code upon

and in uc it's also hard. have to receive it somehow from some port, then send out. all at same time. i hate to think of memory and stuff there too

that's why i wanted to skip all that hard work

but maybe i can't

so yeah, in sbc soc it's easier, it's also complex. costs 10+ times the uc. has poor timing. but has all my familiar tools

whatever. can't blame me too much for trying to move freely in big room, instead of small uc box where i as if constantly hit myself to walls and hurt myself

maybe people get even worse on this. who knows

if i have spent like large parts of my life to learn this, i don't think i can ever

if i complete my driver i'm like phewww i hope i never need to touch it again and can return to my normal life of doing things

i don't know, i did ask from led lighting communities too, they didn't get me either. but there most people know even less code

i want some middle ground here

i'm not that stupid either

i want to run most of stuff in "actual machine". which are small and cheap now

i'm not arguing if it physically can't be done. but i hope it can

the bbb pru idea is nice but bbb seems to be in sorry state now and new 64bit ti socs don't have support yet iirc?

price did fall tho

or i could do soc+uc

but i don't like to code, and i don't like to disassmble hw to flash it. it has to be possible from os. one could view this as extra realtime core

anyway i don't even know what realtime even is. i view it as something that works fast and doesn't jitter around and skip a beat

the ti pru looks cool tho. i did read it shares memory and you can put code there somehow. unsure how. it has no flash so it somehow takes code from host, live

separate uc is harder. more secure but i don't really see someone hacking me that way. they have physical access anyway

so yeah, i get that you could connect all uc pins to soc and then hopefully you can reset and flash it

i also don't like to disassemble things for upgrades, that part works already

unsure what i'll do. the beagle stuff is just one hw too and i want to have more diffrent hw's maybe

so i don't know, maybe soc+uc is best if just soc sucks

i mean this is hobby now but who says hobby can't be professional quality

anyway i hate the hw. i actually tried to create hw from chatgpt too, for fun

it actually wasn't possible before. but now you can hallucinate yourself a non-working pcb

that job is hard too. i mean i know how my circuit would look like. electrically i would have working schematic in my head but now comes the hard part of making it

i wish i could just say, this wire goes here, that one goes there, this protection diode goes here, and so on. make it into 3d model and i'll take a look if it's ok to me

then make it. i don't want to draw schematics, route. make gerbers, gcode, whatever. i just want the object, working

same with led driving software

i don't want to write driver at all

i just want to control it. i have parameters, they are supposed to work, so i want to try. unfortunately i can't as i have the tool somewhat missing

oh and turnkey is too boring

actually my ws2812 / sk* whatever string came with cheap bt controller and app but seems like they wrote bad code or chose bare minimum uc, because i see freq with my eyes

to my knowledge, you can't see ws2812

i'm aware that there are faster ones with higher local pwm and also update speed

but i've seen displays running on ws2812 and it's probably controller issue

so i don't know. original idea was kernel driver for single line and perhaps also clock+data leds

you tell me how many could various hws drive. i hope answer is not 0

the uc way would be unfortunate but if it's needed, it would need to be seamless. maybe some bootloader or loaded fw or code or whatever

the visible result would be like running multicore or multi cpu machine, you never mess with it, you don't flash the cpus, you don't code for them, code just runs. on the below, i don't know how it works, way too hard. i tried to get how smp works but i can't

well probably could use existing components too. i mean i didn't write fbsd either. but many of those are weird

like, you need to define pins, hardcode led number, so on. who needs that. even hardcode animations, not my idea, i want to change them

i mean several places sell bridges too but those don't seem fun. like i need more hacking. but not too much?

whatever. it's either wrong or i don't it or what else

if fbsd driver could work, that would be my favorite

fun to think, maybe it could be implemented as kind of video output. even tho it's slow and small

tho, some of those projects actually treat them as screens. i've seen uc's synced via gpio's. never looked how it worked. that thing also received data from "computer"

i mean uc's are not bad per se. but they are hard to use. always have to use computer at side to run actual code in, etc

lots of more freedom there, i can run every language i want

in my usual things i often run shell+perl+c combinations with complexity going from left to right

but unfortunately if i put c into uc, it's much harder to "stdio pipe talk" with it. this makes it difficult. don't like difficult

or maybe in some other way i like i difficult because i don't like other ways

maybe i did born too late no idea. used computer, immediately coding in high level language. now i want to turn everything into similarly higher level so i could understand it eh. that means showing "realtime" stuff away and just giving it the data

but isn't that the idea of os too? if i touch the file abc, i don't want to perform tasks nor do i want to know how it actually gets all those bits into fs and into physical device

so maybe not that bad idea to abstract the hw

i looked into gpiospi but unsure how it works. spi userland util exists too but even that looks not up to my task

i mean this is now spi at all

and gpioths seema like 1000 times slower than i need. 1-wire is also slow. it's all slow

the gpiospi and gpioiic feel like they must be faster but in that code, i didn't even see how they sleep (call it whatever you want)

so in the end i have nothing...