Archaeology Resistivity Meter

Hi Michael,

I had these initial thoughts, but I've not had time to think things through (I have some time late Wednesday to do that):

There was mention of more sense probes, but maybe the expansion interface is sufficient for that, since one could drive (say) a latching relay via that. Or maybe space for on-board relay?

A minor point was, for the USB UART, for MCP2221 I already have Android code. But FTDI is totally fine too, i.e. if you've already got the schematic entered for that portion then it's quicker for me to just hunt for demo code for FTDI, if you let me know the chip number. Below is the the schematic I've used previously for the MCP2221 (it needs an external 3.3V regulator which probably the FTDI device doesn't, and has 4kV protection which likely isn't enough, I didn't place any additional ESD protection on this schematic).

One other thought was for a test facility, if there was were four jumpers or four DIP switches on the board which would connect a potential divider across the source (two switches for that) and two switches to connect the sense wires to the divider. Maybe jumpers are easier. But probably there will be test points on the board for easy soldering of a mini test harness during software development anyway.

Hi Michael

I agree with your points entirely, I also agree that we need to get to a working prototype as quickly as possible, I'm sure this will prove the theory.

Ken

Thanks Michael,

I have heard of V=IR before, the problem is that it is not a simple resistor. At 50m between P1C1 and P2C2, the 'device' under test is approximately thirty thousand cubic metres of potentially-soggy interference-laden non-homogeneous earth; and if you go out to 100m as Ken mentioned he could with his commercial rig, its over a quarter of million cubic metres of earth in the circuit.

I'm sorry if I'm not being clear, if I may, I'll try and explain the sequence differently.

Phase 1: leading edge of square wave, try to apply, say, 10mA.

Constant current source will apply as much voltage as it is able/allowed to.

It can take maybe 2mS or more to get the injection stable(*1). There is no point in trying to measure until the injection is stable.(*2)

Phase 2:

Injection is stable, starting measuring P1P2, repeat as many times and as fast as possible until end of pulse. Apply filtering to try and get best reading.

Phase 3:

Reverse polarity.

Repeat above until get consistent filtered voltage and hence res, or until some form of timeout. Typically may sample for 20-50 full cycles.

*1) 2mS is a reasonable time for injection to stabilise, and usually works fine with 137Hz reversal, but in some conditions the 3.75mS pulse can expire before injection stabilises, which is why some modern commercial kit offers option to reduce reversal rate down as low as 17.5Hz

*2) I appreciate you could use processor ADC as, I think both you and Shabaz mentioned, to monitor this by looking for output voltage is stable and not maxed-out, and that might be sufficient indication for square-wave, but still believe that proper digitised value of the instantaneous current actually being injected will be necessary to explore non-square-wave excitation.

Dave

OK - great - I've made some progress on designing the input circuits and I might be able to post something by the weekend.

Unfortunately for this project, real work has picked up somewhat recently (although it's a welcome thing for me of course) so I have

less time free than I had.

I'm happy to take the electronic design as far as laying out a pcb and even building one or two but it would be nice to have a

volunteer or two to do software !

For now I'll post schematics as .pdf in this group - I can set up a Github repo if you would like (although I'm no expert in Git -so very

happy for some one else to do it if they can.)

MK

Hi Michael,

Better to be busy than not! : ) I've been a little tied up too, but will download the development environment and start getting used to the support libraries (not used ST's dev environment but am sure I can get up-to-speed quickly).. I'll be able to write code and test it on an off-the-shelf ST dev board, and then can try to bring up a board from a PCB as the hardware is developed.

I'll order a dev-board just as soon as I can find the processor number.. I think you typed it but it's buried in the hundred comments : )

EDIT: I think it is STM32L4R5VGT6 from a sketch, and the suitable board is NUCLEO-L4R5ZI (just a higher pin-count chip with I/O that can be ignored, and more RAM).

If that's correct, I'll go ahead and get that ordered.

