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

[Aziz]

Hi all,

my first PI op-code program is running in the target board.

 
  CMD_NOP                   ; 0 +1
  CMD_JMP,    0, 4          ; 1 +3
  ; 4: loop:
  CMD_XOR,    $20+PI_Out2, 1<<PI_TX_  ; Toggle Transmit Pulse Signal
  CMD_RETI
  CMD_RETI
  CMD_JMP,    0, 4          ; jmp loop
  CMD_EOF

Aziz

[Aziz]

PI op-code decoding reduced now to 7 cpu clocks!

 
; Timer/Counter2 Output Compare Match interrupt request service routine
ISR_TIM2_COMP:
     out   TCCR2, PI_TCCR2     ; (1) disable timer 2
 
; External INT0 interrupt request service routine
ISR_EXT_INT0:
_next_cmd:
     ; Load command
     ld    ZL, X+              ; (2) get command
 
     ; Jump to command vector
     add   ZL, PI_CmdVec       ; (1)
     ijmp                      ; (2) + (2) for another rjmp in the command vector

[Aziz]

Hi all,

I am making good progress in the coding of the PI op-code processor. It is possible to modifiy all registers, I/O peripherals, data ram ranging in the data address space from 0 to 255. For special accesses like the target platform specific I/O operation within 4 cpu clocks, there will exist double access op-codes. It also makes break-before-set operations within short latency time possible (2-4 cpu clocks).
A lot of bit manipulation op-codes will exist. For time-critical operations, the active wait delays can be used. Timer controlled delays will support all prescaler options (/1, /8, /32, /64, /128, /256, /1024) and will release the cpu for the main thread and other interrupt requests. INT0 and TIM2_OC interrupts will not be nested. All other interrupts will allow nested interrupts. TIM2_OC interrupt can be triggered by the software too. The op-code size length will vary from 1 to 4 byte. Special PI op-codes may use more op-code size.

The internal 1 KByte data SRAM (ATmega16) is divided into following sections at the moment:
FIFO-RX (USART): 16 Bytes
FIFO-TX (USART): 16 Bytes
PI op-code program begins
...
PI op-code program ends
...
...
...current stack pointer (top)
...Stack
Stack bottom
End of data SRAM

There is enough data space for the PI op-code program. The PI op-code program supports an initialize and loop routine, single-cycle control, multi-cycle control (arbitrary number of cycles), one time cycle execution, ...
This novel architecture allows an efficient and flexible hardware and software control.

Aziz

[Aziz]

It seems, that I am going to implement a software mcu in a real mcu. This could be a strange PI detector with micro op-code implementation.

I need this feature at all costs for the most flexible PI design possibility. As I haven't coded the "op-code assembler" yet, I am putting the op-codes via byte records in the mcu's data memory.

I will be able to run my first PI code implementation soon. Then I can test my modules.

Aziz

[Aziz]

Hi all,

some considerations about the synch clock jitter and INT0 response arises. Normally, the synch clock (cycle start trigger) from the sound card output is superior. It is developed for this purpose (high definition audio).

As the INT0 detection response is dependend on the current op-code, some clock cycles might delay the INT0 interrupt response. Particularly multi-cycle cpu op-codes will delay the interrupt request until they were finished. As the firmware code is very simple, max. 2 cpu clock cycles could be happen before interrupt is served. This means on 16 MHz clock speed a time period of max. 2*62.5ns = 125 ns.

