<okhsunrog[m]>
<AlexandervanSaas> "I have some sensor data that I..." <- I did the following: installed InfluxDB v2, Grafana, use cargo-embed to send RTT channel over TCP and then used a python script that was receiving data over TCP, parsing it, and writing to influx db, then I used the grafana to visualize the time series, this way the live plot worked perfectly for me
<okhsunrog[m]>
another option: python script receiving data over TCP and plotting it with matplotlib. if you want a bit more fancy interface - you can use PyQt6 with matplotlib
<okhsunrog[m]>
and if you don't mind writing it all in rust, you can create an app using egui + egui_plot + probe-rs as a library crate. something similar to https://github.com/hacknus/serial-monitor-rust
<okhsunrog[m]>
if you're good with frontend you can try Tauri, I'm not sure how suitable it is for realtime plotting, D3.js should be fine
<okhsunrog[m]>
you can also check out https://rerun.io/ but it's mostly for a complex data, might be ovekill for a couple of plots
<okhsunrog[m]>
s/a//
<okhsunrog[m]>
* be fine I guess
<Darius>
+1 for feeding to a DB and using Grafana
<Darius>
depends how much client code you want to write, my aim is usually for 0 :D
<M9names[m]>
<okhsunrog[m]> "you can also check out https://..." <- rerun is very good for live high-speed 2D plotting.
<M9names[m]>
Not the best interface for it, but it does work and is pretty easy to feed data to
_whitelogger has joined #rust-embedded
<okhsunrog[m]>
<Darius> "depends how much client code you..." <- it's fairly simple code, an LLM can totally generate 100 loc that establish tcp connection, parse data and use influxdb python library
<Darius>
I prefer not to use the lying machine, but I am talking about the client to view the data, not something to upload to the server
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
instead of using a script, and instead of writing to influxDB, you could be using the telegraf tool from influx. It can injest a lot of stuff, e.g it can injest modbus-tcp/ raw sockets etc and can pipe it forward to different outputs. One is a db, but you can also directly forward it into grafana via websockets, That way you get a "reasonable" live view of the data with a nice frontend :D
<okhsunrog[m]>
<vollbrecht[m]> "instead of using a script..." <- yes, telegraf is really cool, but it doesn't support probe-rs and RTT as far as I know 🙃
pcs38 has joined #rust-embedded
Noah[m] has joined #rust-embedded
<Noah[m]>
<FreeKill[m]> "Licensing SystemView is ~1.5K..." <- i'm on it, just not as quick ... https://inspect.probe.rs
<whitequark[cis]>
Noah: have you had a chance to try out my PR?
<Noah[m]>
whitequark[cis]: nope, I just sat at the PC and I am picking up slack :D digging out the glasgow :)
<whitequark[cis]>
nice!
<Noah[m]>
Now I just need to figure the pinout of the nrf devkit and the glasgow SWD applet, brb
<whitequark[cis]>
the glasgow SWD applet lets you place the pins wherever you like
<whitequark[cis]>
glasgow run probe-rs -V 3.3 --swdio A0 --swclk A1 or whatever
<whitequark[cis]>
the fact that no applet has a single fixed pinout is one of my points of pride :3
<Noah[m]>
ah sick :)
<Noah[m]>
that's dope!!
<Noah[m]>
you mess up the wiring, you fix it in software
<whitequark[cis]>
right? you just put the wires wherever you like and... exactly
<whitequark[cis]>
if you were using JTAG, there is an applet jtag-pinout which automatically figures out which wire went wher
<whitequark[cis]>
s//`/, s//`/, s/wher/where/
<whitequark[cis]>
so I never even bother looking at the silk for JTAG, I just connect it and run the applet and it tells me the exact arguments to use
<Noah[m]>
how does that work? :) you just test until you get a response from the chip?
<whitequark[cis]>
yes
<Noah[m]>
:D
<whitequark[cis]>
you get some bus contention in the meantime but the idea is that it's short enough it doesn't damage anything (and i've yet to cause any issues despite using this applet for 5 years on the regular basis)
<whitequark[cis]>
i could do the same applet for SWD quite easily
<M9names[m]>
"interface explorer" definitely earning it's name in practice
<whitequark[cis]>
I came up with the concept for this device because I wanted to play with as much electronics as possible but if you are required to write one-off dirty Arduino firmwares for everything you want to interface with, it makes you die inside enough that you just don't do much of it
<whitequark[cis]>
which is why the device I designed has an incredible level of flexibility and uses every last bit of it
<whitequark[cis]>
recently I reverse-engineered an entire SDR board (with completely unknown ... everything) using nothing but a glasgow and an oscilloscope
<whitequark[cis]>
it has an IMXRT1052, two SPI flashes, an FPGA I now know to be XC7K325T, and two AD9361BBCZ's
<whitequark[cis]>
so I needed to capture SPI transactions to AD9361's, reprogram SPI flashes, use Vivado to poke at the FPGA via Xilinx Virtual Cable, debug and program the IMXRT via SWD, and talk to it and the FPGA via UART
<whitequark[cis]>
all of which is doable with a few variations of the command line with this one single device
<whitequark[cis]>
you can even combine e.g. Xilinx Virtual Cable and UART into a single bitstream, so you can look at what the FPGA tells you while keeping access to its programming interface and internal logic analyzer
<whitequark[cis]>
oh, I also used JTAG boundary scan to figure out the unknown FPGA connectivity. also with the same one device
<whitequark[cis]>
in the end I didn't have to deproccess the PCB or even desolder the components for the purpose of figuring out connectivity, because the boundary scan trick took care of most of it, and disassembling the XC7K325T netlist gave me almost all of the rest (you can figure out the purpose of most pins in this device by looking at the bank, which clock it's connected to, which mode it's configured in, all without actually understanding
<whitequark[cis]>
the bitstream logic)
<Noah[m]>
I wish we had a glasgow in university times :D
<whitequark[cis]>
it would be pretty good for education, I think
<Noah[m]>
we did a crapton of reverse engineering of archaic HW back in the students lab (not part of curriculum) where I learned most :)
<whitequark[cis]>
oh, wait, you are inside the repository
<Noah[m]>
ahhh hehe
<whitequark[cis]>
then this would be pipx install -e ./software[builtin-toolchain]`
<Noah[m]>
me dumb I guess
<whitequark[cis]>
* then this would be pipx install -e './software[builtin-toolchain]'
<Noah[m]>
yeah here we go
<whitequark[cis]>
perfect
<Noah[m]>
when you pasted the relative path I realized it
<Noah[m]>
I always hop into the repo automatically
<Noah[m]>
okidoki it's doing stuff :) now I need to get the pinout right :) I think this is more of an experiment with the nRF DK than anything else :D the labels and switches on that thing are questionable :D
mkj[m] has joined #rust-embedded
<mkj[m]>
I've got a couple of crates where I have a no-alloc network library, the "Core" vends out a Handle type to callers, it's just a newtype wrapper as an index to internal buffers. but that doesn't prevent someone passing the a Handle to a different wrong instance of the Core. anyone got good patterns to avoid that, apart from just storing a random (?) ID in both the Core and Handle and checking they match?
<mkj[m]>
I _think_ that a `MaybeUninit` with a `#[unsafe(link_section = ".uncached_section")]`, along with a `compiler_fence()` should be enough? You'd create a new section in the linker script `.uncached_section { } > UNCACHED`. (that's my guess, there maybe gotchas I've missed...)
<mkj[m]>
* I think that a MaybeUninit with a #[unsafe(link_section = ".uncached_section")], along with a compiler_fence() should be enough? (that's my guess, there maybe gotchas I've missed...). (edit, missed that your linker script had a scrollbar!)
<RobinMueller[m]>
what would the compiler fence do?
<mkj[m]>
that would ensure that the compiler doesn't reorder operations before/after access to the DMA area. since the compiler doesn't know that it might be modified externally. https://docs.rust-embedded.org/embedonomicon/dma.html
<RobinMueller[m]>
hmm I wonder if this is necessary when I configure the uncached memory portion as device memory
<RobinMueller[m]>
(which is also available for cortex-a)
<mkj[m]>
it looks like it uses inline assembly, which the compiler also treats as a fence so that would work? but the DMB itself is for caching within the cpu itself afaik
Foxyloxy has quit [Read error: Connection reset by peer]
<whitequark[cis]>
i think you need to add a "memory" constraint to inline assembly for it to become a fence
berkus[m] has quit [Quit: Idle timeout reached: 172800s]
<RobinMueller[m]>
but that is dsb
<RobinMueller[m]>
I need to read more about DMB/DSB usage again.. I know that zynq-rs used DMB in their driver, but maybe DSB would be even better here?
<jason-kairos[m]>
<RobinMueller[m]> "I need to read more about DMB/..." <- I have a huge thread on the EEVBlog forum about this
<jason-kairos[m]>
s/I/There/, s/have/is/
Foxyloxy has joined #rust-embedded
therealprof[m] has joined #rust-embedded
<therealprof[m]>
<whitequark[cis]> "I came up with the concept for..." <- Isn't that what "AI" is for?
<whitequark[cis]>
is it?
<whitequark[cis]>
I wrote a high-performance SWD probe gateware in about one day (12 hours or so I think). I posit that if I used "AI" for it, I would spend at least a week instead
<whitequark[cis]>
I think every time I used ChatGPT for an EE-adjacent search task, it blatantly lied to me; every time I trial Copilot or its ilk, I conclude that I would be better off without their "help"
<whitequark[cis]>
the idea that one must use "AI" to escape the boring task of writing boilerplate is, I believe, fundamentally misguided, just like the idea some hardware vendors have that what they need to make embedded programming easier is an Eclipse variant that generates C code from some high-level description. no, stop doing that. build better APIs instead, ones that leak less and fit to your mind better and are less of a pain to use. then
<whitequark[cis]>
you won't need to write (or generate) so much boilerplate.
<whitequark[cis]>
this is leaving aside any ethical considerations, which are personal and nuanced to discuss. I don't think you need to consider ethics very hard to reject most uses of a machine that generates plausibly looking bullshit and offers it to you adorned with total, ironclad confidence
<whitequark[cis]>
also Glasgow Interface Explorer dates back to ~end of 2018, which is when most uses of what we now know as "AI" were IRC bots that made funny mixup phrases on request
<whitequark[cis]>
<whitequark[cis]> "the idea that one must use "AI..." <- a lot of what Glasgow Interface Explorer offers is exactly these better APIs. you can build and load an FPGA bitstream and its corresponding host-side software with one function call. you can build a high-performance debug probe for a complex interface like CoreSight in something like 400 lines of code. you can test it in simulation in 10 LOC. you can record/replay its
<whitequark[cis]>
communication with the hardware for "virtual hardware in the loop" test in 10 more LOC. and so on. while numbers of lines of code aren't everything, they tell what I'm aiming for quite well
<whitequark[cis]>
my ARM7TDMI debugger (for a pre-CoreSight version of ARM debug macrocell) beats probe-rs in performance, despite being built in Python, because i designed a more powerful interface for running code on the DUT that is able to pipeline everything, making debug entry possible in just 2 roundtrips to the device. this is a better API!
<dirbaio[m]>
panic-immediate-abort gets rid of fmt in panics
<dirbaio[m]>
(only when building a final binary, only with optimizations. LTO required I think)
jfsimon1981a has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
<therealprof[m]>
Catherine: I fully agree. I thought it was obvious that that was a snarky and sarcastic comment, my apologies. If you browse the internet and come across "makers", they nowadays tell you how they don't even have to cut'n'paste from previous projects anymore since they can just ask ChatGPT to generate random one-off Arduino projects doing the most basic tasks. 🤷♂️
<RobinMueller[m]>
<jason-kairos[m]> "I have a huge thread on the..." <- I had a look at varying
<RobinMueller[m]>
Resources again. If I understood everything correctly, a DMB is sufficient. For example, for a DMA TX transfer, one DMB after writing the bytes to the transfer buffer befire issuing a DMA transfer start, so the DMA controller sees the updated memory. Of course I also need to do cache maintenance un that case..
<RobinMueller[m]>
s/un/in/, s/that/case/, s/case../the transfer buffer is in cacheable menory/
<whitequark[cis]>
<therealprof[m]> "Catherine: I fully agree. I..." <- oh, god no. there are people I respect for their technical skills and major contributions to Rust who are so into AI that I had no idea whether you meant it seriously or not
sroemer has joined #rust-embedded
<whitequark[cis]>
* skills and who have major contributions, * to Rust ecosystem who are
<therealprof[m]>
Got triggered by the keywords Arduino and one-off. You may notice that I always airquote "AI" since there's nothing intelligent about it at all...
<dirbaio[m]>
Artificial Incompetence
<whitequark[cis]>
no the incompetence in those cases is definitely organic
<davidmpye[m]>
Is there, does anyone know, a flash backed hashmap library around? I'm after a way of querying if an item is in the map without having to read the entire map page by page from flash
<davidmpye[m]>
as in, "If it were within the map, it would be stored at X address, so you just need to read that address to see if it's there"
<dirbaio[m]>
Ekv can do lookups in O(log N)
<dirbaio[m]>
It's only worth it if you have a *lot* of keys, like 1k-10k+.
<dirbaio[m]>
If you have less I'd use sequential-storage instead. It's O(N) but is quite fast and makes more efficient use of flash thanks to it being simpler.
<TomB[m]>
No worries, we'll torch the planet to make the new meme's though
<TomB[m]>
* the new "AI" generated meme's though
DanielakaCyReVol has quit [Quit: Idle timeout reached: 172800s]
<therealprof[m]>
<TomB[m]> "No worries, we'll torch the..." <- Sounds about right.
jfsimon has quit [Remote host closed the connection]
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
<jason-kairos[m]>
I think it's been blocked for 9 years by a bunch of things related to traits, dyn, const, etc.
pcs38 has joined #rust-embedded
<JamesMunns[m]>
<mkj[m]> "I've got a couple of crates..." <- I handle this in bbq, IMO the right API is to take a reference to your `Core` type, and have the "consume"/"drop"/"whatever" methods on the handle and not the Core. This way you can never use the "wrong" handle with the "wrong" core
sypher3[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
I handle this in bbq, IMO the right API is that your Handle should hold a reference to your `Core` type, and have the "consume"/"drop"/"whatever" methods on the handle and not the Core. This way you can never use the "wrong" handle with the "wrong" core
r[m] has quit [Quit: Idle timeout reached: 172800s]
JamesSizeland[m] has quit [Quit: Idle timeout reached: 172800s]
<FreeKill[m]>
James Munns: I'm guessing that trying to get my head around postcard rpc but _not_ over USB is just giving myself hell huh?
<JamesMunns[m]>
FreeKill[m]: It's designed to allow it (there are "WireRx" and "WireTx" so you can define any transport you want), but only USB is currently provided. There are PoC impls for uart/serial and RTT, but I haven't had time to polish and merge them.
<JamesMunns[m]>
That being said: the traits are public, so the impls don't HAVE to be upstreamed to work in your projects.
<JamesMunns[m]>
* and "WireTx" traits so you
<FreeKill[m]>
Indeed, that's what I gathered 😊 but for learning I was starting to feel like i should really use usb 😅
<JamesMunns[m]>
There’s definitely the most reference material available for usb!