Also, incidentally if it is that device, then Mbed OS is supported too : ) (Mbed doesn't support all processors, only very specific ones). I'm very familiar with that, and could speed up development a lot. (Mbed has an RTOS (RTX), huge suite of library functions, and a development environment famous for being online, but is downloadable - it uses GCC and Python scripts. But happy to use ST environment too. I could try both initially, until there's some skeleton code.

I was hoping you might

I'll look at the implications of using the exact same processor as the Nucleo board - it's one less thing to worry about if the code just drops in.

I have to say that my experience with RTOS and library code on these processors is very negative, but I've not used Mbed so that might be better.

My usual route is Keil tools (not an option here because much too expensive) and my own register access level code for almost everything else.

I'm interested in ST's development environment which I believe is truly open source.

MK

I've had a quick look at the Nucleo boards - there are two - one for the standard processor and one for the P version.

Farnell have no stock of P type processors so I'm going for the standard version.

(The P types can use an external SMPS to drive the core - I'll try to design our board to use either but I don't expect to

use the external SMPS - it offers no advantages in this application.)

I've ordered a Nucleo (Farnell 2845537)

The Nucleo processor has 144 pins and 2M of flash. (The extra pins won't hurt and may help so I'll design the board for the same chip.)

MK

shabaz  wrote:

 

...

 

...I think it is STM32L4R5VGT6 from a sketch, and the suitable board is NUCLEO-L4R5ZI (just a higher pin-count chip with I/O that can be ignored, and more RAM).

If that's correct, I'll go ahead and get that ordered.

Also, incidentally if it is that device, then Mbed OS is supported too : ) (Mbed doesn't support all processors, only very specific ones). I'm very familiar with that, and could speed up development a lot. (Mbed has an RTOS (RTX), huge suite of library functions, and a development environment famous for being online, but is downloadable - it uses GCC and Python scripts. But happy to use ST environment too. I could try both initially, until there's some skeleton code.

It's that device Farnell 2845537.Farnell 2845537.

I don't have one, but checked, and the off-line MBED studio supports it with MBED OS 6.

Also supported by CubeIDE so all options are open.

Hi Michael,

Great, I'll get that board ordered too.

I've installed the ST dev environment to get some familiarity, and will try to sketch about how things could function in the software in the next couple of days.

I'm thinking when it comes to the code, to write the first bits for both the ST environment and mbed environments, so that we have some options initially, and eventually just sticking with one stream as I get up-to-speed adding more and more code features (i.e. likely ST since you're familiar with it too).

I'm not very familiar with the ST compiler tools - only the libraries. So I'm perfectly willing to be converted to mBed for this project.

I'd be very interested to hear about your comparison of the tools.

MK

Hello, I had a bit of time left at the end of today and installed the MbedStudio I had downloaded.

That was the good bit, then I tried to run it - OMG - what a disapointment !

It flouts all the usual windows standards of look and feel so I found it a total pig to navigate, It doesn't have functional Help in the usual way.

There is a help itme in the menu bar but it doesn't provide a normal Help facility at all.

I got it to load up the "bare metal blinky" example - which is still a .cpp file relying on an OS. It included masses of odd files (including things like CAN drivers).

And worst of all it doesn't build - there are errors relating to some deprecated legacy file (writing from home now so  I don't have it in front of me.)

That's when the lack of Help really bit - I couldn't work out how to close the current project and open a new example file - aargh - then it was time to go home.

This evening I downloaded the ST CubeIDE.

I am familiar with the Cube thing for setting up pins  and clocks. The clock thing is actually quite useful. The way the ST tools "organise" the generated code is disgusting,

But that's OK - you just put things somewhere sensible.

The generated code compiles witout errors.

And of course the IDE is Eclipse so looks and behaves like we've all got used to.

The Help still isn't a patch on Keil's but it does a good bit more then the Mbed.

So on the basis of this very quick and quite unfair test - I'm going to play more with the ST tools.

I'm very keen to hear if you can get the Blinky to work on Mbed.

(Is there a way of keeping it to C or Mbed fundamentally C++)

MK

Hello, I had a bit of time left at the end of today and installed the MbedStudio I had downloaded.

That was the good bit, then I tried to run it - OMG - what a disapointment !

It flouts all the usual windows standards of look and feel so I found it a total pig to navigate, It doesn't have functional Help in the usual way.

There is a help itme in the menu bar but it doesn't provide a normal Help facility at all.

I got it to load up the "bare metal blinky" example - which is still a .cpp file relying on an OS. It included masses of odd files (including things like CAN drivers).

And worst of all it doesn't build - there are errors relating to some deprecated legacy file (writing from home now so  I don't have it in front of me.)

