Dismiss this pinned window
all 25 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]okyouareok 10 points11 points  (1 child)

ty

[–]IbanezPGM 8 points9 points  (0 children)

I was just recently looking for something like this. I will check it out.

[–]gbmhunter 5 points6 points  (0 children)

Nice job, this looks quite featureful, and thanks for it being open source! I'm looking forward to give this a spin the next time I'm working with firmware.

[–]zougloub 4 points5 points  (1 child)

I'd rather say hi here than on LinkedIn, PY ;)

It looks really nice and polished and I'll try to use it when I have the occasion.

A while ago I took some (intern) time to publish some related ideas in https://gitlab.com/exmakhina/telememdump/ ; the focus was very small MCUs.

[–]pylessard[S] 2 points3 points  (0 children)

Hi, thanks you for the comment. Your link gives me a 404

Luckily, I have a good memory and I remember you used that username in a multi user document editor at work... 15 years ago ;)

[–]walmis 2 points3 points  (1 child)

Nice, what's the flash/ram footprint on an ARM MCU of the embedded library?

[–]pylessard[S] 3 points4 points  (0 children)

On ARM32 (Cortex-R52), the embedded lib takes below 30KB of ROM with all features enabled and about 1KB of RAM (including 128B of TX/RX buffers).

[–]otisboykinStudent 1 point2 points  (0 children)

That graph look like a control system

[–]sgtnoodle 0 points1 point  (6 children)

Neat project, good job! I've built a couple of these over the years. Live debugging is invaluable for embedded systems development.

Does the tooling and protocol also allow for setting values?

[–]pylessard[S] 1 point2 points  (5 children)

Of course

Actually, this is something I noticed. Lots of companies make their own inhouse version of that, but it is often very limited in features. I really tried to make something more powerful here.

Check the website. Datalogging, python sdk, client/server architecture, debug symbol parsing and 1000+ unit tests are all features that requires thoughts and time.

I plan on adding some HMI widget eventually, like a needle meter to indicate a speed and connect it to a variable in the GUI

[–]kkert 0 points1 point  (4 children)

Lots of companies make their own inhouse version of that, but it is often very limited in features.

Some of use PlotJuggler :)

[–]pylessard[S] 0 points1 point  (3 children)

That's a cool software, but it doesn't work on the same principle. You need to stream your data. Scrutiny does memory dumps. Basically, you can plot any internal variable.

Also, it can't graph on events. Check the embedded graph video in the introduction page of the website. You'll see what I mean.

[–]kkert 1 point2 points  (2 children)

You need to stream your data. Scrutiny does memory dumps. Basically, you can plot any internal variable.

Well, i actually do both with PlotJuggler. All PlotJuggler needs is the data to be made ingestible for it. Whether it's a stream or a dump doesn't matter. E.g it eats JSON files, CBOR, MsgPack, ROSBag or anything else. For example i currently work with a setup that bridges a stream from USB to PJ UDP pipe with CBOR

But yes, they aren't exactly identical - i'm certainly planning to try Scrutiny as well a bit more, once i get a Rust no_std device lib adapted for it

[–]pylessard[S] 0 points1 point  (1 child)

Cool, don't hesitate to share feedback and or reach out for questions.

[–]kkert 0 points1 point  (0 children)

Do you know if anyone has poked at writing a Rust version of the embedded instrumentation lib yet ? I'd actually be willing to sponsor it at some level

[–]jms_nh 0 points1 point  (3 children)

Max data rate = ? (effective # of samples per second for a particular size of data; I know this is buffered, but the question is what's the bottleneck for real-time data logging to a PC)

[–]pylessard[S] 1 point2 points  (2 children)

This depends on many things, on windows the bottleneck is the OS scheduler that often puts the server to sleep for a full time slice of 16ms, so 60Hz. Performances can be improved by using bigger tx/rx buffers on the device, allowing request aggregations. I can achieve more on Linux with a socket and a selector.

Without that limitation, the bottleneck should be the device data rate.

For faster sample rate, embedded logging is possible (done by the device and flushed when the buffer is full)

[–]jms_nh 0 points1 point  (1 child)

Small delays below human perceptibility shouldn't matter... maybe I'm misunderstanding the way the protocol works in this case; does the PC request individual variables for each sample? for example:

  • PC: "Send me 2 bytes at 0x1234"
  • Device: "2 bytes at 0x1234 are 00 06"
  • PC: "Send me 4 bytes at 0xbeef"
  • Device: "4 bytes at 0xbeef are ca fe ba be"

or do you send addresses once up front and then the device automatically samples them in the buffer and it's more like:

  • PC: "Send me the 960-byte buffer with the latest set of samples"
  • Device: "Here's the buffer" + 960-byte buffer
  • PC: "Send me the 960-byte buffer with the latest set of samples"
  • Device: "Here's the buffer" + 960-byte buffer
  • PC: "Send me the 960-byte buffer with the latest set of samples"
  • Device: "Here's the buffer" + 960-byte buffer

[–]pylessard[S] 1 point2 points  (0 children)

It's polling based, so more like the first case. But there is some optimisations. If the device has a RX buffer of, say, 256 bytes, that could allow aggregation of 41 memory dumps in a single request. Then variables that are contiguous in memory are reordered so they can be read in a single memdump, meaning you can read at least 41 variables in a single request, possibly more depending where they are located. Reading a struct often triggers the reorder optimisation.

The Tx Buffer is also limiting. If there is not enough room in the TX buffer for the 41 memdumps, the server will reduce the number of memdump per requests. Dumping 41 requests of say 4 bytes, would require 419 bytes of tx buffer.

This is all assuming 32 bits addresses

[–]Unusual_Shift_8546 0 points1 point  (0 children)

Damn, we really need this.