Archaeology Resistivity Meter

Having started coding my LoraWan custom board using mbed I eventually switched over to CubeIDE.  The mbed environment is confusuing at times especially when creating a custom board for the first time.  It even kept switching my board type occassionally???    You do get a lot of code for free but it needs better documentation especially when creating a custom board.   And as mentioned above, you'll pull in more code than you need.

My vote at this time (I really want mbed to succeed) is to go the CubeIDE route.  Add in a 6pin SWD connector and you can step through the code line by line in the debugger (I used a Tag-Connect cable. Saves a connector on the board).

Other people may have better experience.  I've come from a Eclipse env (not great) for LynxOS and Visual Studio.

There will definitely be a debug connector (with the SWD pins), maybe even with the full ETM pins as well.

(I'm still hoping someone will bring out a cheap debugger pod that supports it.)

MK

Hi Ken,

The tag works great, thanks!

Now it's easy to access all content related to this archaeology meter project.

Hi Michael and Rob,

Sorry you had a bad experience with this.

My current status is to try the code design as a paper exercise, and then some skeleton using the ST dev environment, but I'll simultaneously get code running on Mbed too if I can, just in case.

The architecture can be nicer with the OS, but I'll use a more traditional implementation with the ST dev environment.

Two bits of reference code could be a benefit, I cannot tell how large and how many features could be desired for later add-on. 

Mbed is C/C++, so direct writing to registers etc isn't an issue. The Mbed benefits are the diverse libraries for adding new features and the task handling (and it works well with interrupt handling) that is available.

I've been involved with bare-metal mil-customer projects too, custom-written RTOS, and Linux+huge middleware+C++ (which suits a very different sized project). I am excited about (say) one day add-ons (such as sending data in real-time via a network, or adding different tasks) then Mbed has got a lot covered, but it's unnecessary for the core functions.

That's a weird error, the output shows that MbedStudio is defaulting to an ARM-supplied compiler. With Linux, I can default to GCC with Mbed.

Bad that MbedStudio didn't work by default though.

I tried to compile the blinky on Linux with Mbed with GCC, and the particular errors in your comment refers to symbols in particular files, but the GCC-made version of the file I checked doesn't contain that symbol at all.

Regarding unwanted code, it is possible to delete some of it (for instance unused peripheral code), but by default Mbed will add it.

This is output for the blinky project on the command line with Linux, it's interesting to see which things took the code space (there is a normal map output too, this is just the summary output on the command line after the build).

The output shows the C library used almost half the total code, and about 13 kbytes was used for the basic peripherals (mbed-os/targets entry), OS consumed 6 kbyte, and the user-typed blinky code took 80 bytes, etc. I think this is reasonable (and no messing about having to struggle with 'lighter' versions with reduced printf formatting etc., but is a shift from only having code in there that is known to execute (but as you say that's rare to accomplish).

| Module           |         .text |       .data |        .bss |
|------------------|---------------|-------------|-------------|
| [fill]           |     102(+102) |       8(+8) |     19(+19) |
| [lib]/c.a        | 27372(+27372) | 2472(+2472) |     89(+89) |
| [lib]/gcc.a      |   3116(+3116) |       0(+0) |       0(+0) |
| [lib]/misc       |     180(+180) |       4(+4) |     28(+28) |
| mbed-os/drivers  |     174(+174) |       0(+0) |       0(+0) |
| mbed-os/hal      |   1672(+1672) |       8(+8) |   130(+130) |
| mbed-os/platform |   4228(+4228) |   260(+260) |   280(+280) |
| mbed-os/rtos     |   6880(+6880) |   168(+168) | 6228(+6228) |
| mbed-os/targets  | 13320(+13320) |       8(+8) | 1078(+1078) |
| test.o           |       80(+80) |       0(+0) |     28(+28) |
| Subtotals        | 57124(+57124) | 2928(+2928) | 7880(+7880) |
Total Static RAM memory (data + bss): 10808(+10808) bytes
Total Flash memory (text + data): 60052(+60052) bytes


Image: ./BUILD/NUCLEO_L4R5ZI/GCC_ARM/testprog.bin

Anyway, I'll concentrate on the high-level code design, this was just out of curiosity to check the ST-targetted Mbed can work on linux.

I built the bare metal one on a windows box and got the same errors as Michael:

It's a brand new MBED Studio install from last weekend, not fiddled with any settings.

Nice to know it's not just me !

I have my Nucleo board so I'll see if it will play with the ST tools.

MK

Unfortunately I don't know how to troubleshoot that, I'm a lot happier with Linux+GCC since I've used that.

It's a fundamental issue though, since it's related to heap settings expected somewhere... but could be a bug in the ARM-developed toolchain or (perhaps more likely) MbedStudio.

I think it's more likely MbedStudio, because I tried the online cloud version of Mbed to compile the blinky program, and that worked. It took 10 minutes, which was 5 minutes longer than usual, because there's only one example for the Nucleo board, and the blinky example was slightly incorrect (for C++) so it needed correcting.

I don't have the Nucleo board just yet (ordered it today), but I had a F746G board (quite powerful too!) and out of curiosity I tried running a filter. It was unfortunately unrealistic (I pretended to sample at 10kHz, which was a typo, I'd wanted 1 kHz) but the results were nice.. with 255 coefficients though!

This was the expected result (simulating 5Hz wanted in red (would be zero Hz wanted of course), and 82 Hz unwanted, with a cut-off at 10 Hz (unrealistic amplitudes too, since the wanted signal could be much smaller than the unwanted):

:

and this was the result with mbed-dsp (guessing is just a wrapper of CMSIS DSP functions, so should be identical to doing it on the ST environment, I just have not investigated that yet). This was with printf to output the values to a serial terminal, and then put them in matlab to plot them) - blue is output, and green was the expected result, I didn't plot them aligned:

I didn't get any timing since this was just a late-night coding experiment, but it's extremely impressive how much processing power these devices have. To think this wasn't possible with low-power microcontrollers maybe just a decade ago.

It will be better to use Matlab tools I guess for designing the filter (I'm not knowledgeable on filter design at all) and for now the filter was calculated using a Python program found online (can write that up). Anyway this is all premature coding experimentation, but does give comfort that ARM DSP capabilities are nice!

There has been an ominous silence since I published the input amplifier design a couple of weeks ago.

(You can find it by searching the armp tag.)

MK