Let's made a PC-base metal detector with usb interface !!!

[Sulaiman]

Aziz be careful from german people

[gwzd]

Aziz be careful from german people

Yeah, be careful, they might just hug and kiss you!
RA

[Sulaiman]

hahaha lool even they gave me a BMW !!!

[Aziz]

MCU/PI controller architecture changes

Hello friends,

I ran completely out of I/O ports of the ATmega MCU now.

A flexible hardware controller design requires more I/O lines (most of them are output only). But I do not want to change the MCU type. I still want to use the Atmel chips (PDIP 40 variants).

There is a tricky way of expanding I/O port. A parallel, fast and transparent method will allow expanding it up to 64 (or more) I/O output lines by only having 10 output lines overhead (8-bit data/address bus, 2-bit control lines: address-latch-enable, data-latch-enable).

Port expansion gives some benefits:
- more peripheral functions free useable now (PWM's, analog comparator's, ..)
- the new I/O port lines will be decoupled from the MCU and will have less noise on it. As lots of lines will control analog multiplexing parts, so this shouldn't degrade the SNR much. Direct MCU lines have lots of noise on it.

I will extend one port of the MCU into up to 32 bits (four 8-bit ports). These four ports will controll all PI peripheral parts and will be implemented on a different board. I will group the four new ports to their functionality to reduce port changes. Port changes need more execution cycles but once selected, there is no difference to normal port access functions (transparent latches). I would be able to control up to 8 additional 8-bit ports but four ports should be really enough. Due to PI processing nature, ports changes are not time critical and if the port functions are well grouped together, there are few port changes required only.

Port-TXcontrol
TXON1
TXON2
NFETctrl (blanking fet)
PFETctrl (blanking fet)
free: 4 (reserved for new ideas)

Port-PGA+Config
PGAgate
PGA0
PGA1
PGA2
free: 4 (reserved for configration)

Port-Channel1
Integrator1Gate+
Integrator1Gate-
Integrator1Clear
Integrator1CapFB
S&H1
S&H2
free: 2

Port-Channel2
Integrator2Gate+
Integrator2Gate-
Integrator2Clear
Integrator2CapFB
S&H3
S&H4
free: 2

Integrators can be modified into an inverting amplifier design if the integration capacitor is switched out (Integrator1/2CapFB). Depending on the IntegratorGate1/2+, IntegratorGate1/2- MUX gates, the polarity can be changed and it should be possible to sample direct voltage levels instead of their integration values.

I also designed some interesting VCA's (voltage controlled amplifier). The PGA could be replaced, if the VCA is working better (more dynamic range and flexibility). VCA need a PWM output to realize a DAC output. Or I might even spend another 8-bit port for a true DAC chip (cheap and less overhead).

Development continues - but with slow steps.

Aziz

[Aziz]

Hello friends,

I want to start with the following simple MCU design, which allows me more I/O lines for experimenting and extending. As you can see, I am supporting only the RS-232 interface at the moment. The USB implementation is also very easy using the FD232R chip but the darn chip isn't available in PDIP pinout and it is quite difficult to solder it (flysh1t small).

The port extender is implemented as all output ports and will be controlled by the software. Some of the unused pins of the MCU could still be used as input lines.

I have not tested this design yet and will start to solder it soon. If you find a bug, then let me know.

Aziz

[Aziz]

MCU board finished.

Hello friends,

the new MCU board is finished and is running.

I had to modify the circuit slightly:
The MAX232 chip is causing high frequency spikes on the +5V digital power supply. This is normal due to implemented DC/DC converter running at >100 kHz. So the MAX232 chip must be supplied at the choke (L2) output. Add additional bypass electrolytic capacitors to C2 (100 µF at least) and C12 (10 µF at least). The choke itself should be increased in inductivity to reduce more noise.

Now the MCU caused noise levels on I/O pins:
High output level: 80 mVpp
Low output level: 40 mVpp

Analog multiplexing I/O lines should therefore be decoupled with bus-buffers or similar solutions. The noise is a high frequency noise (CPU frequency 16 MHz) and is easily inductive/capacitive coupled to sensitive analog parts. So never use them directly from the MCU.

I probably will power up the port extender with much cleaner +5V analog supply. I will add more chokes to my modules next time.

Aziz

[Aziz]

Port Extender Finished.

Hi all,

I just have finished the port extender module. It is running so far. I currently didn't have the 74HC238 DIL chip at home so I have selected via hard-wired just the PORTE active and the others inactive.

Now the I/O port lines have much less noise on it: 3-4 mVpp noise regardless of its state (logic 0/1). It even can be improved further, if the power supply of the port extender is removed from power supply noise.