That's when the lack of Help really bit - I couldn't work out how to close the current project and open a new example file - aargh - then it was time to go home.

This evening I downloaded the ST CubeIDE.

I am familiar with the Cube thing for setting up pins  and clocks. The clock thing is actually quite useful. The way the ST tools "organise" the generated code is disgusting,

But that's OK - you just put things somewhere sensible.

The generated code compiles witout errors.

And of course the IDE is Eclipse so looks and behaves like we've all got used to.

The Help still isn't a patch on Keil's but it does a good bit more then the Mbed.

So on the basis of this very quick and quite unfair test - I'm going to play more with the ST tools.

I'm very keen to hear if you can get the Blinky to work on Mbed.

(Is there a way of keeping it to C or Mbed fundamentally C++)

MK

I compiled the blinky for OS6 on mbed studio for your board and it compiled correctly. See small screen capture I posted above.

I too prefer the Eclipse way of working more than MBED Studio. But not that much more that it would decide a way forward.

Hi Michael,

I've not used MbedStudio, but Mbed capability is also a bunch of Python scripts replacing the usual Makefile. I've used that (on Linux, but in theory workable with Windows), i.e. using any text editor (e.g. Visual Code) and then using the command line to run the script to build the project, and another command to program the board. It's possible to create a script, i.e. type something like ./install in order to flash the device. Visual Code allows the command line to be dispensed with, but it's just a preference thing.

