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.

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

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.

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.