<firefrommoonligh>
<K900> "There's literally a most..." <- \tinfoil. Looks like proc macros are deep in dependency trees of many things. Our codes are being manipulated from the bottom up!
<dirbaio[m]>
Big Macro is on us 😰
starblue has quit [Ping timeout: 272 seconds]
AlexNorman[m] has joined #rust-embedded
<AlexNorman[m]>
I'm needing to share SPI0 between 2 devices, embedded_graphics display and embedded_sdmmc, both of which take ownership of the SD... I'm currently driving the graphics but I'm trying to figure out how to also do SD. luckily I wrote the display implementation so I can change it as I need, but I figured I'd check if anyone has any additional advice before I dig into it?
<AlexNorman[m]>
I see that embedded_sdmmc has a way to borrow the spi device, so maybe I can make my display driver use a borrowed spi device and supply it when i need?
<firefrommoonligh>
I would change the API to take a ref
<firefrommoonligh>
Specifically, I don't think owning a bus is good behavior in a general API, because busses are designed to be used by multiple data sources, assuming proper time decon or other deconfliction mechanism
<AlexNorman[m]>
I agree, though most of the examples I see seem to take ownership..
<AlexNorman[m]>
would you simply pass the spi reference when building calling API methods or, maybe I have a relatively light weight struct that I simply construct on demand, that takes the reference?
<AlexNorman[m]>
s/building//
<AlexNorman[m]>
it looks like i'll actually have to the the latter as I have to pass my graphics "device" implementation into the embedded graphics calls
<adamgreig[m]>
With embedded_hal 1.0 you take ownership of an SpiDevice for each driver and whatever provided them handles sharing
<thejpster[m]>
also please do test out the shell example with any random SD card or hard drive images you have - maybe we can find some corner cases that it can't handle.
starblue has joined #rust-embedded
Guest7221 has joined #rust-embedded
inara has quit [Quit: Leaving]
inara has joined #rust-embedded
<firefrommoonligh>
Thx for all the work on this! I haven't been commenting bc I have no uses for SD cards atm
<thejpster[m]>
I spent this evening making smart handles for volumes, directories and files. They're annoying because they have to hold a &mut ref to the volume manager, but they're also useful because they can have methods and drop implementations.
<thejpster[m]>
Maybe next I'll try and make Volume Manager use internal mutability with RefCell or something.
<thejpster[m]>
Also, feel free to comment on the style and/or approach even if you don't know how FAT works!
Guest7221 has left #rust-embedded [Error from remote client]
starblue has quit [Ping timeout: 260 seconds]
<TomB[m]>
adamgreig: ecp5 does look intriguing, and the price is tough to beat, have you ran into any hurdles with the open tooling? What if I want to write my logic in vhdl?
<TomB[m]>
and I guess follow up to that, how well are open riscv designs on this thing supported, e.g. neorv32
JonathanDickinso has quit [Quit: Idle timeout reached: 172800s]
<adamgreig[m]>
Personally all my logic is in amaranth, I'm not interested in touching verilog nor vhdl, but my understanding is generally the open tooling works better with verilog but there are a couple good ways to use vhdl
<adamgreig[m]>
On the whole the open tooling is so so much faster to run than the vendor stuff, and tends to do fairly well but not always entirely as well as the vendor stuff in terms of timing, but it's a worthwhile tradeoff for me at least. Also the vendor tooling has more sophisticated timing analysis especially around the less well supported things like DSP blocks and io timing
<adamgreig[m]>
Plenty people running various riscv soft cores without issue
<TomB[m]>
I guess I should take a look at amaranth, I learned vhdl predominantly because it felt closer to rust-like when I started than verilog, but fair enough, I suppose with amaranth it outputs verilog into the tools then, much like all the JS "transpiler" tools of sorts?
<TomB[m]>
like vhdl seemed more natural and all the vendor tools directly supported it (though I wish they supported a newer dialect...)
<adamgreig[m]>
sort of, although right not it actually outputs RTLIL which is an IL for yosys, which then either does synthesis (ice40, ecp5, various others) or emits verilog for vendor toolchains
<TomB[m]>
like I looked at migen before and... yeah it looked weird to me
<TomB[m]>
rtl-il interesting!
<TomB[m]>
* rtlil, interesting!
<adamgreig[m]>
amaranth is a somewhat more developed and evolved migen, but the very basic concept of "you're writing a python program that, at runtime, constructs the hardware design" is the same and i really like it personally
<adamgreig[m]>
can do so much really good metaprogramming
Noah[m] has joined #rust-embedded
<Noah[m]>
adamgreig: how do you do sim etc? generally my gripe was never with VHDL but rather the whole tooling around it which was hard vendor locked ... especially placement and routing and especially timing verification was always a bit funny with OSS stuff but last time I tried was like in 2019.
<adamgreig[m]>
amaranth has a built in python sim engine so i just write pytest tests
<TomB[m]>
yeah I guess vhdl generics are somewhat limiting... especially in older dialects which is what the free vendor tools typically support
<adamgreig[m]>
for bigger sims, yosys can generate c++, and i have a little python tooling to then build and run that
<TomB[m]>
gotta pay for a newer vhdl from intel, and I don't think xilinx has bothered
<adamgreig[m]>
amaranth is worlds beyond anything you can do in vhdl generics
<TomB[m]>
ghdl+vunit has been amazingly nice though, and very fast to sim and test
<Noah[m]>
ah nice :) always wanted to make a rust waveform viewer and simulator, but I have no clue about this stuff haha
<TomB[m]>
now that is intriguing
<Noah[m]>
adamgreig[m]: yeah I mean if you can get the same implementation efficiency than vendor tools I really don't see why one would not use amaranth :)
<adamgreig[m]>
sadly almost all my recent gateware is for work and not public
<adamgreig[m]>
Noah: with amaranth you can just set "use the vendor tooling" or "use the open-source tooling" and it handles everything else, so long as the toolchain is installed
<adamgreig[m]>
ie it generates a project file, runs the synthesis and build, and can also do programming, so you never need to open/touch/look at the vendor stuff
<Noah[m]>
ah neat!
<Noah[m]>
need to find a good project for myself to try it out!
<adamgreig[m]>
makes it very easy to try a design out in both too, I guess
<TomB[m]>
that is pretty neat, I don't picture that fsm being that small in vhdl at all
<TomB[m]>
I can't say I have much love for python though...
<Noah[m]>
yeah would be neat to have all tooling oSS, but I guess FPGA vendors don't really have an interest in that. which is funny, because the SW always sucked and the HW was pretty neat. So they should be able to attract more folks with better SW. But I guess many companies want sth vendor provided.
<adamgreig[m]>
but the free stuff is so much easier to set up (you can just "pip install yowasp-nextpnr-ice40" for example and get a full p&r, compiled to wasm, installed as a python executable via wasmtime)
<TomB[m]>
is there any sort of type checking at all in amaranth or is it all duck typed with horrible errors?
<Noah[m]>
adamgreig[m]: yeah but last time I checked, yosys would not do timing analysis which renders it kinda worthless - maybe its fixed now - and also, ice40 is not really a commercially used FPGA I think.
<adamgreig[m]>
ice40 is definitely commercially used, who do you think is buying them?
<adamgreig[m]>
it's for sure not just hobbyists
likewise[m] has joined #rust-embedded
<likewise[m]>
I like SpinalHDL for RTL. I do not want to start a "HDL Other" war though.
<Noah[m]>
adamgreig[m]: I was always under the impression it was mostly hobbyists. but I might be ill-advised here
<adamgreig[m]>
Tom B: it has a strongly typed concept of interfaces for connecting modules together, but it generally doesn't pull in python typing annotations (though some people use them)
<adamgreig[m]>
but yea, that's the rub, you are writing python programs the whole time, so you have to like python more or less
<adamgreig[m]>
likewise: my view today is "so long as you're using something that's not verilog or vhdl, you're probably doing alright"
<TomB[m]>
I mean I don't hate python, but every time its gone beyond the 1 file with ~1000 lines it starts to become burdensome
<adamgreig[m]>
spinalhdl seems nice, chisel too, I'm trying to remember another nice one I saw the other day that had an extremely rust-like syntax
<adamgreig[m]>
my usual gripe with all of them is they do not have the same metaprogramming approach that amaranth has of "you're writing a program in the host language which at runtime constructs the logic"
<TomB[m]>
like suddenly you get odd errors only when you go to run things and they are annoyingly hard to sort out sometimes
<adamgreig[m]>
well, maybe that's unfair on chisel actually
<adamgreig[m]>
Tom B: I think these days there are enough extremely large python programs out there to demonstrate the feasibility of large python programs without a ton of type errors, but perhaps it does mean needing a decent amount of unit tests or type annotations?
<likewise[m]>
adamgreig: Yeah, Chisel and SpinalHDL both build a model of the hardware (that you can "mold" during run-time), then generate it at the end of run-time, AFAIK.
<adamgreig[m]>
I'm always writing a ton of unit tests for my amaranth code anyway since that's how the logic is tested, so it de-facto is also running all the python anyway, so there aren't generally any surprise runtime errors for me
<TomB[m]>
I mean I like rust for a reason lets just say :-)
<TomB[m]>
I'd rather write rust than python any day of the week, every day of the year
<adamgreig[m]>
there's a lot of new hdls out there to try out, many involving rust
<TomB[m]>
I think the type annotations might help me though... frankly its hard to remember what some var is without the annotations, you pass a var a few functions in without them and i mean, while your writing that stuff you know, 3 months later its beyond baffling
<TomB[m]>
but I do think its neat the space is being explored
<TomB[m]>
oh now that is neat
<TomB[m]>
the pipelines as a language feature is cool
<adamgreig[m]>
it's basically just the rust syntax, even has tagged enums and match statements and such
<adamgreig[m]>
<Noah[m]> "I was always under the impressio..." <- I don't think the hobbyist fpga market could possibly sustain them, but it is popular with hobbyists in the same way that I guess PICs and AVRs were
<Noah[m]>
fair :0
<Noah[m]>
* fair :)
<adamgreig[m]>
they're nice fpgas, too!
<adamgreig[m]>
simple enough to really thoroughly understand, small enough that building for them never takes that long
<adamgreig[m]>
yosys never does timing analysis because it's just synthesis btw, but nextpnr does do timing analysis for its place&route, albeit it's quite pessimistic compared to vendor models as all the timings have to be reverse engineered
crabbedhaloablut has quit []
<TomB[m]>
spade looks cool, I'll have to keep an eye on it
<adamgreig[m]>
yea! it seems neat but again it looks a bit like a nicer verilog whereas I think I now want something quite different
<adamgreig[m]>
amaranth has been absurdly productive compared to verilog for me
<Noah[m]>
adamgreig[m]: I never really had that small applications :/ all stuff I did so far required a ZYNQ :D
<adamgreig[m]>
hah, fair enough! how many LEs?
<adamgreig[m]>
the ecp5 go up to 85k LUT4s which has been more or less big enough for all my needs so far and saves ever installing vivado...
<TomB[m]>
I guess I should try amaranth
<likewise[m]>
All stuff I did does barely fit largest Ultrascale+ :-)
<likewise[m]>
* All *recent* stuff I
<adamgreig[m]>
my sympathies :P
<likewise[m]>
Yeah, I hear people complaining about Rust compile times... :-)
<TomB[m]>
Vivado was slow for even small designs for me, like trying to load up a neorv32 soc and some other stuff on an artix 7 I got really annoyed
<TomB[m]>
I can't even imagine a big part like that...
<TomB[m]>
I fired up ghdl + vunit and haven't looked back
<TomB[m]>
but I guess that only works if you don't need IP blocks :-)
<likewise[m]>
Vivado is slow under the hood because it spawns processes for each step. So for small designs, lots of overhead.
<likewise[m]>
For large designs, the place and route takes hours.
<TomB[m]>
doing the same damn thing on a cyclone iv with quartus made me wonder what kind of cycle spinning is going on over there in xilinx land...
<Noah[m]>
adamgreig[m]: Can't tell for sure, but a big plus of the ZYNQ is that you can push a lot of data into RAM and then write a kernelmodule/driver to send it over the network from the A9.
<Noah[m]>
And of my bachelors, we built filter-chains that would use all LUTs available, so more was better :P
<Noah[m]>
<adamgreig[m]> "the ecp5 go up to 85k LUT4s..." <- yeah vivado is the piece of garbo I would wanna get rid of too. but in all fairness, I am not a good HDL dev ^^
<Noah[m]>
do you use the UI or the TCL?
<Noah[m]>
TCL definitely made things waaaaay more agreable for me and CI testable and reproducible as well :)
<TomB[m]>
Noah[m]: even using tcl its not exactly a whirlwind... though avoiding the bloatware Java UI taking a minute or two to start was nice
<adamgreig[m]>
both are hateful, I would just have python drive vivado under the hood, with the simulations and CI all staying in python land for the logic...
<Noah[m]>
becuase imo the UI is just a complete deficiency ... their official recommended way of version control is exporting a ZIP ...
<TomB[m]>
Noah[m]: this is just the normal embedded developer flow everywhere
<TomB[m]>
dump zips on shared window drives with all the IDE files
<TomB[m]>
I swear, people that don't do this are the oddities
<adamgreig[m]>
these days I think a full VM image of the tool plus your code and everything
<adamgreig[m]>
presumably snapshotted every week or two
<Noah[m]>
TomB[m]: for me it's more that we also used some of the ZYNQ provided HW modules which require this weird routing of vivado. and vivado likes to fuck it up. using TCL you can just run `make design` again whereas the UI just leaves you in the dirt when it fucks up ^^
<likewise[m]>
The shops I work with do export Vivado projects, then commit to GIT with all the scripts on GitHub to help do that.
<TomB[m]>
I mean and yeah to be fair I'm like a 100% hobbyist/learner in this space, but man what the hell, have to be a masochist to do large HDL design work I feel like with the tools
<Noah[m]>
likewise[m]: yeah, but vivado still takes the liberty to make completely weird script diffs at times :/
<Noah[m]>
idk why we just cannot have nice things ...
<Noah[m]>
trip to the US just told me again that it can be even worse than some countries in the EU haha ... people just don't care about having nice things
<Noah[m]>
on that note: I am cleaning probe-rs code ... it's bad ...
<TomB[m]>
well from the other side, using probe-rs, its really quite nice
<Noah[m]>
TomB[m]: yeah, I am making an effort now to cleanup the other bits :) Good UX was always the main goal :)
<Noah[m]>
Can improve tho =)
<adamgreig[m]>
hah fun, i thought i recognised the name, the spade-lang dev also maintains stm32f1xx-hal and hangs out here
<Noah[m]>
adamgreig[m]: oh nice! Sweden is pushing out some dope Rust stuff and tech in general :)