<rqou>
what about the overall question of "can i trust japaric? is this stable enough to actually use?"
futarisIRCcloud has joined ##openfpga
<whitequark>
sure
<whitequark>
the foundational parts (like svd2rust, cortex-m, etc, crates) are very stable
<whitequark>
the RTFM framework is still evolving
<whitequark>
but it doesn't look to me like it will have dramatic changes after this point
<rqou>
hmm ok
<rqou>
one last concern i have is that the RTFM framework seems to be an excellent way to write bug-free embedded software, but it's different and incompatible with traditional shitty practices
<rqou>
which probably doesn't matter in my case i guess since it's a greenfield project
<rqou>
e.g. doesn't have a clusterf*ck of freertos/nucleus/threadx/blobs in it
<awygle>
chibios is pretty good, as far as free c rtoses go
<rqou>
yeah, bunnie and xobs seem to really like it
<awygle>
plus is smol
<rqou>
i used to think freertos was good until i actually used it
<awygle>
and has gone to space
<rqou>
the freertos design is pretty old and slow
<awygle>
it was pretty easy to port to MSP430 also
<rqou>
oh yeah porting freertos is a disaster for some reason
<awygle>
crappy abstractions
<rqou>
i don't get why "push rN, swap stack, pop rN" is so hard
<rqou>
cortex-m MPU support in freertos is also pretty borked
<rqou>
as well as needing _both_ svc and pendsv for some reason??
<awygle>
i should do a riscv port
<awygle>
except i have other things going on
<rqou>
someone should just implement a cortex-m style nvic for risc-v
<rqou>
in RU or some other non-western country of course (because patents)
<awygle>
the fossi folks are looking for RTL projects for GSoC, suggest that to them
<rqou>
the rust rtfm framework basically hijacks the nvic into a scheduler
<awygle>
i am familiar with it yeah
<rqou>
it doesn't have a very traditional "threads" model
<rqou>
but the more i think about it the more i feel a traditional "threads" model is pretty useless for a microcontroller/real-time system anyways
<awygle>
my firmware for my cubesat transceiver ended up being something like an actor model on top of chibios
<awygle>
really anything primarily event-driven works pretty well. ee(some numbers, maybe 143?) taught us to use statecharts
<awygle>
149, whoops
<rqou>
yeah i never took that
<awygle>
was pretty good
azonenberg has quit [Ping timeout: 265 seconds]
azonenberg_work has quit [Ping timeout: 260 seconds]
openfpga-bb has quit [Ping timeout: 256 seconds]
thallia has quit [Ping timeout: 268 seconds]
thallia has joined ##openfpga
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
eduardo has joined ##openfpga
ondrej2 has joined ##openfpga
eduardo_ has joined ##openfpga
eduardo has quit [Ping timeout: 256 seconds]
m_t has joined ##openfpga
azonenberg_work has joined ##openfpga
<rqou>
O_o STM32F765 looks like a really neat part
<rqou>
double-precision fpu, 216 mhz
<rqou>
and the LQFP100 part is $13 in quantity 1
<rqou>
azonenberg_work: how come the newer faster parts are cheaper than the old slow parts?
<rqou>
also O_o the STM32H7 (unfortunately not available yet)
<rqou>
400 MHz core
<rqou>
is this a microcontroller or a full SoC?
<rqou>
also what "[Cortex-M7] features a 6-stage superscalar pipeline with branch prediction"
<azonenberg_work>
rqou: probably a die shrink
<rqou>
should totally just run linux on this thing :P
<rqou>
the H7?
<rqou>
ST claims that it can go so fast because it has L1 caches
<rqou>
wait the F7 has L1 cache too
<rqou>
so yeah, maybe the H7 is a die shrink
openfpga-bb has joined ##openfpga
<rqou>
i actually want an STM32F7 linux board now
<rqou>
i should make one for the lulz
<rqou>
i wonder if linux-on-cortexm actually works or not
azonenberg has joined ##openfpga
<rqou>
i should make an STM32F7 linux-optimized board and gift one to landley so that he can become even more sad at the clusterf*ck that is the linux cortex-m port :P :P
azonenberg_work has quit [Ping timeout: 264 seconds]
<whitequark>
what
<whitequark>
why the fuck is there a linux cortex-m port
<whitequark>
that's stupid
<rqou>
yeah, it exists
<rqou>
according to landley some companies have actually shipped products with it
<rqou>
it's not upstream or rebased to anything modern of course
<rqou>
apparently the abi is a disaster
<rqou>
but i don't know anything about it
<jn>
stm32 has seen a *lot* of mainline commits
<rqou>
wait what
<jn>
what's even weirder: there seems to be an stm32 based on cortex-a, now
<rqou>
jn: i thought there was only the emcraft fork?
<rqou>
no there isn't
<rqou>
unless it's unannounced?
<jn>
it might not have been announced, but there was a patchset on the lkml :)
<rqou>
but it still feels weird to me that "no, you cannot do <thing that was never a good idea but embedded people did anyways because embedded code quality is a joke>"
<cr1901_modern>
>whitequark: cr1901_modern: then why talk about it.
<cr1901_modern>
My point was "There's usually a crate for $X already." But here, rqou (doesn't have sine for whatever reason): https://github.com/japaric/m
<rqou>
yeah, i'll figure it out
<rqou>
btw, imho the rust ecosystem needs more "math" crates
<rqou>
but apparently the "math" functions that i tend to need aren't quite the math functions that other people want
<rqou>
i mostly want stuff for linear algebra, discrete math (finite fields, elliptic curves, etc.), linear signals and systems, DSP, etc.
rohitksingh_work has quit [Read error: Connection reset by peer]
<implr>
rqou: the stm32f7-disco is a fairly nice board if you don't want to make your own for a bga400 part
<implr>
has a touch lcd, ethernet i think, some extra ram
<implr>
except for the... questionable decision of exposing gpio via an arduino header
rohitksingh has joined ##openfpga
FabM has quit [Ping timeout: 248 seconds]
eric_j has quit [Read error: No route to host]
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
pie__ has joined ##openfpga
pie_ has quit [Ping timeout: 240 seconds]
<cr1901_modern>
daveshah: Cleaned up everything in arachne-pnr and icestorm. There's a version mismatch in the binary chip DB _despite_ them clearly being the same version looking in a hex editor
<cr1901_modern>
wait a second...
<cr1901_modern>
daveshah: Ignore for now. Something's _very_ weird
<daveshah>
cr1901_modern: Are the binary chipdbs in the same folder as arachne-pnr? I think that's what the Windows build needs.
<cr1901_modern>
daveshah: No they aren't. But shouldn't it have returned a "file not found" error?
<daveshah>
cr1901_modern: Not if you have old chipdbs in that folder. Otherwise I think it should
<cr1901_modern>
daveshah: No old chipdbs in the folder where I expect them to be... huh...
<cr1901_modern>
this is weird...
<daveshah>
cr1901_modern: What happens if you delete the chipdbs wherever they are? Does it then given a not found error?
<cr1901_modern>
daveshah: Yes
<daveshah>
cr1901_modern: Good start. Can you send me the binary chipdb causing the problem?
<cr1901_modern>
daveshah: This didn't use to be a- oh ffs... I see at least part of the issue now
rohitksingh has quit [Ping timeout: 248 seconds]
<cr1901_modern>
daveshah: I will send it if necessary, but I think my issue is orthogonal
<daveshah>
c1901_modern: OK, let me know if you want me to look at anything
<cr1901_modern>
daveshah: So, indeed there was a version mismatch. This didn't use to happen despite me using the "generic" make target.
<cr1901_modern>
daveshah: I'm checking my old backups of the repo on my NAS for hints
<daveshah>
cr1901_modern: Interesting. Just to check, what folder are the binary chipdbs being loaded from?
<cr1901_modern>
daveshah: In each case (tests, general usage), where the arachne-pnr binary lives
<cr1901_modern>
daveshah: So the truth of the matter is arachne-pnr on msys64 will work fine with the *nix defaults. I should probably add a patch for this like I did w/ yosys
<daveshah>
cr1901_modern: I see the problem. The makefile puts them in the "proper" share folder.
<daveshah>
cr1901_modern: blame on the Makefile suggests no changes to those lines for >1 year
<cr1901_modern>
daveshah: I know... so I guess I copied the chipdbs manually?
<cr1901_modern>
But I don't trust myself to have remembered to do that if arachne-pnr silently didn't crash :P
<daveshah>
cr1901_modern: Yes, that's all I can think happened. Then the chipdb format was stable for a long time until I, and possibly others when Clifford merged a load of PRs, changed it.
<cr1901_modern>
(which it only started crashing in Dec. My last successfuly build was Sep 29-Oct 1 thereabouts)
<cr1901_modern>
daveshah: According to recycle bin, I remembered to copy the chipdbs during the Sep 29 build
<daveshah>
cr1901_modern: OK. This all makes sense then. I suggest that ../share/arachne-pnr is used on "normal" mingw builds, unless the `mxebuild` Make target is used.
* cr1901_modern
agrees
<cr1901_modern>
daveshah: I'll do that patch in a few mins. It's basic conditional logic similar to my yosys patch
<daveshah>
cr1901_modern: Great, that would be brilliant
<cr1901_modern>
There's no way for me to verify what past-me was thinking b/c I didn't back it up, but...
* cr1901_modern
is taking a photo
<cr1901_modern>
daveshah: https://imgur.com/a/c5cS4 Past me knew he needed to copy the binaries to the bin directory.
rohitksingh has joined ##openfpga
<cr1901_modern>
(Notice the times)
<cr1901_modern>
(and the locations)
<cr1901_modern>
I don't remember what caused me to copy them at this point :(. I don't remember arachne crashing back then. I don't recall any insns that told me to do it either.
<cr1901_modern>
tldr: This whole fiasco was due to user error and I have no idea why I did it right the first time :P.
<daveshah>
cr1901_modern: Yeah, it's funny how these things get forgotten. One of the reasons I've decided to start backing up my `.histfile`.
<daveshah>
cr1901_modern: It was caused by bad documentation not user error :)
<cr1901_modern>
:). Thanks, that makes me feel better
<cr1901_modern>
daveshah: Hmmm, I _might_ have a histfile that could shed light
<daveshah>
The Python command shouldn't be executed basically
<daveshah>
But this is in a Makefile that should never have anything to do with w.mk
RaivisR__ is now known as RaivisR
<mithro>
daveshah: Can you push your makefile changes somewhere?
<mithro>
daveshah: I'm not currently happy with the `ALTERNATIVE_TO` syntax - but we can fix that up in a later CL
<daveshah>
mithro: sorry, rather ironically the windows key on my computer keyboard has failed stuck down. Will push makefiles when I've dug out my spare.
<mithro>
daveshah: Do you have uncommitted changes?
<daveshah>
Sorry, I've been really stupid. Wait a second.
<daveshah>
mithro: Left some debugging in gen.mk - pull again and it should go to the error
<daveshah>
mithro: Basically the problem is that it's trying to generate pb_type.xml as well as pb_type.*.xml, whereas I'm trying to make it only generate pb_type.*.xml
<daveshah>
mithro: Yes, at the moment I think your PR will fail because it will also try and generate a pb_type from sim.v which is not valid Verilog (but AFAICS model generation should be done directly from sim.v, hence the sed to strip it)
<daveshah>
mithro: Could be solved by calling it something like sim.wv instead which makes me more comfortable than a file ending in *.v which isn't Verilog
<mithro>
daveshah: A quick fix is "if USE_W -- $(filter-out pb_type.xml,$PB_TYPE_XML)"
<daveshah>
mithro: Thanks, I've integrated with a few tweaks and `make -f Makefile.xml` is working now.
<daveshah>
But `make -f Makefile.gen` still fails in the same way....
<daveshah>
I just can't see how they would behave differently, as Makefile.gen just calls all the Makefile.*s in order
<daveshah>
Have pushed latest to Master
user10032 has joined ##openfpga
<daveshah>
mithro: Fixed it
<daveshah>
It was a really nasty one
<daveshah>
in `gen.mk`, the variable `MAKEFILES` was being filled with the name of all Makefiles to run in order for the for loop
<daveshah>
This caused each sub `make` to load all of these makefiles, which caused a conflict and broke the XML generation
<daveshah>
By renaming this variable to `GEN_MAKEFILES` it works properly