I did forget to mention, that all 74HCxxx chips in the port extender module should have each 100nF bypass cap on its supply pins. The schematics is not showing this yet.

The power startup default output of the external ports is 0 (all output ports logic 0).

I have a 74HC238 SMD version and will think of modifying it to a DIL version.

Never control sensitive analog units with direct MCU I/O pins!


Aziz

[Aziz]

Hi all,

here is some comment on how to access the external ports (port E, F, G, H):

ALE and DLE bits should be initialised to logic 0 at start-up time. Then all external ports should be initialised to their default values using the general port access procedure below:

General port access procedure:
DLE = logic 0 (disable data latch)
PORTC= external port address (0=port E, 1=port F, 2=port G, 3=port H, ..)
ALE = logic 1 (make address latch enable)
ALE = logic 0 (external port adress now latched=stored)
PORTC= port data (write data to port)
DLE = logic 1 (make external selected port transparent)

Now all PORTC accesses will be visible and transparent to the selected external port (DLE=1). A small latency time is there due to typical propagation delays of the chips (74HC541: 9 ns, 74HC573: 14 ns, total: 23 ns). Reading of PORTC is only valid to a selected external port and does not support reading other external ports (all output). So the application needs to know, what is stored in the external ports. External port changes require a full initial write to the selected port.

The ALE and DLE bits can be set and cleared using the bit set or bit clear commands. The time overhead for port changes is not critical as we have lots of wait timings. So the wait timings could be reduced due to port change overhead.

Aziz

[Aziz]

RS-232 interface is working.

Hi all,

the RS-232 interface seems to work (transmit & receive). I did not decide the final baud rate yet. It depends on the communication processing mode. The MCU has only one character receive buffer and the data must be taken out as soon as possible until next data is received. Some time-critical commands won't permit nested interrupts or will block the main program flow for some period and if the received character isn't read out in time, it will be lost. A FIFO buffer would be good - but there isn't any.

Only the receive path to the MCU is critical (laptop side has FIFO buffer chip). But there are several ways of handling the communication:
- high speed communication with error detection and repetition flow control (at 115.2 kBaud)
- low speed (9600 Baud, low communication overhead, max. one character per transmit pulse rate)
- switching between communication mode and processing mode

Anyway, the communication is not critical. I will see, which option will work well.

I probably will support several compatible 40 PDIP AVR MCU variants:
ATmega16-16PU, 16 MHz (I have samples)
ATmega32-16PU, 16 MHz (I have samples)
ATmega164P-20PU, 20 MHz (improved ATmega16)
ATmega324P-20PU, 20 MHz (improved ATmega32)
ATmega644P-20PU, 20 MHz (I have samples)
ATmega1284P-20PU, 20 MHz (no source found yet)

Only minor firmware changes are required to support different MCU's. But it gives second source as well as discontinued MCU flexibility options.

I will give a go to the ATmega644P-20PU chip at 20 MHz first. The internal 4 kB SRAM should be by far big enough for complex PI firmware coding.

I will order the missing 74HC238 chip today and will test the port extender soon, whether it is working or not.

Aziz

[Aziz]

New improved AVR MCU's available

Hi all,