So on some timing critical conditions, I might use active delay commands in the interrupt service routine. I will very likely change the ISR routine shown above to make variable length command coding. The parameter fetch will be removed from the command decoding to make single byte op-codes possible (like NOP's).

It is also possible to make a full PI operation op-code. If timing problems occur, then this option must be taken into account.

Take care,
Aziz

[Aziz]

Hello friends,

I will publish some more mcu internals. See below the interrupt request service routines (ISR) for INT0 and Timer 2 Output compare match interrupt. They share almost the same code. Timer interrupt service routine disables the timer 2 when the wait command exceeds the desired delay time.

 
; Timer/Counter2 Output Compare Match interrupt request service routine
ISR_TIM2_COMP:
     out   TCCR2, PI_TCCR2     ; (1) Disable Timer2
 
; External INT0 interrupt request service routine
ISR_EXT_INT0:
_next_cmd:
     ; Load command
     ld    PI_Cmd,    X+       ; (2) get Command
     ld    PI_Param,  X+       ; (2) get Parameter
 
     ; Jump to command vector
     ldi   ZL, low(Cmd_Vector) ; (1)
     add   ZL, PI_Cmd          ; (1)
     ijmp                      ; (2) + (2) for another rjmp in the command vector

As you can see, the interrupt request service routine is kept small to achieve short interrupt latency time. Command decoding takes 10 cpu clock cycles. One clock cycle more is necessary for the timer 2 ISR. To achieve a short interrupt latency, global variables in the register file are used.

What is the exact interrupt latency?
- 4 cpu clock cycles takes the interrupt action.
- +2 cpu clocks takes the rjmp from the interrupt vector to the ISR routine.
- +10 cpu clocks is used for command decoding
- +n variable number of cpu clocks for command execution (normaly very short code).
- +4 cpu clocks takes reti (return from interrupt)

Interrupt latency = 4+2+10 = 16 cpu clocks (on 16 MHz = 1µs) for command execution begin.

Normaly, there will be more successive commands in the list, which reduces the latency time between commands for critical timing actions. 4(int)+2(rjmp)+4(reti) = 10 cpu clocks won't be taken additionaly in this case. Only additional 2(rjmp) cpu clocks will be necessary to jump to the _next_cmd label. After the interrupt vector table, the command vector table starts. This allows quite lots of commands with short jump to the command vector address (ZH is 0, ZL is command vector address).


Aziz

[Aziz]

Hi friends,

I have developed a command language for the PI control logic. The "code" will be compiled in the laptop software and will be transferred to the PI board. The PI board and mcu firmware software won't contain any particular algorithm for the PI operation (PI detector implementation). When there is an issue due to patent pending of methods, the PI implementation could be changed quickly without changing the firmware. It also makes sharing of PI implementation and lots of different search modes possible.

MCU internals:

INT0 will be used as an external interrupt request source for triggering a new cycle operation. The trigger signal comes from the sound card. This interrupt will have the highest priority and will be triggered on rising edge (going from -5V to 0V).

TIMER 2 will be used for delays between PI logic control commands. There is no active delay in the interrupt service routine and the timer will be setup to produce timer compare match interrupts. This interrupt has high priority level over the other peripherals (USART, ..). This makes the design more efficient and releases the cpu to handle the communication interface and other peripherals.

There will be platform independent and target platform dependent commands (mcu I/O commands). The command decoding takes 10 cpu clock cycles at the moment (constant overhead: independent of number of commands). For time critical PI control logic, there will be special commands available. I want to implement roughly 20-30 commands. It will also allow a multi-cycle PI implementation (like different transmit pulse width implementations, alternating transmit pulse polarty implementations, ...) .

Aziz

[Aziz]

Hi miki73,

Aziz can you give us your final pi board schematics?
To better uderstanding your work..

Regards!

I am sorry, but there isn't any final work available yet. This project is only to be understood as an experimental project under development and finally to answer the only one question at the moment:
"Can the 24-bit USB sound-card be used in conjunction with laptop for pulse induction metal detection?". This means, can the 24-bit codec chips be convenient for the PI type detectors. The codec chips were usually built-in in the sound-card.

The former answer for the VLF type is already there: Yes! But I am interested on PI technology and do not follow the VLF type detectors anymore.

There is still huge amont of work to do to get the very very interesting answer to the question above. If the answer is promising much potential, then it would make sense to follow this project. In this case, a new hardware design would be necessary. I hope, I can get the answer and proof of concept next month.
Would I invest several month of effort when I wasn't convinced about the huge potential?

-----------------

BTW, I got my ordered parts today. Damn, I forgot to order some other important parts. The USB <-> serial converter is running. Now this project becomes a fully USB project. Later, the RS232 interface will be replaced by a USB interface (1.5 Mbit low speed USB).


Aziz

[miki73]

Aziz can you give us your final pi board schematics?
To better uderstanding your work..

Regards!

[Aziz]

It seems, that I will have the most flexible PI systems ever made.
The laptop software will control almost everything of the PI board.

The PI control logic will be stored in the data RAM and not in the program memory (it isn't a hard wired firmware software code). This makes the developing of any search modes in the field possible!!! This feature is the most important possibility, that I would need for the case of not handled conditions and ground types (called outback prototyping).

The PI board will be a very very stupid machine. Without the laptop software, it can do nothing. This makes the developing of the prototype very fast (PC development is very comfortable, flexible, easy, cheap and fast). So the PI board will need the laptop and therefore it can not be operated as a stand-alone system.

When there are some more I/O pins available, I will extend the design to make oscilloscope displays of the PI decay curve possible. (Yes, even this could be done very easily!!! The idea is a result of lack of money and means. And of course, you won't have an instrument in the field.).


Aziz

[Aziz]

Hi all,

I have just ordered another bunch of important parts for the project. Also an USB/Seriell converter to make field tests possible. Due to my very low budget, I will buy an used oscilloscope next month on ebay.

Transmitter stage is working. I also have started to develop the firmware code. PORTC and PORTD will be used for controlling the PI board (transmitter pulse, PGA, integrator, S&H..). INT0 is used as a high priority cycle trigger. PORTA will be used for input signals (digital and analog sensor signals). PORTB probably for LCD - don't know yet (the laptop has a much better colour display ).

The firmware code won't know how to control the PI board. So the brain of the PI logic will remain in the laptop and will be downloaded to the mcu. A pure stand-alone system will not be developed.

The very very interesting question might be answered next month probably.

Aziz

[Aziz]

Hi all,

I am recovered from my disease now.

And I had a look into some ATmega data sheets in the mean time. It seems, that the firmware code will be very very simple and efficient (no active delays necessary).
The complete PI control can be handled with short latency in the interrupt service routine. Thanks Atmel for making the data address space easy, flat and possible to access the whole peripherals (including register file). The whole PI control logic can be handled from the laptop and uploaded through the communication interface to the mcu. Therefore no special firmware code in the mcu is necessary. And also no need for firmware updates (flashing).

The main thread of the mcu will do the bi-directional communication controlling. The 16 MHz speed is fast enough to handle everything.

Aziz

Hello Aziz , very good and beautiful work (like and artistic painting or a brightly sculpture), please go to a good dentist because problem with tooth are more serious if they do not cure ...do not wait ... at time is very important
hope you will cure rapidly your pain and relax a few weeks.
Regards and Take care
Alexis.

[simonbaker]

Hi all,

as you can see (below), the hardware overhead is quite big. But it doesn't matter for the experiments I have planned.
Now, the very big part of the project starts: the soul of the detector (firmware, PC software). So I might be offline for a while.

I will continue as soon as I am feeling better (had a relapse of my tooth problem).

Take care,
Aziz

You are very productive Aziz, keep up the good work!

(how do you find time to to so much?)

Cheers,

-SB

[Qiaozhi]

Hi all,

as you can see (below), the hardware overhead is quite big. But it doesn't matter for the experiments I have planned.
Now, the very big part of the project starts: the soul of the detector (firmware, PC software). So I might be offline for a while.

I will continue as soon as I am feeling better (had a relapse of my tooth problem).

Take care,
Aziz

I think you should call this detector "Frankenstein", as it's turning into a monster.
But hopefully it won't try to kill its creator.