<whitequark[cis]>
(sorry, had to be away for a bit)
<Attie[m]>
hi again Catherine
<Attie[m]>
i'll need to go soon too unfortunately
<Attie[m]>
I don't know enough about Nix to really weigh in here, and I wanted to read up on it before discussing... but I've had three weeks and been swamped with other stuff
<Attie[m]>
I presume that the nixpkgs= line is somewhat equivelant to a docker container? (i.e: stuck in time, comes with everything built-in)
<Attie[m]>
not sure how that's better / worse than us holding a container with the toolchain pre-installed(?)
<whitequark[cis]>
yep
<whitequark[cis]>
Attie[m]: us? I don't want any the Glasgow org to store Docker containers though
<whitequark[cis]>
the Docker based solution builds on top of a container published by Debian
<Attie[m]>
that's fair... but "us" -> hub.docker.com/.../sdcc (maybe) vs. github.com/NixOS/nixpkgs
<Attie[m]>
the images are held somewhere
<whitequark[cis]>
nope they are not
<whitequark[cis]>
please take a closer look at the script
<whitequark[cis]>
it takes a base Debian image and installs sdcc and everything else there every time it's run
<whitequark[cis]>
sorry, I was unclear. I mean that there are no customized images
<whitequark[cis]>
the entirety of the image customization process on top of a base image is in that script and it runs every time
<Attie[m]>
granted - but it doesn't have to(?)... just like that setup has been pushed into the nixpkgs, it could be pushed into a docker image(?)
<whitequark[cis]>
huh?
<whitequark[cis]>
what do you mean pushed into the nixpkgs?
<Attie[m]>
i'm quite possibly missing something, as above I don't know Nix well enough... but right now, I don't see A vs B as a particular benefit
<tpw_rules>
hi, i posited the idea so hello
<whitequark[cis]>
the Docker-based script and the Nix-based script work exactly the same way conceptually
<whitequark[cis]>
the main difference is that with the Docker script, the result is less reproducible because we do not store toolchain images
<Attie[m]>
o/ twp_rules
<Attie[m]>
yes, understood
<whitequark[cis]>
(Debian could potentially upload new versions of sdcc within a release, though they've never done that before)
<whitequark[cis]>
whereas the Nix script is guaranteed to be actually reproducible
<Attie[m]>
but those images are stored somewhere for Nix, yes?
<whitequark[cis]>
not exactly
<whitequark[cis]>
the binary artifacts are cached, but if you did not have the cache, Nix would build everything from source
<tpw_rules>
(the hash points to the source build instructions)
<Attie[m]>
i just looked into that tarball... i see things a bit more clearly now
<Attie[m]>
... interesting
<Attie[m]>
If an sdcc docker image was available, then I'd stick with no preference... Nix is indeed a nice looking solution
<Attie[m]>
like all things though, the sources are spread far and wide, so there is still potential for our "reprouducible builds" to break one day if we loose the caches
<Attie[m]>
I'm a squirrel at heart, and like to "hold" things like toolchains for myself
<Attie[m]>
(but I understand why it's not desirable to start holding and maintaining an sdcc docker image, for example)
<whitequark[cis]>
Attie[m]: Nix mirrors sources too
<Attie[m]>
ah, I wondered if that might be the case... the mirror:// prefix, etc...
<tpw_rules>
it's also possible to pull what nix gets out of the store and archive it (recursively too)
<Attie[m]>
yeah, sensible... but needs to happen, and then we're maintaining an image all of a sudden
<whitequark[cis]>
on the whole, I think the Nix solution is more likely to survive
<Attie[m]>
.. "image"
<whitequark[cis]>
because Docker has previously shown that they are willing to boot off OSS tier projects
<tpw_rules>
well that's a personal choice, not a project choice
<Attie[m]>
shall we go for it?
<whitequark[cis]>
we can I think
<whitequark[cis]>
I kind of like it
<Attie[m]>
yeah, looks nice enough - and i've heard lots of people shouting about it :)
<whitequark[cis]>
cool :3
<tpw_rules>
there is a little bit of robustification that can be done though it would make things a bit uglier. i can submit a PR for it next week
<tpw_rules>
(as in two days)
<whitequark[cis]>
tpw_rules: was about to ask! which kind of robustification?
<whitequark[cis]>
I like how concise and clear the current script is
<tpw_rules>
1. add the sha256 of the tarball which will make the local cache more effective 2. call directly into nixpkgs instead of using nix-shell magic -p as that could in theory change. i'll submit a PR for how it is now and then add those as a comment and we can decide there. i like how it looks now too
<Attie[m]>
thanks!
Lord_Nightmare has quit [Server closed connection]
Lord_Nightmare has joined #glasgow
feldim2425_ has quit [Server closed connection]
feldim2425 has joined #glasgow
jstein has quit [Ping timeout: 255 seconds]
balrog has quit [Quit: Bye]
balrog has joined #glasgow
joerg has quit [Ping timeout: 246 seconds]
joerg has joined #glasgow
esden has quit [Server closed connection]
esden has joined #glasgow
trh has quit [Quit: weg]
trh has joined #glasgow
cyborg_ar has quit [Server closed connection]
cyborg_ar has joined #glasgow
artemist has quit [Server closed connection]
artemist has joined #glasgow
notgull has quit [Ping timeout: 240 seconds]
notgull has joined #glasgow
nyanotech has quit [Server closed connection]
nyanotech has joined #glasgow
notgull has quit [Ping timeout: 260 seconds]
notgull has joined #glasgow
RaYmAn has quit [Remote host closed the connection]
RaYmAn has joined #glasgow
RaYmAn has quit [Remote host closed the connection]
RaYmAn has joined #glasgow
jstein has joined #glasgow
bvernoux has joined #glasgow
ar-jan has joined #glasgow
ar-jan has quit [Ping timeout: 255 seconds]
ar-jan has joined #glasgow
notgull has quit [Ping timeout: 246 seconds]
notgull has joined #glasgow
nemanjan00[m] has joined #glasgow
<nemanjan00[m]>
What is the endianness of amaranth generated core? I want to transfer 2 byte number and I do not know in which format I should decode/encode it
<whitequark[cis]>
Amaranth does not have endianness as such
<nemanjan00[m]>
If i do reset=26, what does that decode to?
<nemanjan00[m]>
Ok, 26 is stupid example, what does 511 decode to?
<whitequark[cis]>
that's not any different
<nemanjan00[m]>
How should I send it to applet?
<whitequark[cis]>
it depends on the applet code
<nemanjan00[m]>
Let's say I have Signal that fits 2 bytes and I want to fill those 2 bytes in, I set r_en to 1, wait for r_rdy to be 1, make that signal eq(r_data), now I wait for r_rdy to be 1, again, should I just shift Signal by 8 bits and add r_data to it?
<whitequark[cis]>
yeah
<whitequark[cis]>
whichever direction you shift and concatenate determines the endianness
<nemanjan00[m]>
Yeah, but if I decrement that number, how does it decrement it? It treats it as big or little?
<nemanjan00[m]>
To convert int to byte array in python, I need to choose endianness
mats1 has quit [Server closed connection]
mats1 has joined #glasgow
<nemanjan00[m]>
Ok, nvm I searched code and I saw you use little as param for int.to_bytes
<whitequark[cis]>
again, this is entirely dependent on how you use shifts and concatenations when you build the applet FSM
<whitequark[cis]>
you can make it big or little endian
<galibert[m]>
Or weird endian
<whitequark[cis]>
just by doing m.d.sync += buf.eq(Cat(buf, out_fifo.r_data)) or m.d.sync += buf.eq(Cat(out_fifo.r_data, buf))
Wanda[cis] has joined #glasgow
<Wanda[cis]>
<del>we use little by default because we're all littles here</del>
<whitequark[cis]>
if you increment a number it is done arithmetically
<whitequark[cis]>
but yeah Wanda is right
<galibert[m]>
Wanda: my MD tells me I should try for littler
<nemanjan00[m]>
If I do m.d.sync += num.eq(num + 4096), how will it treat num?
<whitequark[cis]>
as a number?
<whitequark[cis]>
endianness isn't an inherent property of numbers, it only arises when you access a wide value as a series of smaller units
<nemanjan00[m]>
Will it add 0x0800 or 0x0008 to it?
<whitequark[cis]>
it will add 4096 to it
<galibert[m]>
It will add 4096
<whitequark[cis]>
which is 0x800
omnitechnomancer has joined #glasgow
<omnitechnomancer>
It will add 4096 to it
<whitequark[cis]>
I do not understand how you can think it would add 8 to it when you are adding 4096
<whitequark[cis]>
this is not how numbers work
<nemanjan00[m]>
I was confused about how endianness works, I did not realize it does not continue outside of memory. I was under impression it is transfered to registers in same format and then arithmetics was implemented for specific endianness
<nemanjan00[m]>
I just need to implement recieving data now. It does make sense to be able to do both at the same time, for MITM and replay purposes, so it will be single applet
<nemanjan00[m]>
I will not be yet creating PR, since I do plan to have some more breaking changes until it is done
gruetzkopf has quit [Server closed connection]
gruetzkopf has joined #glasgow
<_whitenotifier>
[glasgow] whitequark synchronize pull request #486: applet.control.servo: an applet for controlling servomotors and brushless ESC modules - https://github.com/GlasgowEmbedded/glasgow/pull/486
<_whitenotifier>
[glasgow] whitequark synchronize pull request #486: applet.control.servo: an applet for controlling servomotors and brushless ESC modules - https://github.com/GlasgowEmbedded/glasgow/pull/486
<_whitenotifier>
[glasgow] whitequark synchronize pull request #486: applet.control.servo: an applet for controlling servomotors and brushless ESC modules - https://github.com/GlasgowEmbedded/glasgow/pull/486
<whitequark[cis]>
tpw_rules: updated to use integer number of us
<whitequark[cis]>
s/us/µs/
<galibert[m]>
Read is as "us" instead of "µs" and that gave way to a bunch of very interesting interpretations
<whitequark[cis]>
I wrote it as "us" first
<whitequark[cis]>
and changed because it was ambiguous in exactly the way you suggest
<galibert[m]>
:-)
<ar>
decimal/float number of "us" would have more interesting interpretations
<tpw_rules>
hmm, they also always start at 1000. like the two control methods are -100 to 100 (which gets mapped to 1000 to 2000) or just the raw pwm number
<ar>
"hello, my headmate is only 0.3 of a person"
<whitequark[cis]>
oh.
<tpw_rules>
i wasn't particularly clear earlier
<whitequark[cis]>
I'm not going to do -100 to 100 because then 0 does something bad if you are handling an ESC
<whitequark[cis]>
which i discovered earlier while using a servo tester with an ESC
<whitequark[cis]>
(do not recommend)
<tpw_rules>
yeah, there is that unfortunate duality
<galibert[m]>
What's an ESC?
<tpw_rules>
electronic speed controller
<tpw_rules>
in the rc/drone jargon
<whitequark[cis]>
BLDC driver
<galibert[m]>
controls what, a stepper motor?
<tpw_rules>
BLDC motors usually
<whitequark[cis]>
the BLDC I had here had Kv=2300
<tpw_rules>
(sometimes brushed dc but that's kind of rare these days)
<whitequark[cis]>
and I powered it with 12V
<tpw_rules>
did you lose any fingertips
<whitequark[cis]>
no
<tpw_rules>
or prints
<whitequark[cis]>
nor did I need a new pair of pants
<whitequark[cis]>
but it made me contemplate what would be a good choice for position range for the applet
<whitequark[cis]>
I am unsure if I want to get all of the logic out of the applet gateware
<whitequark[cis]>
it feels a bit sketchy, but it would also simplify some things
<tpw_rules>
yeah unfortunately i can't think of a thing where 0 is off
<tpw_rules>
idk if maybe you can have 0-1 like set_frac and then set_raw which takes 1000-2000
<whitequark[cis]>
I mean I'm not super unhappy about 0-1000
<tpw_rules>
but consider if it asks for a microsecond number, i'd put in 1000 to stop my motor and then it would go at max speed
<whitequark[cis]>
...
<whitequark[cis]>
yeah.
<tpw_rules>
it's kind of an unfortunate ambiguity. if someone uses a bidirectional ESC (for e.g. a car) then 1000 is max speed backwards, or 0 in a 0-1 scale
<tpw_rules>
this is probably an unlikely case though
<tpw_rules>
or rather the less likely
<tpw_rules>
some ESCs have safety and won't start turning until they see their 0 point after startup
<tpw_rules>
maybe yours doesn't or you accidentally bypassed it by swapping wires/power around
<whitequark[cis]>
it does have safety
<whitequark[cis]>
I was just unsure how the values map
adamgreig[m] has joined #glasgow
<adamgreig[m]>
(fwiw 1000-2000us is what I'd expect and use for servo stuff, even once it makes it into telemetry and technical reports etc)
<adamgreig[m]>
just another stupid scale you get used to, albeit ambiguously about where 0 position is and so forth
<tpw_rules>
yeah
<_whitenotifier>
[glasgow] whitequark synchronize pull request #486: applet.control.servo: an applet for controlling servomotors and brushless ESC modules - https://github.com/GlasgowEmbedded/glasgow/pull/486
<whitequark[cis]>
updated
<tpw_rules>
so to reiterate, everyone who sees an 'rc pwm' value, expects an integer (or sometimes float, but usually there isn't enough resolution to matter) within 1000-2000, which directly corresponds to the pulse width in microseconds
<tpw_rules>
if you'd like to add a 0-1, ±1, ±100, or whatever, (one system i use sometimes does ±4500 internally), then that's your prerogative but it should be like set_angle or set_scale or something instead of a generic term like "pwm" or "value"
<whitequark[cis]>
oh. one of the blades flew into my face
<whitequark[cis]>
well
<whitequark[cis]>
past my face
<tpw_rules>
similarly, and admittedly overly nit-picky, seeing 1ms and 2ms in the docs is weird. i'd write 1000us and 2000us.
<tpw_rules>
i've mangled my hand with that move before. or well at least got blood everywhere
<whitequark[cis]>
it's a PETG propeller Maya made for me
<whitequark[cis]>
dunno how much that can maim you
<whitequark[cis]>
"decently well", apparently
<tpw_rules>
i'm not sure how good PETG is at 28000 rpm
<whitequark[cis]>
so actually what happened is that the motor jumped
<whitequark[cis]>
earlier i mounted the motor to some 2020 framing securely and spun it up to uhhhhhh 50%.
<whitequark[cis]>
according to the power supply that dumped about 60W to a motor the size of like
<galibert[m]>
tpw_rules: very good for 1000us, downhill from there?
<tpw_rules>
galibert[m]: i don't understand
<whitequark[cis]>
23mm dia, 15 mm height
<tpw_rules>
ah
<whitequark[cis]>
PETG held, the motor started kind of ... well ... interesting smell
<galibert[m]>
Bad joke, not important
<tpw_rules>
yeah the power density in those things is wild
<tpw_rules>
i've been kind of mean to those sorts of motors but never smelled one before
<whitequark[cis]>
it might've been the ESC
<whitequark[cis]>
the heatshrink on it shrank a bit and it smelled like uh
<whitequark[cis]>
hot glued
<whitequark[cis]>
* hot glue
<whitequark[cis]>
the ESC is rated at 30A and it was fed with 5A at that point, so it should be fine
<Attie[m]>
I played with designing an ESC a while ago... early firmware was not kind to the motor, and the smell of varnish from the coils is quite familiar
<tpw_rules>
final nit: "The frequency of the updates is not strictly constrained by the protocol, and is fixed at 20 ms." -> "The frequency of the updates is not strictly constrained by the protocol, but is fixed at 20 ms by this applet."
<tpw_rules>
that's a little too low level for me... i've seen people try
<whitequark[cis]>
it's interesting to see the resolution on the ESC
<tpw_rules>
but the reason to do it escapes me
<whitequark[cis]>
1010 is considered off
<tpw_rules>
there's a deadband and a calibration process
<whitequark[cis]>
tpw_rules: that's why they call it ESC
<whitequark[cis]>
1016 makes the motor twitch and make weird sounds
<whitequark[cis]>
1020 is firmly on
<tpw_rules>
was that another joke
<whitequark[cis]>
1019 is on half the time
<whitequark[cis]>
tpw_rules: yes
<whitequark[cis]>
uhhhh
<tpw_rules>
is your ESC identifiable at all?
<tpw_rules>
like make/model
<whitequark[cis]>
it's like 4 GBP aliexpress special
<tpw_rules>
so no
<whitequark[cis]>
oh, i think the bearings in this motor are shot
<whitequark[cis]>
it sometimes catches and stops/restarts
<tpw_rules>
so it might not be calibratable
<tpw_rules>
that can also be a crappy esc thing
<whitequark[cis]>
time to spin it to 107%
<whitequark[cis]>
oh, that browns out the PSU
<tpw_rules>
particularly at low speed
<whitequark[cis]>
i am powering this entire thing from USB, using a buck-boost converter i have here
<tpw_rules>
so, do you have three more motors and ESCs too
<whitequark[cis]>
oh, wait, no, the motor is ... fine?
<whitequark[cis]>
tpw_rules: i've been using two power supplies
<whitequark[cis]>
one big Riden RD6012P
<whitequark[cis]>
and one small one, which can actually do 60W too, but only barely, and only with a resistive load really
<tpw_rules>
(incidentally if anyone knows a good way to run PoE equipment over usb-c, please hit me up)
<whitequark[cis]>
tpw_rules: haha
<whitequark[cis]>
i am sure i could get one
<whitequark[cis]>
glasgow quadcopter?
<whitequark[cis]>
anyway, here's an interesting behavior
<whitequark[cis]>
right now the motor spins just fine at 1100
<whitequark[cis]>
but before that, after i set it to like 1018, it would spin slower and worse at 1100
<whitequark[cis]>
restarting a lot
<whitequark[cis]>
what's up with that
<tpw_rules>
sync issues
<tpw_rules>
and janky ESC firmware
<whitequark[cis]>
it also seems to top out at 1600
<whitequark[cis]>
that's 8 W at 12 V from this power supply
<tpw_rules>
so 60w was with the propeller?
<whitequark[cis]>
yep
<whitequark[cis]>
it generated a considerable amount of thrust
Lord_Nightmare has joined #glasgow
<tpw_rules>
interesting
<whitequark[cis]>
i can get it to consume 30W right now by loading it by uh
<whitequark[cis]>
pushing a propeller blade into the rotor so that it basically mills it down
Lord_Nightmare has quit [Remote host closed the connection]
<tpw_rules>
done that move before too lol
<whitequark[cis]>
lmfao
<tpw_rules>
that's why i asked about the fingerprints
<tpw_rules>
topping out at 1600 could be a calibration thing. try plugging in the 12v power supply to the esc with the glasgow set to output 2000, set it back to 1000, then unplug and replug the 12v and see if the range expands
<tpw_rules>
(remove the propeller ideally)
<_whitenotifier>
[glasgow] whitequark synchronize pull request #486: applet.control.servo: an applet for controlling servomotors and brushless ESC modules - https://github.com/GlasgowEmbedded/glasgow/pull/486
<whitequark[cis]>
the propeller is gone! it shattered
<whitequark[cis]>
this is fun
<whitequark[cis]>
i bought the ESC to start an ICE i also got for us to play with
<tpw_rules>
but i'm not immediately sure that a little bldc would be suitable for starting
<whitequark[cis]>
not this BLDC
<tpw_rules>
sensorless specifically
<whitequark[cis]>
it comes with a suitable BLDC, but not with an ESC
<whitequark[cis]>
and it clearly is sensorless
<tpw_rules>
interesting
<tpw_rules>
i wonder if there's a built in clutch or something
<whitequark[cis]>
>....ERROR: Max frequency for clock 'cd_sync_clk_if_0__i_$glb_clk': 23.05 MHz (FAIL at 30.00 MHz)
<whitequark[cis]>
oh it doesn't work on ice40up5k
<tpw_rules>
i also might be able to make a glasgow quadcopter. but none of the control theory stuff i'm good at and i don't think a little risc-v would fit my usual autopilot firmware
<whitequark[cis]>
once we have ram-pak support you would have uh
<whitequark[cis]>
32 MB of RAM
<whitequark[cis]>
would that help
<whitequark[cis]>
... someone could boot linux on glasgow, conceivably
<tpw_rules>
it wouldn't hurt but more i would need an FPU
<whitequark[cis]>
ah
<tpw_rules>
(and idk if 50MHz would be enough)
<_whitenotifier>
[glasgow] whitequark synchronize pull request #486: applet.control.servo: an applet for controlling servomotors and brushless ESC modules - https://github.com/GlasgowEmbedded/glasgow/pull/486
<whitequark[cis]>
could make it accelerated
<tpw_rules>
that gets back into that control theory stuff
<whitequark[cis]>
right
<tpw_rules>
(it would also be ungodly cost ineffective but you knew that already...)
<whitequark[cis]>
tpw_rules: so, do you want to own the servo applet?
<tpw_rules>
i don't know what that means
<whitequark[cis]>
basically, be its maintainer
<tpw_rules>
i suppose?
<tpw_rules>
i can test it officially next week
<tpw_rules>
and comment and stuff. is there any metadata that would represent that?
<whitequark[cis]>
yes, github code owners
<whitequark[cis]>
github will also gate PRs on your review
<tpw_rules>
sure, we can give it a try. the only ownership system i've used is the one built into nixpkgs
<_whitenotifier>
[glasgow] whitequark synchronize pull request #486: applet.control.servo: an applet for controlling servomotors and brushless ESC modules - https://github.com/GlasgowEmbedded/glasgow/pull/486
<whitequark[cis]>
invited you to the org
<tpw_rules>
"This applet can also serve as an example of a rather simple applet that follows the latest best practices." would that be your responsibility to keep up to date or mine?
<whitequark[cis]>
mine
<whitequark[cis]>
though it's not referenced anywhere right now
<whitequark[cis]>
hence "can"
<whitequark[cis]>
really I'm much more interested in someone who has actual experience with servos having authority over it than using it as an example
<tpw_rules>
ok, i can do that. i just accepted the org invite
<whitequark[cis]>
purrfect :3
<_whitenotifier>
[glasgow] whitequark synchronize pull request #486: applet.control.servo: an applet for controlling servomotors and brushless ESC modules - https://github.com/GlasgowEmbedded/glasgow/pull/486
<_whitenotifier>
[glasgow] whitequark synchronize pull request #486: applet.control.servo: an applet for controlling servomotors and brushless ESC modules - https://github.com/GlasgowEmbedded/glasgow/pull/486
FireFly has quit [Server closed connection]
FireFly has joined #glasgow
<tpw_rules>
Attie[m]: i was looking at your i2s applet and was wondering if you had planned a mode where it could be used as a controller/master/whatever which generates the clock signals?
<tpw_rules>
(i want to test microphones)
<Attie[m]>
it was originally designed to sniff from an otherwise complete system, but that would be sensible!
<_whitenotifier>
[glasgow] whitequark synchronize pull request #486: applet.control.servo: an applet for controlling servomotors and brushless ESC modules - https://github.com/GlasgowEmbedded/glasgow/pull/486
<_whitenotifier>
[glasgow] whitequark synchronize pull request #486: applet.control.servo: an applet for controlling servomotors and brushless ESC modules - https://github.com/GlasgowEmbedded/glasgow/pull/486
tomkeddie[m] has quit [Quit: Idle timeout reached: 172800s]