I have found some architectural changes on AVR MCU's. Atmel has changed some naming conventions to the improved MCU's:
ATmega644P will be designed up to 16 MHz now.
ATmega644PA will support 20 MHz and has less power consumption (it doesn't count much, as we waste huge power in the coil).

The older ATmega644P-20PU model still supports 20 MHz. There is no code changes necessary to the advanced PA version. Only electrical specification differencies exist. I have not found a source for newer models yet.

I have now a running ATmega644P-20PU version (20 MHz). If I can get other MCU's, I will support them too.

Main architectural changes between different models are:
- memory organision (start, size, interrupt vectors)
- I/O port address changes, I/O port bits changes
- extended I/O port access (additional cpu clock cycles necessary)
- additional/other peripherals
- speed (relevant for timers and RS232 interface)

The conditional compiling of source code handels all different MCU's quite well. So there is no problem at all.

I should get the new parts soon and can test the MCU board and port extender board together.

Aziz

[Aziz]

Hi all,

see below the external port change CPU op-code implementation:
syntax: PCH <addr8> <data8> (3 byte op-code)

..
//-------- External Port Definitions  ---------
#define    EXTPORT_CTRL  PORTD
#define    EXTPORT_ALE   6 // pin #20/PD6/ICP1
#define    EXTPORT_DLE   7 // pin #21/PD7/OC2
#define    EXTPORT_PORT  PORTC
 
..
 
// Op-code implementations
 
..
 
//CMD_PCH: Change external port and write data
// syntax: PCH <addr8> <data8>
// addr8: Port Address (byte: 0=PORTE, 1=PORTF, 2=PORTG, 3=PORTH, ..)
// data8: Port Data (byte: 0-255)
; clocks: 6+14 = 20 (16 MHz: 1250 ns, 20 MHz: 1000 ns)
Cmd_PCH:
     ld    PI_Param1, PI_PC+         ; (2) Get External Port Address
     ld    PI_Param2, PI_PC+         ; (2) Get External Port Data
 
     ; Port Address Access
     cbi   EXTPORT_CTRL, EXTPORT_DLE ; (2) Disable Data Transparent-Latch
     out   EXTPORT_PORT, PI_Param1   ; (1) Write External Port Address
     sbi   EXTPORT_CTRL, EXTPORT_ALE ; (2) Enable External Port Address Latch
     cbi   EXTPORT_CTRL, EXTPORT_ALE ; (2) Latch External Port Address
 
     ; Port Data Access
     out   EXTPORT_PORT, PI_Param2   ; (1) Write External Port Data
     sbi   EXTPORT_CTRL, EXTPORT_DLE ; (2) Enable Data Transparent-Latch
 
     CMD_PREFETCH                    ; (4) Macro: Prefetch next op-code and decode

The code above makes secure access to the external ports possible. The op-code execution time of PCH is 1µs at 20 MHz. Once the external port is selected, other port access op-codes (write, bit-manipulating) will run faster. The long lasting execution time is really not critical.

Aziz

[Aziz]

Hi all,

external port access implementations are getting quite efficient. See below the port store op-code implementation:
syntax: PST <data8>

//CMD_PST: Store data into external port (parameter: port-data (byte) )
// direct op-code vector implementation
// syntax: PST <data8>
// data8: Port Data (byte: 0-255)
; cycles: (4) + 3 = 7 (16 MHz: 437.5 ns, 20 MHz: 350 ns)
.ORG Cmd_Vector+CMD_PST
    ld  PI_Port, PI_PC+       ; (2) Get External Port Data
    out EXTPORT_PORT, PI_Port ; (1) Write External Port Data
 
    CMD_PREFETCH              ; (4) Macro: Prefetch next op-code and decode

Introducing a global backup register for portc (register PI_Port), few cycles can be saved further. To minimize the op-code prefetching and decoding cycles, there will be double access op-codes available (store and bit-manipulating).

The NOP op-code requires 4 cpu-cycles (4*50 ns = 200 ns) which gives not much fine time resolution. There will be some tricky way, which will make just one cpu-cycle (50 ns) timing alignment possible. So the application firmware compiler will handle such accurate timings between delays.

Aziz

[Aziz]

Hi all,

now the trick with 50 ns timing resolution delays (at 20 MHz):
The NOP op-code has 200 ns instruction cycle time (instruction prefetching and decoding, no execution). Successive more NOP's in the controller firmware does not achieve the 50 ns timing resolution (only 200 ns resolution).

The solution is to introduce four different NOP instruction op-codes:
NOP: 200 ns
NOP1: 250 ns (+1 cpu cycle)
NOP2: 300 ns (+2 cpu cycle)
NOP3: 350 ns (+3 cpu cycle)

With the combination of the NOP(x) op-codes, a 50 ns timing resolution can be achived.

For instance: 550 ns delay
NOP (200 ns)
NOP3 (350 ns)
Total: 550 ns

Same applies to the delay op-codes (variable counter delays, 8-bit, 16-bit). So there will be sufficient op-code variations, which allow exact 50 ns timing resolution during delay timings.
The application typically has lots of wait timings between controller actions. Using convenient delay op-code will lead to exact timing even the CPU simulation is not fast enough as the MCU (ATmega) itself.

See below the NOP(x) instruction implementations (direct vector coded):

//CMD_NOP3, NOP2, NOP1, NOP: no operation (direct implementation)
// NOP3 cycles: (4) + 3 = 7 (16 MHz: 437.5 ns, 20 MHz: 350 ns)
.ORG Cmd_Vector+CMD_NOP3    ; NOP+3 cpu-cycles
     nop
// NOP2 cycles: (4) + 2 = 6 (16 MHz: 375 ns, 20 MHz: 300 ns)
.ORG Cmd_Vector+CMD_NOP2    ; NOP+2 cpu-cycles
     nop
// NOP1 cycles: (4) + 1 = 5 (16 MHz: 312.5 ns, 20 MHz: 250 ns)
.ORG Cmd_Vector+CMD_NOP1    ; NOP+1 cpu-cycle
     nop
// NOP cycles:  (4) + 0 = 4 (16 MHz: 250 ns, 20 MHz: 200 ns)
.ORG Cmd_Vector+CMD_NOP     ; NOP
     CMD_PREFETCH           ; (4) Macro: Prefetch next op-code and decode

Note, the instruction code of NOP1 = code(NOP) - 1. Entering NOP3 will fall through NOP2, NOP1 and finally to NOP. The NOP instruction itself has no execution code and will start immediatelly with the next instruction prefetching and decoding.

Now the 8-bit counter delay (active delay) implementation (SWAIT, short wait):

 
//.. SWAIT decoding part (vector)
 
//CMD_SWAIT2: active short wait, parameter: 8-bit delay counter
.ORG Cmd_Vector+CMD_SWAIT2  ; SWAIT+2 cpu-cycles
     nop
//CMD_SWAIT1: active short wait, parameter: 8-bit delay counter
.ORG Cmd_Vector+CMD_SWAIT1  ; SWAIT+1 cpu-cycle
     nop
//CMD_SWAIT: active short wait, parameter: 8-bit delay counter
.ORG Cmd_Vector+CMD_SWAIT
     rjmp Cmdexe_SWAIT      ; (2)
 
//.. SWAIT implementation (execution code)
//.. somewhere above 0x0100 program code address
 
//CMD_SWAIT2: active short wait, parameter: 8-bit delay counter
; cycles: (6) + 2 + 1+n*3 = 9+n*3
//CMD_SWAIT1: active short wait, parameter: 8-bit delay counter
; cycles: (6) + 1 + 1+n*3 = 8+n*3
//CMD_SWAIT: active short wait, parameter: 8-bit delay counter
; cycles: (6) + 0 + 1+n*3 = 7+n*3, 
;(16 MHz: 437.5 ns + n*187.5 ns, min: 625 ns, max: 48.4375 µs) (n=0 -> n=256)
;(20 MHz: 350 ns   + n*150 ns,   min: 500 ns, max: 38.750 µs)  (n=0 -> n=256)
Cmdexe_SWAIT:
     ld    PI_Param,  PI_PC+   ; (2) get delay counter
Cmdexe_SWAITLoop:
     dec   PI_Param            ; (1) counter--
     brne  Cmdexe_SWAITLoop    ; (2) for branch, (1) for loop end
     CMD_PREFETCH              ; (4) Macro: Prefetch next op-code and decode

The SWAIT <counter8> instruction execution time is:
t-cycles = 7+n*3, n= 8-bit counter (n=0 -> n := 256)

As the wait time is proportional to three cpu-cycles, only three SWAIT op-codes are enough (SWAIT, SWAIT1, SWAIT2).

Now it should be possible to achieve exact 50 ns timing resolution with the expense of some minimum delay. But the minimum delay is not critical.

Aziz

[slimabidi]

Hi AZIZ,

indeed, this is really an interesting and fascinating project. The
digital lock-in amplifier is a pure software implementation which is
applied on the input signal (A/D converted receive signal). The lock-
in amplifier is a very sensitive phase detector even the signal is
buried in high noise. Any small changes can be detected with it (µV
measuring). Using a 24 bit sound-card at 96 kHz sample rate increases
the signal-to-noise ratio and dynamic range. It will also work on 16
bit and 44.1/48 kHz with reduced SNR and dynamic range.

It is quite time-critical application. You must not loose the
synchronisation of the transmitted to received signal. The continious
wave form is buffered to the sound-card to avoid signal gaps due to
operating system task switches. But this is easy to handle and only
the DMA is busy and relieves the CPU. Laptop has enough CPU power for
doing this and much more in real-time (FFT, digital filter, lock-in
amp, detection, signal generation, synch generation, graphical
output ..).

The operating frequency for the sensor is between 5 to 24 kHz (VLF
range). It depends only on the resonant frequency of the search head
(L,C resonant defining elements) and sampling rate (fmax=SR/4). The
higher the operating frequency, the better the sensitivity of the
sensor (Faraday's law). So it is mostly defined by the sensor
specification.

The sensors are typically D shaped coils with same inductivity L for
transmit and receive coil. This will allow a simple matching of the
capacitors (same for transmitter and receiver). The coils are in
overlapped co-planar position and forming a circle (two D's). The
receive coil should have a minimum of signal level (10-50 mV rms).
This position must be found by moving one of the coils.

What about digital lock-in amplifier for your application? This would
be a quite useful feature.

Regards,
slim

[slimabidi]

Thinks AZIZ

Interesting and fascinating project

Good Works



Your friend Slim