Hallo,
seit erst kurzem beschäftige ich mich auch mit dem Padauk PFS154
Controller (Tim / CPLDCPU sei dank), nicht weil der so toll ist, sondern
weil der aufgrund seines Preises ( < 10 Cent) irgendwie reizvoll ist.
Im Moment arbeite ich mich da etwas ein, im speziellen dem 16-Bit Timer.
Sollte ich hier dämliche Fragen stellen: bitte um Verzeihung, mit dem
Chip bin ich noch nicht so vertraut wie ich das mit anderen Controllern
bin.
Verwendeter Compiler ist ein Snapshot vom SDCC, Version 4.0.3 #11879
Wäre super nett, wenn sich gerade Philipp Klaus K. und CPLDCPU für
diesen Thread hier angesprochen fühlen würden.
Mein Anliegen ist/war es, den Timer16 nicht nur als Overflow-Timer
laufen zu lassen, der je nachdem welches Bit des internen Zählregisters
mit dem Interruptrequests sozusagen unterschiedliche Overflowgrenzen
hat. Hiermit können in Verbindung mit dem Taktvorteiler schon viele
Timingsachen eingestellt werden. Um genauere Timings vornehmen zu können
wollte ich einen Reloadtimer realisieren, also Blick ins Datenblatt.
Das sagt, dass es KEINE Adresse für das Zählregister des 16-Bit Timers
gibt, weil es scheinbar (korrigiert mich wenn ich falsch liege) das
einzige 16-Bit Register dieses Controllers ist.
Aus diesem Grunde dürfte es wohl so sein, dass nachfolgender Code
übersetzt wird und __sfr16 ohne weitere Angaben einer Adresse verwendet
werden kann:
CLKMD = CLKMD_IHRC_DIV2 | CLKMD_ENABLE_IHRC; // 8 Mhz main clock
19
return 0;
20
}
Obiger Code kann übersetzt werden, aber leider macht der Compiler für:
my_t16= 0x12;
das folgende daraus:
1
; reg16_test.c: 23: my_t16= 0x12;
2
mov a, #0x12
3
mov p, a
4
stt16 p
Wie man hier dann deutlich sieht, weist er dem 16-Bitregister nur ein
Bytewert zu, versucht man diesem Register mit einem 16-Bit Wert zu
beschreiben (entweder mit Cast oder mittels einem Wert > 255):
my_t16= 0x1234;
produziert der Compiler einen Fehler:
1
reg16_test.c:25: error 9: FATAL Compiler Internal Error in file '/home/sdcc-builder/build/sdcc-build/orig/sdcc/src/pdk/gen.c' line number '1070' : Unimplemented __sfr16 store
2
Contact Author with source code
Für mich heißt das, dass der 16-Bit Zugriff auf das Timer16 Register
nicht vorhanden ist, oder?
Heißt das dann, dass das (momentan) schlicht nicht geht oder mache ich
etwas falsch.
Für den Moment habe ich mir folgendermaßen beholfen:
[code]
volatile uint16_t reload;
...
reload= 0x1234;
// Reloadwert des 16-Bit Timers setzen
__asm
mov a,_reload+0
mov __t16c+0,a
mov a,_reload+1
mov __t16c+1,a
stt16 __t16c
__endasm;
----------------------------------------------------------------
Die Frage jetzt: geht das momentan anderst als den Weg über
Maschinensprache
innerhalb von C ?
Netten Gruß, Ralph (vor allem an CPLDCPU und Philipp Klaus)
Auf das Timer-Register kannst Du nicht über normale Befehle zugreifen,
das geht nur über ldt16 und stt16.
Die wollten ihre Architektur extrem schlank halten und keine generischen
16-Bit-Befehle oder ähnliches implementieren und haben daher für die
Timer eine Extrawurst gebraten.
Du kannst also mit ldt16 und stt16 nur jeweils auf ein Word im RAM
schreiben bzw. lesen.
Ich vermute mal für diese Sonderlocke ist in SDCC noch keine bequeme
Behandlung enthalten, Du wirst also über Assembler gehen müssen.
sfr16 war schon immer etwas gefährlich. Beim SDCC kann man immerhin
durch Wahl der Parameter beeinflussen wo die Register liegen. Aber alle
Compiler haben halt das Problem dass nicht garantiert ist in welcher
Reihenfolge die 8Bit Teile geschrieben werden.
Die Fehlermeldung deutet an dass der Codegenerator für Padauk noch kein
sfr16 beherrscht.
Dein asm Code zeigt dass die Teile einen spez 16bit Schreibbefehl
beherrschen. Das gibt's z.b beim x51 Target nicht. Dort macht sfr16 in
etwa das was dein Inline Code tut.
Mal schauen was Philip dazu sagt.
Thomas Z. schrieb:> sfr16 war schon immer etwas gefährlich. Beim SDCC kann man immerhin> durch Wahl der Parameter beeinflussen wo die Register liegen.
Ich würde ja auch gerne mit 2 mal 8 Bit __sfr Zugriffen das 16-Bit
Register beschreiben, einzig es gibt einfach keine Adresse für dieses
Register im Chip.
Gerd E. schrieb:> und haben daher für die> Timer eine Extrawurst gebraten.
Das sehe ich genau so.
Gerd E. schrieb:> Du kannst also mit ldt16 und stt16 nur jeweils auf ein Word im RAM> schreiben bzw. lesen.
stt16 kann einzig und ein alleine ein Word aus dem Speicher in das
Timerregister schreiben (was hier dann heißt, dass das Register eben
nicht über eine Adresse ansprechbar ist), gleiches gilt in umgekehrter
Richtung zum Lesen aus dem Timerregister in ein Word im Ram.
Thomas Z. schrieb:> Mal schauen was Philip dazu sagt.
bin ich auch gespannt !
Ralph S. schrieb:> stt16 kann einzig und ein alleine ein Word aus dem Speicher in das> Timerregister schreiben
Dann kann sfr16 nicht funktionieren da die die Parameter für sfr16
einfach zwei 8bit Konstanten sind die zu einem 16 Bit wert vereint sind.
Eine Speicheradresse müsste ja der Linker einsetzen.
Tim . schrieb:> Es gibt zu dem Thema hier schon einen Bug-Report, wenn ich mich nicht> irre:
Danke fuer die Info, smile: bin ich gespannt ob das "repariert" wird.
Ich hab großen Respekt vor der Motivation des SDCC Teams wie sie den
Compiler für den Padauk angegangen sind. Ich hab noch einmal den
kompletten Thread gelesen gehabt. Von der Vorstellung als du den Chip
zum ersten mal zur Sprache gebracht hast bis zu dem Punkt, an dem der
Compiler funktionierte !
Geniale Leistung von allen daran beteiligten
Man muss fairerweise sagen, dass die meiste Arbeit im EEV-Forum ablief.
Der Thread ist etwas länger:
https://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering/
JS, der den EasyPDKProg entwickelt hat, ist auch dort unterwegs. (Meine
Lite Version ist eine Vereinfachung seines Programmers).
Es haben Viele etwas beigetragen. Interessanterweise gibt es inzwischen
wohl mehr Programmer als Projekte mit dem Padauks :)
Tim . schrieb:> Man muss fairerweise sagen, dass die meiste Arbeit im EEV-Forum ablief.
Das mag wohl sein, aber den SDCC zu programmieren dass er PDK kann...
hat wohl schon das SDCC-Team gemacht.
Tim . schrieb:> Es haben Viele etwas beigetragen. Interessanterweise gibt es inzwischen> wohl mehr Programmer als Projekte mit dem Padauks :)
Na ja, es ist auf Free-PDK wieder ein neuer Programer aufgetaucht, der
auch auf dem aus dem EEV Blog basiert. Ich selbst habe mir jetzt auch
eine Platine geroutet und warte darauf, dass die aus China eintreffen.
Mir gefällt weder die Micro-USB Buchse, noch die USB-A... ersterer
übelst zu löten und zweite ist zu wuchtig. Ich hab gerne USB-Mini.
Im Moment verwende ich einen großen Steckbrettaufbau (der STM32 ist auf
einem Adapter verlötet), aber so wirklich begeistert bin ich da auch
noch nicht davon, vor allem weil er einen F072 verwendet, den man nicht
wirklich preisgünstig bekommt.
Mir schwebt da etwas in F103 mit CH340 Bridge vor (um keine CDC im F103
verwenden zu müssen). Schaun wir mal.
Zudem bastel ich an einer TUI-Konsolen IDE für den PDK und einem
Framework (und alles gleichzeitig).
Um mit dem PDK etwas anstellen zu können (er ist schon wirklich extrem
spartanisch) bin ich für mich dabei, erst einmal (für mich) wichtige
essentielle Dinge zum Laufen zu bekommen.
Per Bitbanging geht schon mal eine serielle Schnittstell, vor allen
Dingen hier auch ein "char getchar()" und mein abgespecktes Mini-printf
geht auch. Seit heute geht ebenfalls I2C per Bitbanging.
Im Moment funktioniert mein Timer16 mit Reloadfunktion, so dass ich
(Rechteck)frequenzen entsprechend für 2 Oktaven der C-Dur Tonleiter
generieren kan.
Hier wird dann ein "YetAnotherMelodyPlayer" gemacht werden, der einen
Notenstring abspielen kann (wie diese Glückwunschdudelkarten...
monophone allerdings).
Auf der nächsten Liste der zu erledigenden Dinge steht dann das
Charlieplexing an und dann kümmere ich mich um den Komparator.
Hier mag ich dann, ähnlich wie in einer uralten Appnote von Atmel für
den Tiny2313 eine einfache (und relativ ungenaue) AD-Wandlung vornehmen.
Damit müßte dann so etwas wie das VU-Meter (in Verbindung mit dem
Charlieplexing) realisierbar sein, wie das hier jemand für einen
ATtiny13 vorgestellt hat.
Nachdem du mir die Quelle www.lcsc.com genannt hast, hab ich da mal die
dort erhältlichen PFS154 und PFS172 im 16 poligen Gehäuse bestellt und
weil ich den 3 Euro Bonsu fürs erstbestellen haben wollte auch noch den
UKW-Radio Chip RDA5807 im 8 pol. Gehäuse (den hatte ich bisher nirgendwo
gesehen).
Daraus mag ich dann mal versuchen, ob die 2 kWord reichen, um mit dem
Padauk dann ein UKW-Radio gemacht werden kann.
Für einen ATTiny44 habe ich so etwas gemacht, mit 20 LED per
Charlieplexing (benötigt 5 I/O) als Anzeige, 4 Tasten und eben 2
Leitungen fürs I2C. Macht zusammen 11 I/O Leitungen und der PFS hat 14.
Stellt sich mir die Frage, ob der Speicherplatz reichen wird. Leider
wird man hier auch nicht den zuletzt benutzten Sender und die genutzte
Lautstärke beim Wiedereinschalten herstellen können, weil der PDK kein
internes EEPROM hat, leider!
Aber als erstes größeres Projekt werde ich also dieses UKW-Radio
angehen. Zwischendurch das alte "Simon sagt" Spiel (von dem ich annehme
dass es einfach ist, wobei ich denke dass hier aufgrund des Ram-Mangels
nicht mehr als 40 bis 50 Wiederholungen machbar sein werden).
Als zweites großes Projekt werde ich versuchen, aus dem PDK ein
I2C-Slave zu machen, der dann seinerseits irgendwelche Gerätschaften
ansteuert (vllt. ein einfaches Textdisplay).
Ideen habe ich genug.... nur nicht genug Zeit.
Die Frage ist, ob das alles Sinn macht, weil ich schlicht glaube, dass
die Verbreitung, zumindest bei den Bastlern, nicht sehr groß werden
wird, weil man auf die Schnelle nicht so wirklich gut an einen
Programmer und an die Chips herankommt. Schade eigentlich
Ralph S. schrieb:> Tim . schrieb:>> Man muss fairerweise sagen, dass die meiste Arbeit im EEV-Forum ablief.>> Das mag wohl sein, aber den SDCC zu programmieren dass er PDK kann...> hat wohl schon das SDCC-Team gemacht.
Das SDCC-Team (Philipp + Mitstreiter) ist in beiden Foren unterwegs.
Wollte nur darauf hinweisen, das Vieles außerhalb von µC.net passiert
ist.
Ralph S. schrieb:> Im Moment verwende ich einen großen Steckbrettaufbau (der STM32 ist auf> einem Adapter verlötet), aber so wirklich begeistert bin ich da auch> noch nicht davon, vor allem weil er einen F072 verwendet, den man nicht> wirklich preisgünstig bekommt.>> Mir schwebt da etwas in F103 mit CH340 Bridge vor (um keine CDC im F103> verwenden zu müssen). Schaun wir mal.
Ja, ein Port der Firmware auf einen F103 wäre nicht schlecht. Der F072
hat zwei Vorteile:
1) DAC-Ausgang. Der kann aber wahrscheinlich durch einen PWM ersetzt
werden, wenn man am Opamp noch einen Filter ergänzt.
2) Er hat einen intergrierten USB Bootloader. Den F103 kann man leider
nur mit entsprechendem Equipment programmieren.
Einen F103 zu nutzen wäre trotzdem zu bevorzugen, da er auf jlcpcb als
standard-Bauteil verfügbar ist. Der F072 ist häufig nicht lieferbar.
Eine CH340 bridge würde allerdings deutlich komplexität erzeugen. Da
wäre die Nutzung der USB-Peripherie im F103 einfacher.
Ralph S. schrieb:> Als zweites großes Projekt werde ich versuchen, aus dem PDK ein> I2C-Slave zu machen, der dann seinerseits irgendwelche Gerätschaften> ansteuert (vllt. ein einfaches Textdisplay).
Dafür wäre der PFC232 ideal, der timeslicing mit zwei virtuallen Cores
unterstützt. Leider ist er noch nicht zu bekommen.
Ralph S. schrieb:> Stellt sich mir die Frage, ob der Speicherplatz reichen wird. Leider> wird man hier auch nicht den zuletzt benutzten Sender und die genutzte> Lautstärke beim Wiedereinschalten herstellen können, weil der PDK kein> internes EEPROM hat, leider!
Die µC mit internem EEPROM haben ein G als zweiten Buchstaben in der
Bezeichnung. Aber anscheinend haben sich die angekündigten PGC433 und
PGC434 etwas verzögert, obwohl sie schon im Katalog von Anfang 2019 als
"under development" stehen.
Thomas Z. schrieb:> Ralph S. schrieb:>> stt16 kann einzig und ein alleine ein Word aus dem Speicher in das>> Timerregister schreiben>> Dann kann sfr16 nicht funktionieren da die die Parameter für sfr16> einfach zwei 8bit Konstanten sind die zu einem 16 Bit wert vereint sind.> Eine Speicheradresse müsste ja der Linker einsetzen.
Die Padauk backends sollten einen Schreibzugriff auf __sfr16 als stt16
kompilieren. Die bisherige Implementierung funktioniert allerdings nur,
wenn der geschriebene Wert < 256 ist (für andere Werte gibt es
stattdessen die Fehlermeldung "Unimplemented __sfr16 store").
Tim . schrieb:> Ralph S. schrieb:>> Als zweites großes Projekt werde ich versuchen, aus dem PDK ein>> I2C-Slave zu machen, der dann seinerseits irgendwelche Gerätschaften>> ansteuert (vllt. ein einfaches Textdisplay).>> Dafür wäre der PFC232 ideal, der timeslicing mit zwei virtuallen Cores> unterstützt. Leider ist er noch nicht zu bekommen.
Immerhin existieren schon welche. Allerdings werden sie noch nicht von
SDCC unterstützt (man könnte höchstens einen der Cores in SDCC
programmieren, den anderen dann in Assembler). Und auch noch nicht vom
easy-pdk-programmer.
Thread beobachten
Seitenaufteilung abschalten