Versuche mit dem HT66F30
Der
Holtek HT66F30 hat einige interessante Eigenschaften, darunter mehr
Ports, einen kalibrierten internen Taktgenerator, einen
12-Bit-AD-Wandler und erweiterte Timer. Zwar ist der Flashbereich nur
so groß wie beim HT46F47 und das EEPROM mit 64 Byte sogar nur halb so
groß. Aber die Familie kennt auch noch den HT66F40 und den
HT66F50 mit jeweils verdoppeltem Speicher und noch mehr Anschlüssen.
Reizvoll ist auch, dass ich den schon bekannten Compiler und die
vorhandenen Brenner verwenden kann.
Für die ersten Versuche
habe ich den HT66F30 auf eine Platine gelötet, die eigentlich für ein
kleines Spiel mit dem HT46F47 gedacht war. Der neue Controller hat 24
Beinchen gegen den 18 Anschlüssen des Vorgängers. Einige der
Anschlüssen hängen daher in der Luft. GND, VCC und Reset müssen mit
Drähtchen verbunden werden. Aber viele der Ports liegen passend für die
auf der Platinen vorhandenen Positionen für LEDs und
Tastschalter. Zusätzlich habe ich den Anschluss zum Brenner
eingebaut.
Den
Compiler HT-IDE3000 verwende ich schon lange. Nun war ein Update
fällig, damit auch der HT66F30 explizit unterstützt wird. Das erste
Testprogramm sollte nur irgendwie auf den Port A zugreifen. Es konnte
problemlos kompiliert und in den Controller gebrannt werden. Aber die
acht Pins am Port A blieben hochohmig.
Im
nächsten Schritt habe ich auch den Port B getestet. Das hat problemlos
funktioniert, an den Ausgängen erschienen die gewünschten Ausgaben. Ein
Blick auf die Pin-Funktionen zeigt, dass alle PA-Pins auch Eingänge für
den AD-Wandler sind. In dem 300 Seiten dicken PDF-Handbuch des
Controllers habe ich dann im Kapitel zum AD-Wandler gefunden, dass der
Port A voreingestellt als Eingang für den Wandler dient, wobei die
I/O-Funktionen abgeschaltet sind. Mit _acerl = 0; wurde der Port frei
geschaltet. Allerdings sind nun immer noch drei Leitungen ohne
Ausgabe. Ich muss also noch weiter auf die Suche gegen, welche
interne Baugruppe sich die Ports greift.
#include "HT66F30.h"
void main(){
unsigned char i, j, idx;
_pbc = 0;
_pb = 85;
_acerl = 0; //Port a kein AD-Input sondern Port
_cp1c =0; // Conparator frei geben
_pac = 0; //set port A to output port
_pa = 85; //zero port A (all light on)
// _papu = 255; //pullup
while(1) {
_pb = 85;
_pa = 85;
_delay(1000);
_pb = 170;
_pa = 170;
_delay(1000);
}
}
Das
Programm soll Rechtecksignale an allen Pins an PA und PB erzeugen. Das
bietet die Möglichkeit, einen Blick auf die Genauigkeit des internen
RC-Oszillators mit 8 MHz zu werfen. Das Handbuch sagt, er hat eine
Genauigkeit von 2% bei 5 V und 25 Grad C. Bei 5 V messe ich eine
Ausgangsfrequenz von 995 Hz. Bei 3 V steigt die Frequenz auf 1026 Hz,
also 3 % mehr. Die Spannung ist also tatsächlich wichtig, wenn es auf
die Genauigkeit ankommt. Unter den möglichen Optionen gibt es auch die
Frequenzen 4 MHz und 12 MHz.
Zum
Schluss: Heureka, ich habe doch noch gefunden, was mir drei Port-A-Pins
geklaut hat: Es gibt zwei Komparatoren, und es war der Komparator 0.
Eine Zeile mehr, und alle acht Bits stehen für I/O-Aktionen zur
Verfügung:
_cp0c =0; // Conparator 0 frei geben
_cp1c =0; // Conparator 1 frei geben