The language when working with Mbed is partially C++, the main benefit is the libraries are nice (they're high-level, since the same APIs have to work with other manufacturer devices too). Some of the APIs use C++ functionality however, so typing in pure C is not possible.

I'm currently writing some ideas on paper, at first thought there seems to be about 8 'work areas' a user might want to get involved with, and each seems to be separate so that can make things easier, i.e. launch into any work area based on user input or otherwise. But I'll probably focus on the core area first (calling it Survey for now) since by trying to design that (on paper) it will force me to concentrate on the important bits of the main functionality, so that code for testing bits of hardware is quicker to be done.

Also, if you know which Flash chip you want to use, I can order that too, so I can play with getting some basic file method to meet all the workflow areas to the extent of being enough for a prototype.

The ideas so far are (not really user stories, just very brief half-baked brainstorming, I've only spent 10 mins on it so far : )

EDIT:  From Jan's screenshot it looks like ARM have implemented MbedStudio on top of a modification of Microsoft Visual Code, the icons and layout look very similar.

I wasn't originally a fan of Visual Code, but it's flexible to a lot of coding tasks, and so many coders use it now, that it's likely to remain around for ages. I like that it's extremely expandable, but there's definitely a learning curve to it - lots is unconventional with it : (

I used to use the paid 'UltraEdit' but it offers low value now that Visual Code is around.

Thanks for note.

Here's a bit of the Mbed console output during compile:

Building project mbed-os-example-blinky-baremetal (NUCLEO_L4R5ZI, ARMC6)
Scan: mbed-os-example-blinky-baremetal
Compile [  0.4%]: mbed_tz_context.c
Compile [  0.8%]: AnalogOut.cpp
Compile [  1.2%]: AnalogIn.cpp

ABOUT 240 other compiled files skipped !!!!!!!

Compile [ 99.2%]: USBPhy_STM32.cpp
Compile [ 99.6%]: trng_api.c
Compile [100.0%]: watchdog_api.c
Link: mbed-os-example-blinky-baremetal
[Warning] @0,0: L3912W: Option 'legacyalign' is deprecated.
[Error] @0,0: L6218E: Undefined symbol Image$$ARM_LIB_HEAP$$ZI$$Base (referred from BUILD/NUCLEO_L4R5ZI/ARMC6/mbed-os/platform/source/mbed_sdk_boot.o).
[Error] @0,0: L6218E: Undefined symbol Image$$ARM_LIB_HEAP$$ZI$$Limit (referred from c:\ProgramData\Mbed Studio\mbed-studio-tools\ac6\bin\..\lib\armlib\mc_w.l(malloc2.o)).
[Error] @0,0: L6218E: Undefined symbol Image$$ARM_LIB_HEAP$$ZI$$Length (referred from BUILD/NUCLEO_L4R5ZI/ARMC6/mbed-os/platform/source/mbed_sdk_boot.o).
Warning: L3912W: Option 'legacyalign' is deprecated.
Error: L6218E: Undefined symbol Image$$ARM_LIB_HEAP$$ZI$$Base (referred from BUILD/NUCLEO_L4R5ZI/ARMC6/mbed-os/platform/source/mbed_sdk_boot.o).
Error: L6218E: Undefined symbol Image$$ARM_LIB_HEAP$$ZI$$Limit (referred from c:\ProgramData\Mbed Studio\mbed-studio-tools\ac6\bin\..\lib\armlib\mc_w.l(malloc2.o)).
Error: L6218E: Undefined symbol Image$$ARM_LIB_HEAP$$ZI$$Length (referred from BUILD/NUCLEO_L4R5ZI/ARMC6/mbed-os/platform/source/mbed_sdk_boot.o).
Finished: 0 information, 1 warning and 3 error messages.
[ERROR] Warning: L3912W: Option 'legacyalign' is deprecated.
Error: L6218E: Undefined symbol Image$$ARM_LIB_HEAP$$ZI$$Base (referred from BUILD/NUCLEO_L4R5ZI/ARMC6/mbed-os/platform/source/mbed_sdk_boot.o).
Error: L6218E: Undefined symbol Image$$ARM_LIB_HEAP$$ZI$$Limit (referred from c:\ProgramData\Mbed Studio\mbed-studio-tools\ac6\bin\..\lib\armlib\mc_w.l(malloc2.o)).
Error: L6218E: Undefined symbol Image$$ARM_LIB_HEAP$$ZI$$Length (referred from BUILD/NUCLEO_L4R5ZI/ARMC6/mbed-os/platform/source/mbed_sdk_boot.o).
Finished: 0 information, 1 warning and 3 error messages.

Notice that this "bare metal" blinky compiles more than 240 files !!!

The actual Blinky is this:

/* mbed Microcontroller Library
 * Copyright (c) 2019 ARM Limited
 * SPDX-License-Identifier: Apache-2.0
 */

#include "mbed.h"

#define WAIT_TIME_MS 500 
DigitalOut led1(LED1);

int main()
{
    printf("This is the bare metal blinky example running on Mbed OS %d.%d.%d.\n", MBED_MAJOR_VERSION, MBED_MINOR_VERSION, MBED_PATCH_VERSION);

    while (true)
    {
        led1 = !led1;
        thread_sleep_for(WAIT_TIME_MS);
    }
}

I have about a million problems with this but the main ones are:

Even a simple project is dependent on literally hundreds of unknown files - an error in any one of them will break it.

Its typical of what I would call 2nd decade code - everything slowly percolates down to the hardware though layer upon layer of abstraction (obfuscation !).

The error is typical of this approach - I have no idea why we need to build mbed_sk_boot or what legacyalign was meant to do, (or how it can be wrong in example code) !

I come from a hardware for mass production/ high reliability back ground and I aim for:

• Every line of code should be embedded in the project itself, so it can be rebuilt, byte accurate, 10 or 20 years later.
• Every line of code should be traceable to a requirement in the specification (rarely met except in aerospace but a good goal).
• There should be no dead code.
• The code should be as simple as possible, for example timers should be set up by direct control register writes, rather than through some opaque API call
• which has stuff to work 100 timer features not present on the hardware you are working.

It seems to me that the Mbed approach is aiming for a sort of baby Linux on embedded processors - there will be places where that is a good thing but it's not the route I would choose for this project.

Having said that, if others really want to go that way, I won't throw my toys out of the pram.

The core code on the processor needs to be able to set up some circular buffers for data from its own and the external ADCs and DACs and DMA for SPI to the FPGA and for the internal ADCs and DACs.

It will have to support regular maintenance of these buffers - probably at a faster rate than a typical OS tick rate.

I'm assuming that the  Mbed OS will support this (although a super loop would do it better and more transparently ) so I can't see why the thing shouldn't work in Mbed.

MK

Michael, I think you will like the CubeIDE approach more (or dislike less ).

There's still a HAL above the register layer, but a more traditional one.

Yes, you are quite right.

And although I don't like the HAL I know it well - so I use it but mostly as a reference, but sometimes as intended.

There is a lightweight HAL but I don't think you can make the Cube tools generate a project based on it.

MK

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.