Eeprom eines FK105 Betriebsfungerätes mit Arduino Mini ersetzen.

Hallo Zusammen.

Ich versuche grade die PLL schaltung eines Grundig FK105 durch einen mit 16 MHz getakteten Arduino Micro zu ersetzen, aber der Arduino ziert sich
allerdings grade etwas.

Ich hatte mei meinen Funkfreunden hier vor Ort mehrfach die Befürchtung geäußert das der Arduino Micro Pin Change Interrupt für die 750KHz mit denen
der EeProm getaktet ist, zu langsam sein könnte. Da kam dann immer ein "Aaaach das macht der doch mit Links! "

Ich sollte noch besser meinen Instinkten folgen und das vorher nachrechnen. Jedenfalls scheint bei meiner nicht optimierten Interrupt routine und dem
Chinesischen Funktionsgemerator, dessen Funtion bereits unter einer LED zusammenbricht, an meiner nicht störsicheren Testschaltung bei einem KHz
schluss zu sein.

Ein wenig kann ich sicher noch optimieren:
- Sleep Mode deaktivieren
- Die ISR entschlacken.
- ISR_NAKED machen.

Wenn das nicht hilft, kann ich noch:
- Den Arduino umquarzen.
- den PLL Counter auslöten und das auch vom Arduino machen lassen, langsamer halt. Das kompliziert halt den Umbau, falls
ich nicht irgendeine eigenschaft der PLL überlesen habe.

Oder ich nehm halt doch einen EEProm, und kann halt nicht mehr selbst umprogrammieren.

grüße

Hans

Hallo Uwe, Hallo Tom,

@Tom: Ich tu es eh messen, aber es wird trotzdem knapp....

Uwe: Quellcode hier: https://github.com/zem/fk105 ich hab ihn mittlerweile nochmal optimiert seit dem letzten test gestern nacht, ggf musst du dich durch die revisionen klicken. Programmieren tu ich in C. falls ich rausfinden sollte das Assembler da irgendwas bringt, werd ich Assembler einsetzen.

grüße
Hans

Hallo Uwe,

Ich bau nachher mal was anschauungsmaterial zusammen zusammen, kann aber morgen werden, hier ist grade AFU Kurs Kick off.

Ich muss die A N und Vorteilerwerte der PLL mit 3 Bit Adresse und 4 Bit Daten betanken. Die 3 Bit adresse kommt von einem Counter IC
die mit den 750 kHz vorteilertakt betrieben wird. Der PLL IC hat dann noch einen L eingang und ich vermute mal das bei aufsteigender 750000 Hz
flanke die Adressdaten angelegt werden und bei absteigender Flanke die Daten ind das Register der PLL übernommen werden.

Meine Idee war, mich auf das niederwertigste Bit der Adresse zu setzen damit ich jeden Adresswechsel mitbekomme muss ich demnach bei
aufsteigender und absteigernder Flanke die Interruptroutine ausführen.

Ich halte die Looping funktion eh mal offen. Ich könnte zum beispiel den Atmega auch die Adressen durchzählen lassen, dann währe ich
aus dem timing komplett raus.

grüße
Hans

Immernoch zu langsam ich messe jetzt 792 KHz allerdings fürchte ich das ich nochmal doppelt so schnell werde muss.... wenn ich die schaltung richtig lese, wird während der aufsteigenden 750 KHz flanke dder Datenwert angelegt und während der absteigenden Flanke dann eingelesen, ich kann mich aber täuschen....

Vielleicht lerne ich doch nochmal assembler wenn ich mir folgenden code so ansehe:

Zitat

.global __vector_9
.type __vector_9, @function
__vector_9:
/* prologue: naked */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
in r30,0x3 ; D.2226, MEM[(volatile uint8_t *)35B]
lsr r30 ; D.2226
ldi r31,0 ;
subi r30,lo8(-(freq)) ; tmp50,
sbci r31,hi8(-(freq)) ; tmp50,
ld r24,Z ; D.2226, freq
out 0xb,r24 ; MEM[(volatile uint8_t *)43B], D.2226
/* #APP */
; 135 "main.c" 1
reti

Alles anzeigen

Ich zähl da 7 instruktionen vom start der Interruptroutine bis zur zuweisung des Wertes...

Ich hab auch schon über das weglassen der ISR nachgedacht. Soweit nach meiner Recnung muss die Schleife muss unter 10,6 Takten länge bleiben, sonst ist der controller zu lahm. In meiner ISR Routine zähle ich 7 Assembler Anweisungen, in deiner Schleifenlösung zähle ich schon 13 assembler anweisungen, zu je n>=1 takten, das passt nicht.

Die ISR verbraucht laut internet 4 Takte + einem Jump zur ISR funktion selbst mit nochmal 3 Takten. dagegen braucht der C code mit 7 instruktionen ca 13 Takte. Das weglassen der ISR wird es also erst rausreißen wenn ich meinen C code mit den derzeit 7 Instruktionen nochmal 3 Takte schneller gemacht habe. .

Die Überlegung mit der ISR ist auch, das ich so besser messen kann. Ohne ISR weis ich nie genau wie asyncron mein Controller grade gegenüber meinen Adressen ist, das ist derzeit ein rückschritt. Wenn ich mir den Assembler Code so anschaue würde ich mal behaupten das die verzögerung die C da verursacht größer ist als die der ISM.

Ich behalte das noch im Hinterkopf als optimierung wenn mir am schluss noch die genannte anzahl takte fehlen aber an assembler fürhrt hier kein Weg vorbei. Ich muss feststellen: C ist zu langsam dafür.

Die Idee mit dem SRAM Baustein ist gut, aber ein freund hat mich auf eine noch bessere Idee gebracht. Es gibt da ein FPGA Board in der größe mit einem USB stecker dran. Das ist in jedem Fall schnell genug.

Ich mach aber erstmal weiter mit dem muC der ist jetzt da.

grüße
Hans