<d1b2>
<Attie> i have a question regarding status / indication LEDs on add-on modules...
<d1b2>
<Attie> it seems that no applets i've come across yet have support for status / indication LEDs
<d1b2>
<Attie> is this a concious design decision, or just how things have turned out?
<whitequark>
latter
<d1b2>
<Attie> if (for example) the CAN applet had support for LEDs on the standard ports, would that be okay?
<whitequark>
it would be kinda weird
<d1b2>
<Attie> ... this is more out of interest, @electronic_eel has already talked me out of them
<d1b2>
<Attie> re "it would be wierd", yeah after thinking about it i agree...
<whitequark>
i think LEDs on addon modules make the most sense when they are directly connected to something on the module
<d1b2>
<Attie> yeah, that's the plan here... shift them off dedicated LED signals, and on to the Tx/Rx signals
<whitequark>
sounds very good to me
<d1b2>
<Attie> original thinking was that (at least for the Rx LED), we could only blink if the message was valid / matched a filter, rather than lighting for all traffic
<d1b2>
<Attie> but... that's actually potentially very misleading
<d1b2>
<Attie> a second question... do you have any visibilty on multiple applets?
<d1b2>
<Attie> specifically, wheter each applet would get a whole port, or potentially individual pins assigned
<d1b2>
<Attie> i'd imagine the latter, but just checking if there's something i'm unaware of that might enforce the former
<whitequark>
well
<whitequark>
right now we don't have multi-applet support at all
<whitequark>
and it would require considerable amount of refactoring to get anywhere
<whitequark>
as a stopgap, if you want a "double CAN" applet, i suggest you basically duplicate the subtarget
<d1b2>
<Attie> yeah, this is more of a "looking forward" question - given your comment on refactoring, i guess if there was a limitation it would be taken care of (re ports vs. pins)
<whitequark>
or hell, just have the hardware support two ports but the software one
<whitequark>
well
<whitequark>
i think having each applet manage the port voltage at all times (like we have it now) is kinda dumb
<whitequark>
the cases where applets should power cycle anything are really rare, and we would be better off supporting them explicitly
<whitequark>
e.g. "device.claim_port_regulator" or something, like "claim_interface"
<whitequark>
most of the time, there should be a constraint solver thingy where the CLI looks at the available applets and their voltage requirements
<whitequark>
so: you can assume that multi-applet support would not have "port per applet" as a hard requirement
<d1b2>
<Attie> ok, great... i suspected you'd say something like that!
<d1b2>
<Attie> thanks
Getorix has quit [Ping timeout: 246 seconds]
Getorix has joined #glasgow
Stormwind_mobile has joined #glasgow
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #glasgow
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter_ is now known as PyroPeter
d1b2 has quit [Remote host closed the connection]
d1b21 has joined #glasgow
d1b21 is now known as d1b2
<_whitenotifier-f>
[GlasgowEmbedded/archive] electroniceel pushed 1 commit to master [+1/-0/±0] https://git.io/Jkrg6
<_whitenotifier-f>
[GlasgowEmbedded/archive] electroniceel 6446eff - G00059: INA233 ADC/Current measurement IC that is used on revC2
<electronic_eel>
whitequark: about the firmware code structure for the new adc. i think it would make sense to rename the current adc.c to adc_adc081c.c and create a new adc_ina233.c
<electronic_eel>
the question is how to call the different functions from main. do you prefer simple ifs in main or do you want function pointers that are initialized once?
<whitequark>
ifs are just fine
<electronic_eel>
i think for now ifs are easier to implement as there are just a few calls. in the long run code size will be an issue, so we'll probably have to move to ifdefs anyway
<whitequark>
there will be one firmware
<electronic_eel>
...as long as everything fits in it
<whitequark>
if we run into code size issues i'm going to look into getting sdcc to generate less awful code
<whitequark>
by, most likely, feeding it more awful input
<whitequark>
there's a lot of places where we really don't let it do a good job, too, like LED manipulation being implemented as functions
<whitequark>
by declaring those with a callee_save pragma or turning them into macros we can probably save quite a few bytes
<whitequark>
(just one example)
<electronic_eel>
for now the input looks like regular c for small mcus, so it is manageable. but before we have to move to asm, i think i'll prefer different firmwares for different revs
<whitequark>
i don't think we need to move to asm
<whitequark>
what we can do is (a) use fewer functions, (b) use less deep call stacks, (c) use more globals
<whitequark>
the root cause is that i wrote the firmware as if i was using a C compiler with IPO, but sdcc is a C compiler without IPO
<whitequark>
i knew that at the time, and the solution to code size problems is not #ifdef hell (and flashing hell, and uploading hell, and distribution hell) but simply making the C code in the firmware worse
<electronic_eel>
yummy spagetti code with goto-sauce
<whitequark>
you don't even really need gotos until we're down to shaving individual bytes (which i don't think we'll ever reach)
<whitequark>
i spent quite a while experimenting with sdcc while optimizing some stuff for nrf24le1
<electronic_eel>
ah, ok, they are 8051 too
<whitequark>
including an almost-fully-USB compliant flash bootloader for lu1 that fits into 512 bytes
<whitequark>
(it's even relocatable! did you know relocatable code for 8051 is possible even though it has no position-independent instructions and no way to read PC?)
<electronic_eel>
cool. i've used a usb bootloader on atmegas that barely fits into 2 kb, but with software usb (v-usb)
<whitequark>
most of that bootloader (except for dual DPTR copy functions) is in C because, as it turns out, sdcc is pretty okay turning switch/if decision tree spaghetti into passable assembly
<whitequark>
see the stuff in main()? it was neither necessary to rewrite that in asm, nor possible to get nontrivial gains, based on my experimentation
<whitequark>
it's not even far from idiomatic C
<hl>
that reminds me. what toolchain does silabs ship for their 8051 MCUs?
<whitequark>
this is why i think we should start by trimming the fat from the current fx2 firmware (which has so far never taken code size into account) before thinking about #ifdefs
<electronic_eel>
yeah, i'm not contending that, for the time being one firmware should be fine
<whitequark>
electronic_eel: avr is a lot denser than 8051, i think
<whitequark>
i haven't used them in close enough succession to compare, but the amount of accumulator fiddling in 8051 is unmatched by anything more recent
<electronic_eel>
yeah, but having true usb hardware is still much preferable to a software-only stack
<whitequark>
(who said CISC is good for code density...)
<whitequark>
oh sure
<whitequark>
i've worked with v-usb
<whitequark>
marvelous piece of work, but it does take some liberties with the spec
<electronic_eel>
all this irq fiddling to not interfere with the actual work the mcu has to do...
<whitequark>
i tried to do a PS/2 converter based on V-USB
<whitequark>
couldn't do because of said IRQ fiddling
<whitequark>
that said, it was one of my first embedded projects. i'm sure i could do it today
<electronic_eel>
in the end i got it to work, but it took much longer and much more tries than anticipated
<whitequark>
yup. with the cost of AVR, probably makes more sense to use two of thos
<whitequark>
this is kinda what unojoy does, i think
<electronic_eel>
no. use one stm32. the cost of avrs has gone up steeply, while e.g. the stm32f030 is really cheap
<whitequark>
i meant in the period
<whitequark>
that was before stm32
<whitequark>
in my case at least
<whitequark>
i jumped on the stm32 train as soon as stm offered free stm32vldiscovery to anyone who signed up
<electronic_eel>
yeah, in my case too. they were too expensive back then and the toolchains not as well worked out yet
<whitequark>
... and now i'm writing 8051 code lmao
<whitequark>
mostly because i really don't want to be programming stm32's in C, and all the rust stuff is kinda immature
<whitequark>
i were to program them in rust i would have to start with basically crt0 and SVD, since much of the current rust tooling is just... bad
<whitequark>
(well not crt0. rrt0? you get the idea)
<electronic_eel>
hmm, but you are writing 8051 code in ugly c. you could write nicer c code for stm32, better compiler and more flash
<whitequark>
and orders of magnitude more effort to do anything
<whitequark>
i wrote a chip support package for FX2 in 2 or 3 days
<electronic_eel>
but on the other hand it is fun being able to squeeze the max out of such small code sizes
<whitequark>
i don't trust anyone else's chip support packages for stm32, so i would have to make my own, and i already know exactly how much effort that takes with the incredibly rich peripherals on stm32
<whitequark>
(well, it's less "don't trust", and more "i've participated in the making of the sausage and i know just how bad it is")
<electronic_eel>
at least you don't want to use the cubemx stuff from st
<whitequark>
yep
<whitequark>
i think just about everyone agrees that svd2rust is kind of bad
<whitequark>
but the thing-that-comes-after-svd2rust doesn't exist
<electronic_eel>
but there are some open alternatives, like libopencm3 or the chibios hal (this is what i use)
<whitequark>
meh
<whitequark>
i've helped enough people debug libopencm3 issues to know i don't want to use that
<jpa->
chibios and libopencm3 are two of the best STM32 libraries, but nowhere near perfect
<russss>
heh
<whitequark>
i haven't encountered chibios yet, so i might look into that
<russss>
I quite like chibios but rust has spoiled me now and I kind of don't want to program anything in C ever again
<whitequark>
but so far i'm quite convinced that the only level on which i want to program stm32's is register access level
<whitequark>
(or any other cortex-m for that matter)
<jpa->
and a small bunch of C code is easier to maintain than a big bunch.. especially STM32 USB driver's i've had some bad experiences with
<russss>
yeah I started using chibios because it makes the USB stuff vaguely bearable
<whitequark>
in any case the arm thing i'll probably next have to support is fx3, and that just has nothing going for it
<russss>
but IMO the rust STM32 USB stuff is miles better, even though it's still getting started
<whitequark>
(i should probably start looking for someone to pay to convert the docs into an SVD file)
<whitequark>
and that isn't even a cortex
<hl>
i have no JTAG tooling and designed, built and assembled my own STM32L4 board, then used the USB DFU bootloader in its ROM to program it from scratch, writing all my own headers and not using any CSP. totally viable
<whitequark>
yep
<whitequark>
i'm not saying i *can't* do it. i know i can. i just don't feel like doing it
<jpa->
it's also funny how STM32 still doesn't have any usb 3.0 superspeed stuff; could be a reasonable alternative for FX3 otherwise
<whitequark>
how do you process ~Gbps on a cortex-m?
<jpa->
STM32H7 can move around 200MByte/s with DMA quite comfortably
<whitequark>
hm
<whitequark>
okay, point
<hl>
jpa-: huh. do you know the figure for a M4?
<electronic_eel>
even their stm32mp1 mpu doesn't have usb 3 or pcie, i think either they don't trust their internal busses enough or they have problems with the required analog ip
<d1b2>
<daveshah> WCH have claimed 3.8Gbps with the DMA on their RISC-V based USB3 chip
<d1b2>
<daveshah> but the docs on that are still pretty thin on the ground
<jpa->
actually, 200MByte/s when i'm doing simple snappy compression on QSPI -> CPU -> USB, should be twice that if it was just directly to USB
<jpa->
hl: no, it depends on a lot of things like the bus structure, DMA controller and bus frequency
<hl>
ah
<hl>
anyway, someone clue me in. What situation are you even considering using an STM32?
<hl>
Glasgow? How would you integrate/connect it with the FX2?
<whitequark>
we were discussing "what to do if avrs are too slow"
<whitequark>
nothing to do with glasgow
<hl>
ah
<jpa->
in case of glasgow, it would probably be in place of FX2; but yeah, as is it doesn't make much sense
<electronic_eel>
there is no stm32 that easily beats xfer speed of the fx2
<whitequark>
or the simplicity of the USB interface for that matter
<electronic_eel>
so the fx2 is quite a good match for the needs of Glasgow
<jpa->
there is no STM32 that beats FX2 transfer speed, because they are both capped by USB2; there are STM32's that have much more buffer memory (1MB internal SRAM in STM32H7), which can help in some cases
<jpa->
but yes, i agree that FX2 seems the best option for glasgow
<jpa->
and if there ever is a reason to upgrade, it should be pretty easy to do it in a compatible way by keeping the same USB protocol
<whitequark>
it seems likely that the iCE40 FPGA will go out of production earlier than the FX2
<electronic_eel>
but that should be easier to replace, by an ecp5 for example
<whitequark>
FX2 is one of the most popular (if not *the* most popular) USB interfaces ever made in the entire history of USB
<d1b2>
<daveshah> I don't think iCE40 is going anywhere soon either though, Lattice are probably at least 1-2 years off a credible replacement being readily available
<whitequark>
yeah
<whitequark>
the FPGA is easier to replace arguably, all we need is a yosys and nextpnr port
<whitequark>
with minimal board level changes
bvernoux has joined #glasgow
kmehall has quit [Read error: Connection reset by peer]
kmehall has joined #glasgow
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] electroniceel pushed 1 commit to wip-revC2-firmware [+2/-1/±3] https://git.io/Jkonj
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] electroniceel f55a794 - firmware: rename adc file and functions to prepare supporting the INA233 ADC too
<electronic_eel>
do you believe in yellow or green?
<Lofty>
That scans to "life after love" pretty well
<electronic_eel>
Lofty: i don't think TI thought about this when writing this masterpiece
<d1b2>
<daveshah> It's now entirely permissible that they change the behaviour between batches
<electronic_eel>
oh, yeah, a lawyer wrote it. they should have confused the register addresses as well, just to be sure that no one can sue them for anything
<d1b2>
<Attie> I'd go for green... because the diagram seems to match (if I'm reading through the blur correctly)
<d1b2>
<Attie> but the best way to find out, is to test it!
<electronic_eel>
the logic analyzer confirmed green, but i read the yellow text first and was a bit confused what my code was doing...
<d1b2>
<Attie> doh
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] electroniceel pushed 2 commits to wip-revC2-firmware [+1/-1/±5] https://git.io/JkoMb
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] electroniceel 5cc8014 - firmware: implement voltage reading for the INA233
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] electroniceel f448508 - software/glasgow/device/firmware.ihex: change to symlink (DO NOT MERGE THIS INTO MASTER!)
<whitequark>
if i had a nickel every time a commit with "DO NOT MERGE" appeared in master...
<sorear>
homu-like setup, but all it does is check commit messages
<electronic_eel>
whitequark: why do we have iobuf_get_alert() in the firmware (adc.c)? it reads what is currently configured as limits in the adc. wouldn't it be easier to just store this in memory than reading it out of the adc every time?
<electronic_eel>
the "DO NOT MERGE" commit is there to make it easier for others to test my branch. they'd have to manually copy over the firmware without the symlink, this is not really obvious
<electronic_eel>
so i thought it would make sense to add it. maybe esden, timonsku, greg davill or others with a revC2 might want to check it out soon
<whitequark>
electronic_eel: then that will be wrong if you reload the firmware
<whitequark>
regarding copying the firmware: `make -C software`
<electronic_eel>
sorry, i don't get what is wrong with the firmware upon reloading
<whitequark>
if you store it in memory, it reinitializes .bss or .data
<whitequark>
the idea behind iobuf_get_alert() being written as it is was to return the actual alert values no matter what happens, rather than returning a potentially wrong cached value
<electronic_eel>
do you think there is a risk of a wrong cached value if we init the limits on reset?
<whitequark>
i don't think about it, i simply don't use caching so returning a wrong value is fundamentally impossible
<electronic_eel>
i can of course copy that behavior for the ina233, was just already thinking about code size reduction
<electronic_eel>
but we can do that if we hit the limits
<whitequark>
exactly
<electronic_eel>
so, back to the firmware loading. sorry, but i still don't get what the problem is
<whitequark>
which of the problems we just discussed?
<electronic_eel>
" then that will be wrong if you reload the firmware" and "if you store it in memory, it reinitializes .bss or .data"
<electronic_eel>
maybe i'm missing something obvious or using it wrong
<whitequark>
if you store a cached value in memory and then do `make load` then the cached value will be overwritten by the CRT init code
<whitequark>
if you update the limits on reset, then that's not really a problem
<whitequark>
but i don't write firmware by making one part fragile and another part in a way that doesn't break the first one. i write firmware that doesn't have this fragility in first place when it's straightforward to do (and in this case it is)
<whitequark>
or in other words: if there is potentially a single source of truth for some sort of data, then i always use that
<whitequark>
because it means that there is no way stale or incorrect values would be returned
<electronic_eel>
ah, ok, i totally misunderstood you. i thought all your comments were about me symlinking the firmware file and that causing wrong load behavior, while you were talking about my question re limit caching
<whitequark>
ohhhh
<whitequark>
oh nope i think we should just make the symlinking redundant
<whitequark>
the current behavior is low-key developer-hostile
<electronic_eel>
what do you have in mind re the firmware file? i guess you don't want sdcc as a requirement for regular users
<whitequark>
hm
<whitequark>
wait, why can't you just update the ihex file in the same commit as any other changes?
<whitequark>
`make -C software` then git commit with the sources
<electronic_eel>
hmm, ok, so each of my commits would have a different blob?
<whitequark>
yup
<whitequark>
that makes bisecting easier too
<electronic_eel>
hmm, i guess in the end we'll squash the commits before merging?
<electronic_eel>
otherwise it would add a lot of bloat
<whitequark>
not really
<whitequark>
i mean, squashing is fine if it's useful for other reasons
<whitequark>
but the firmware is not really significant in any way in terms of overall git repo size
<whitequark>
like, our git repo (with all submodules) is currently 146M. if your commits (which happen once per hw iteration) add uh... 300k (assuming 10 commits with uncompressed fx2 ihex, which is not even the case), that's nothing
<whitequark>
66M without the submodules. probably kicad's fault
<electronic_eel>
we are loading the firmware from python code, we aren't limited there to what make allows. so how about this: check if there is a glasgow.ihex file in the firmware folder that is newer than the firmware.ihex in the device folder. if there is a newer file, load that instead
<whitequark>
no
<whitequark>
python code shouldn't look outside of its root, because it's supposed to be a package
<whitequark>
it used to look outside of its root during build (in build_ext), but that was super fragile
<whitequark>
if we change anything, then we should get rid of firmware/glasgow.ihex entirely, and only have an ihex file in the python root
<whitequark>
but i don't see why we can't just update the blob in each commit
<whitequark>
oh and i especially don't like the idea of comparing mtimes and then silently acting on that
<whitequark>
that's just more potential fragility to fix existing one
<electronic_eel>
ok, you are right with the mtimes, git actions can confuse them
<whitequark>
updating the blob in VCS lets other people check out the firmware easily, like you said would be handy
<whitequark>
btw, if you update the API level (you should), then they won't get a silent failure either
<whitequark>
it doesn't solve the problem of people using `make -C firmware` when they should do `make -C software`, which is a much smaller one but maybe still worthy of attention
<electronic_eel>
it was confusing to me at first why my newly built firmware sometimes wasn't loaded, but instead an old one. so i think we should still consider just having one file
<whitequark>
I tried doing that but it requires changing fx2rules
<whitequark>
maybe later
<electronic_eel>
ok, it is not really a critical issue. updating the ihex with each commit will also work
bvernoux has quit [Quit: Leaving]
<whitequark>
re <WillC> Can I dump a PIC with the glasgow?
<whitequark>
yes, but also probably no (assuming 8-bit PICs)
<whitequark>
PICs are totally nuts. I think we estimated with marcan that they use at least ~200 different programming algorithms
<whitequark>
compared to 9 used by AVR, which is already obscenely many
thaytan has quit [Ping timeout: 240 seconds]
<d1b2>
<DX-MON> that sounds like a challenge to me XD but then.. I don't need yet another project for now as tempting as it'd be to add support for the PICKit2/3's interface to Glasgow along with logic for at least some PICs