Hallo Leute,
möchte euch das Layout für ein MCS51-Experimentierboard überlassen. Es
ist einseitig und damit auch für einfache Herstellung für Bastler
geeignet.
Das Handbuch zum Board ist unter:
Beitrag "Re: 8051 - Programm und Daten in einem 128kB Chip ohne Overlap" zu
finden. Dort befindet sich der Schaltplan zur Platine, eigentlich zum
Vorläufer, aber die Unterschiede sind minimal. Die Beschreibung der
Platine findet sich im Handbuch.
Die Schaltung verwendet einen MCS51-Kontroller im 40poligen DIL Gehäuse
z.B: 89S52. Auf der Platine befindet sich ein RAM-Baustein mit 32kByte
Größe in von Neumann Architektur (gemischter Programm/Datenspeicher) im
Adressbereich 8000h bis FFFFh.
Der zweite Speicher ist als 32kByte EPROM (27C256) als Programmspeicher
in Harvard Architektur im Adressbereich 0000h bis 7FFFh vorgesehen.
Dieser Baustein ist für das Programm der Platine vorgesehen.
Mit ein wenig Änderungen läßt sich das EPROM durch ein zweites RAM
ersetzen und als Kontroller einer mit programmierbaren internen
Programmspeicher verwenden. Dadurch kann beispielsweise das MCS51-Basic
in den Kontroller Programmiert sein und die Platine für Basic mit
64kByte RAM Verwendung finden.
Natürlich kann auch ein normales Programm in den Baustein oder das EPROM
programmiert werden.
Werde mir die Änderungen für Basic51 ansehen und anschließend hier
mitteilen.
Gruß. Tom
Nachtrag
Übrigens, hier ist ein Bootloader für die Platine zu finden:
Beitrag "Re: 8051 - Programm und Daten in einem 128kB Chip ohne Overlap"
Damit ist es möglich Programme ins RAM der Platine zu übertragen und
dort auszuführen. Dazu ist KEIN Programmiergerät nötig. Das Programm
wird auf dem PC erstellt und über eine RS232-Schnittstelle übertragen.
Wie das genau funktioniert steht auch im Handbuch.
Und nicht über die zwei Quarze im Layout wundern. Es wird entweder der
Eine (SMD), oder der Andere (THT) bestückt. Nicht beide gleichzeitig.
Gruß. Tom
TomA schrieb:> Mit ein wenig Änderungen läßt sich das EPROM durch ein zweites RAM> ersetzen und als Kontroller einer mit programmierbaren internen> Programmspeicher verwenden.
Und warum nicht gleich einen Flash?
Der RAM braucht doch noch ne Stützbatterie.
Hallo Peter,
Es spricht, ausser dem Aufwand, nichts gegen ein Flash, bei Gelegenheit
kann ich die benötigten Routinen in den Bootloader übernehmen.Ich habe
hier noch ein paar 28256 herumliegen, so fänden die auch noch Verwendung
Im Moment beschäftige ich mich ohnehin mit dem Bootloader, der zickt bei
der Übertragung einer Intel-Hex Datei. Die Übertragung läuft meist
fehlerhaft, falls es doch mal klappt startet er das Programm nicht. Habe
wohl etwas zuviel gekürzt, oder Windows funkt zu oft dazwischen?
Am Wochenende bleibt mir etwas Zeit, dann kümmere ich mich darum und
kann auch gleich nach Flash/EEPROM sehen. Für Basic macht Flash auf
jeden Fall Sinn. Ich verwende die Platine nicht für Steuerungen, sondern
um mal schnell neue Hardware anzuschließen, oder schnell mal eine
Programmidee auszuprobieren. Da ist gepuffertes RAM völlig ausreichend.
Zum Programmieren benutze ich µVision von Keil, da kann ich innerhalb
der IDE die Programme runterladen und mit dem ISD51 direkt die Hardware
debuggen, funktioniert alles recht einfach und komfortabel. Bei
Interesse kann ich hier auch zeigen wie das funktioniert. Auch die 2K
Grenze der Demoversion sind nur ein kleines Problem. Wenn eine Routine
funktioniert wird sie im Bootloader/RAM/Flash abgelegt und entzieht sich
so der Restriction. Dadurch gilt die Größenbeschränkung nur für die
MAIN-Funktion.
Habe gestern die Stromaufnahme aus der Batterie überprüft, sie liegt für
ein RAM bei 0,3µA. Dürfte bei zwei RAM's dann bei ca. 0,6 µA sein. Das
hängt aber auch von den verwendeten Bausteinen ab.
Gruß. Tom
So, jetzt arbeitet der Bootloader richtig.
Er kann in ein EPROM/EEPROM/Flash programmiert werden, dann muß der Pin
/EA (Pin 31) auf Lowpegel liegen, für Zugriff auf externen Speicher. Auf
der Platine ist dafür eine Lötbrücke vorgesehen.
Wird der Bootloader in den Microcontroller programmiert, bleibt die
Lötbrücke offen und /EA liegt über einen 10k Widerstand auf Highpegel.
Gruß. Tom
Und jetzt noch ein kleines Testprogramm zum Downloaden. Einfach die
Hex-Datei "Test.hex" über eine RS232 (48,n,8,1) zur IS51 übertragen.
Wenn es funktioniert hat, schaltet der Port 1 seinen Zustand alle 500ms
um. Das kann mit einem Voltmeter oder einer LED mit Vorwiderstand
überprüft werden.
Das Testprogramm ist für Keil µVision geschrieben, die Quellen liegen
bei. "Test.c" ist der Quellcode, "IS51CBL.H" macht die Eigenheiten der
IS51 zugänglich, "SUIS51BL.ASM" ist die Startupdatei für die richtigen
Einstellungen des Programms für ein Autostart-Programm. Diese drei
Dateien gehören zum µVision-Projekt.
Die Datei "Simulate.ini" wird dem Softwaredebugger übergeben, damit er
mit der Speicherbelegung der IS51 zurecht kommt.
Im Grunde braucht die IS51 einfach nur Maschinencode für Adresse 8000h,
mit einer Autostartkennung, im Intel-Hex Format. Ob diese Datei von
einem Compiler oder Assembler stammt ist der IS51 egal. Ist im Handbuch
genauer Beschrieben.
Gruß. Tom
Hallo Leute,
ein hab ich noch.
Das Basic ist jetzt an die Platine angepaßt. Es ist die Version 1.32 des
Interpreters. Habe die Baudrate fest auf 9600 eingestellt und ein paar
kleine Prögramme ausprobiert, klappt einwandfrei. Ob wirklich alles
richtig funktioniert, weiß ich nicht?
Zum Beispiel meldet das Basic eine falsche Quarzfrequenz. Das Kommando
"PRINT XTAL" liefert 11059200 anstatt des verbauten 12000000MHz Quarz.
Damit das Basic im Adressraum 0000h bis 7FFFh RAM findet sind ein paar
Änderungen der Hardware nötig:
Das EPROM 27C256 durch ein RAM 62256 o.ä. tauschen
Pin 27 vom EPROMsockel trennen und mit Pin 27 vom RAM verbinden.
Pin 22 vom EPROMsockel trennen und mit Pin 22 vom RAM verbinden.
Pin 1 vom EPROMsockel trennen und mit Pin 1 vom RAM verbinden.
Pin 28 vom EPROMsockel mit +5V verbinden.
Man sieht die Unterschiede der beiden Bausteine im Schaltplan der
Platine recht gut.
Das neue RAM muß nicht mit der Batterie verbunden sein, da es durch das
Basic, bei jedem Neustart, gelöscht wird. Als µC verwende ich einen
ATMEL 89S52.
Im Anhang das Handbuch, die Assembler Quelldatei und das Hexfile des
Basic.
Gruß Tom
Aus Versehen habe ich den Quellcode einer falschen Version für
USB-Schnittstelle angefügt.
Hier der Quellcode für die aktuelle 9600er UART Version.
Diese Version ist für eine schnelle Zeichenfolge vom UART ausgelegt. Die
Zeichen werden nicht sofort einzeln bearbeitet, sondern erst mal im
Zeichenpuffer abgelegt und danach ausgewertet.
Die Datei IS51Basic.ASM ist die falsche Version, die Datei IS52Basic.a51
ist die richtige Version für die umgebaute IS51-Platine!
Sorry. Tom
Da fällt mir noch etwas ein. Der Umbau der IS51-Platine für Basic geht
auch einfacher, wenn man keine 64k-RAM braucht. Einfach die beiden CS
Signale von EPROM und RAM tauschen. Dann liegt das RAM im Adressraum
0000h - 07FFFh und das EPROM ist von 8000h - FFFFh aktiv.
Gruß. Tom
Hier ist die umgebaute Platine mit dem PCverbunden und wird über "hterm"
angesprochen. Die für die Übertragung nötigen Einstellungen können dem
Bild entnommen werden.
Auf die Anforderung die Menge freien Speicher zu zeigen "print free",
antwortet das Basic mit "32254".
Gruß. Tom
TomA schrieb:> Zum Beispiel meldet das Basic eine falsche Quarzfrequenz. Das Kommando> "PRINT XTAL" liefert 11059200 anstatt des verbauten 12000000MHz Quarz.
Du kannst entweder mit XTAL <Frequenz> die richtige Quarzfrequenz
angeben oder sie gleich im Assemblerfile an deine Verhältnisse anpassen.
Die Defaulteinstellung findet sich unter dem Label XTALV in Zeile 5813
des Original Listings:
@Matthias: Vielen Dank für den Hinweis, das werde ich machen :)
@All: Das geänderte Basic für IS51 wartet beim Start nicht auf den Code
20h um die Baudrate zu ermitteln. Nachdem es mit einer festen
Einstellung arbeitet startet es sofort.
Gruß. Tom
Peter S. schrieb:> Jetzt bräuchte es nur noch eine
n Sinn und Zweck für das Ganze???
Das 8051 Ding von Atmel hat doch ISP. Wofür der Aufriss mit dem Board?
Hallo Nixversteher,
ISP ist eine feine Sache, hat aber auch Nachteile. Für ISP braucht man
ein Programmiergerät und mit jedem Schreib/Löschzugriff verkürzt sich
die Lebensdauer des Flashspeichers. Zudem ist die Programmierdauer der
Zellen um ein vielfaches langsamer als bei RAM. Bei einer
Übertragungsrate von 4800Baud macht das noch keinen Unterschied, bei
hohen Datenraten schon.
Das ganze Projekt stammt aus einer Zeit, da gab es noch kein ISP oder
ähnliches. Da mußte der µC oder ein EPROM noch aus der Schaltung
entnommen und in einem separaten Programmiergerät beschrieben und wieder
in die Schaltung zurück gesetzt werden. Ein EPROM-Simulator war schon
purer Luxus und entsprechen teuer.
Mit neueren Bausteinen und einer hohen Übertragungsrate ist der
Programmdownload in ein RAM auch heute noch interessant für ein Lern-
und Experimentiersystem, in dem es zu vielen Programmdownloads kommt.
Ein modernes System wie
Beitrag "Re: 8051 - Programm und Daten in einem 128kB Chip ohne Overlap" kann
über USB 1.1 mit hoher Datenrate arbeiten und dazu auch gleich die
Versorgungsspannung der Schaltung und das Hardwaredebugging über die
Schnittstelle erhalten.
Ein Arbeitssystem welches einmal programmiert wird und dann seine
Aufgabe erfüllt, wird besser über ISP beschrieben.
Am besten, man überläßt dem Anwender die Wahl des für ihn geeigneten
Werkzeugs.
Gruß. Tom
Hier noch ein Link zum debuggen mit ISD51 von Keil. Ist zwar für eine
IS51-Version mit USB-CDC Schnittstelle. Funktioniert aber mit RS232
genauso, da ISD51 für RS232 entwickelt wurde.
Beitrag "Keil ISD51-Debugger über VUSB"
Gruß. Tom
TomA schrieb:> Das ganze Projekt stammt aus einer Zeit, da gab es noch kein ISP oder> ähnliches.
Die Zeit kenne ich auch noch, aber das war einmal. :->
Also doch sinnfrei und zum Zeitvertreib.
Hallo Leute,
habe mir jetzt das EEPROM (28C256) vorgenommen, mit Basic funktionierte
es auf Anhieb. Die benötigten Routinen sind bereits vorhanden und man
kann sofort Programme speichern und wieder zurücklesen. Wie des geht,
steht im Handbuch des Basic auf Seite 23.
Zu beachten ist nur, das EEPROM nicht aus der Batterie zu versorgen
(Jumper umstecken), sonst ist diese zu schnell leer.
Mit dem Bootloader funktioniert es noch nicht, da die Zeichen über RS232
zu schnell kommen. Der 28C256 braucht ~10ms zum programmieren einer
Zelle, da versäumt der Bootloader einige Zeichen der SIO. Also entweder
langsamer senden, oder die Zeichen im RAM zwischenspeichern und danach
Blockweise ins EEPROM schreiben. Mit größeren Zeitabständen zwischen den
Zeichen zu senden ist die einfacher zu realisierende Variante.
Gruß. Tom
Nixversteher schrieb:> Also doch sinnfrei und zum Zeitvertreib.
Nicht unbedingt. Mein SPS Projekt basierend auf dem Intel Basic
ermöglicht es eben, die SPS zu benutzen und interaktiv zu programmieren
- etwas, das mit der Original Software von Kloeckner Moeller nie möglich
war, abgesehen davon, das diese Software nur unter MSDOS und evtl. Win95
lief, nicht mehr erhältlich ist, und ausserdem eine Syntax zum 'auf die
Bäume gehen' hatte.
Nun habe ich ein robustes Industrieteil, das bequem zu programmieren ist
und das mit jedem Terminal angesprochen werden kann, ohne das man den
Support einer nicht mehr vorhandenen Firma benötigt.
Von welcher SPS kann man das schon behaupten?
Matthias S. schrieb:> Nicht unbedingt. Mein SPS Projekt basierend auf dem Intel Basic> ermöglicht es eben, die SPS zu benutzen und interaktiv zu programmieren
Das INTEL-Basic ha6t den Vorteil, jetzt quelloffen zu sein. Außerdem
lassen sich individuelle Basic-Befehle per Assembler sehr leicht
"nachrüsten".
Es ist nicht nur das Basic. Die meisten Bausteine aus MCS51 haben die
Möglichkeit einen externen Programmspeicher anzuschließen, wodurch sie
für schnellen Programmdownload geeignet sind. Die Speicherzeit des
EEPROM sind 10ms, beim RAM ist das 0,2µs - dazwischen liegt der Faktor
50000.
Der Verlust von zwei E/A-Ports ist durch Memorymapped-I/O schnell mehr
als ausgeglichen. Habe ein gefädeltes Board hier, mit 16
Erwieiterungsports zu je 8 Bit. Die Zugriffszeit zu den Ports ist die
einer Speicherzelle. Wäre eigentlich Interessant diese Ports auch in
Basic zugänglich zu machen!
@petersieg: Ich werde noch versuchen das Board auf Halb-Europaformat
(100mm x 80mm) zu verkleinern, damit es mit der Demoversion von Eagle
bearbeitet werden kann. Das kann allerdings dauern.
TomA schrieb:> @petersieg: Ich werde noch versuchen das Board auf Halb-Europaformat> (100mm x 80mm) zu verkleinern, damit es mit der Demoversion von Eagle> bearbeitet werden kann. Das kann allerdings dauern.
Hey. Das wäre ja Super!!
Wäre dann eine wirklich schöne, runde Sache um etwas im Bereich 8052
Basic SBC zu machen..
Peter
TomA schrieb:> Wäre eigentlich Interessant diese Ports auch in> Basic zugänglich zu machen!
Jo, dann wird die Sache zu einem sinnvollen Steuercomputer. Im SPS Basic
habe ich das ja auch so gemacht, damit man die beiden 8255, den ADC und
den DAC aus Basic heraus ansprechen kann. Es ist eben der 8k
Speicherplatz, der das alles ein wenig einschränkt - ich habe die Timer
2 Befehle rausgeschmissen, um Platz zu schaffen.
Interessant ist das Basic aber auch als reine Programmierkunst. Beim
Beschäftigen damit habe ich hin und wieder beeindruckt vor mich hin
genickt über das, was die Intel Jungs damals vor fast 25 Jahren da alles
gemacht haben. Alleine das Floating Point Paket ist schon ein Genuss.
Jetzt ist der Bootloader auch in der Lage mit dem 28C256 umzugehen. Im
Moment sind es noch zwei Programme zum Download eines Anwenderprogramms
vom PC in den IS51 Programmspeicher. Eines für das EEPROM und eines für
das RAM. Werde die beiden zusammenfassen und die Unterscheidung durch
einen Aufrufparameter treffen.
Ausserdem ist die Baudrate des Bootloaders jetzt 19200, damit man den
Gechwindigeitsvorteil des RAM etwas nutzen kann und die Übertragung zum
EEPROM etwas schneller geht.
Mit dem EEPROM kann die Schaltung nun auch für Steuerungen eingesetzt
werden, da ein leerer Kondensator/Batterie keine Probleme mehr bereiten
kann.
Muß noch das Hardwaredebugging mit Keil's ISD51 prüfen, mal sehen ob das
auch mit dem EEPROM umgehen kann?
Gruß. Tom
Hier die neuen Dateien zum Download einer Datei durch den Bootloader.
Und der dazugehörige Bootloader mit 19200 Baud. "Send.exe" ist das
Sendeprogramm und "Send.txt" eine Kurzbeschreibung dazu.
Gruß Tom
Habe jetzt ein kleines Board, speziell für den Basic-Compiler,
entworfen. Natürlich wird auch der Bootloader damit funktionieren.
Das Board hat halbes Europaformat (80 x 100mm) und kann so mit den Eagle
Testversionen ab Version 6 bearbeitet werden. Das Layout ist einseitig,
so daß es im Hobbylabor zu fertigen ist.
Habe euch die Schaltpläne, die Bestückung und das Layout beigefügt.
Bitte noch nicht nachbauen, das Layout ist noch nicht überprüft. Ich muß
jetzt erst mal eine Platine davon machen, um zu sehen ob alles paßt und
ob es auch richtig funktioniert. Wenn es zufriedenstellend funktioniert
schnüre ich ein Paket und stelle es ein.
Ein paar Eckdaten:
64k-Byte externer Speicher in 2 Bausteinen. Das 32k-RAM von 0000h bis
7FFFh ist ein 62256 o. ä. in einem schmalen DIL-Gehäuse. Es ist nicht
mit der Batterie verbunden, da es vom Basic beim Start gelöscht wird. Es
befindet sich unter dem Sockel des 2. Bausteins. Dieser kann
batteriegepuffertes RAM oder ein EEPROM Typ 28C256 ö.ä. sein.
Das Board hat zwei Erweiterungsstecker. Auf den kleinen 20pol. sind die
Signale von P1 und P3 geführt. Unter anderen auch die ISP-Signale,
dadurch kann der µC, über Adapter, in der Schaltung programmiert werden.
Ein Umschalter kann die RXD und TXD-Signale auch auf diesen Stecker
schalten.
Der zweite Stecker dient der Ein- Ausgabeerweiterung, die Platine ist
für bis zu 256 zusätzliche 8Bit-Ports vorbereitet. Die Erweiterung
benutzt MemoryMapped I/O und der Dekoder für die letzte Memorypage
(FF00h bis FFFFh) ist bereits integriert. Die Erweiterung selbst kommt
dann auf eine zweite Platine und bildet mit der Basicplatine ein
Sandwitch.
Als Quarz denke ich an einen 14,745MHz Typen, um mit einer hohen
Baudrate zu arbeiten. Werde die nächsten Tage weiter daran arbeiten.
Ich würde als µC den 89S8253 empfehlen. Zum Einen zickt der nicht so
beim ISP programmieren wie der 89S52, zum Anderen verfügt er über 12k
Programmspeicher. Da ist mehr Platz für das Basic und dessen
Erweiterungen.
Gruß. Tom
Den ersten Fehler habe ich beim ansehen der Pläne eben entdeckt.
Die RXD-Led LED2 soll am MAX232 nicht an Pin12, wo sie den Datentransfer
stören kann, sondern an Pin 9.
TomA schrieb:> Ich würde als µC den 89S8253 empfehlen. Zum Einen zickt der nicht so> beim ISP programmieren wie der 89S52, zum Anderen verfügt er über 12k> Programmspeicher. Da ist mehr Platz für das Basic und dessen> Erweiterungen.>> Gruß. Tom
Hallo Tom, ich hab mal die Erfahrung von Matthias hierher kopiert.
Vielleicht ganz nützlich bei der Grundauslegung.
Er schreibt laut Beitrag "Re: Basic für 80C31"
Übrigens kann ich die AT89S8253 nicht empfehlen.
Erstens lassen ausgerechnet die sich nicht mit dem AVRISP
programmieren und zweitens haben sie ein paar Bugs, die einige der
Features unnutzbar lassen, wie den internen EEPROM. Mir ist es z.B. in
stundenlangen Versuchen damals nicht gelungen, diesen EEPROM zu nutzen -
ich bin dann wieder zum problemlosen 89S52 mit externem 93C46 EEPROM
gewechselt, als ich meinen Steuerechner für den Bassverstärker baute.
Die AT89S8252 kenne ich nicht. Ich habe entweder meine Programme in den
89S52 reinbekommen oder gleich einen z.B. AVR benutzt.
So, die Platine ist geäzt. Das erste Bild (IS51BasPl1) zeigt die leere
Platine, hatte zufällig eine mit den richtigen Masen herumliegen. Die
Punkte sind Stellen an denen sie stark oxydiert ist, sollte aber nicht
weiter stören.
Im zweiten Bild (IS51BasPl2) die betonierte Platine. Hier rächte sich
schlampiges arbeiten. Hatte nach dem Reinigen der Platine mit Stahlwolle
vergessen sie mit einem fettfreien Tuch abzureiben und so hielt der
Toner an ein paar Stellen nicht :( Aber nichts was sich nicht mit einem
Lackstift wieder in Ordnung bringen ließ. Die schwarzen Kleckse des
Lacks sind deutlich zu sehen.
Im dritten Bild (IS51BasPl3) ist die geätzte Platine, sie ist gut
geworden und im Gegenlicht erkenne ich keine Fehler. Jetzt werde ich sie
noch bohren und bestücken, um zu sehen ob alles paßt und funktioniert.
Bis jetzt hat es noch keine zwei Stunden gedauert, die Platine zu
machen. Das bohren dauert auch höchstens eine Stunde. Bestücken wird,
wegen der vielen Brücken, länger dauern.
@Janus. Ich habe nur gute Erfahrungen mit dem 89S8253. Bis zur Revision
K waren da tatsächlich viele Fehler drin, inzwischen läuft er
einwandfrei. Die Probleme mit EEPROM und Watchdog sind behoben. Aber du
hast recht, man braucht ein geeignetes Programmiergerät für die 89S825x.
Gruß. Tom
Ah.. ein selber Ätzer und Bohrer ;-)
Das tue ich mir nicht an.. ;-) Habe auch keinerlei Werkzeug dafür..
Dafür kann man aber ein Platine in ein paar Stunden haben.. ich muss
Wochen darauf warten..
Da du Eagle Freeware verwendest, kannst du dann (oder ich) aus dem
einseitigen Layout auch noch alternativ ein 2-seitiges erstellen.
Den heutigen Platinenfertigern ist es fast egal ob einseitig oder
2-seitig.
Dann spart man sich die Brückenanfertigungen und hat oben auch gleich
Lötstoplack drauf..
Peter
Hallo petersieg,
habe sie eben gebohrt und mit Lötlack besprüht. Nachdem der trocken ist,
beginne ich mit bestücken.
Die Platine ist bereits zweiseitig, beim Leiterplattenfertiger werden
die Brücken als zweite Seite durchkontaktiert und geäzt. Wer sie selbst
und einseitig macht, bestückt die Brücken als Draht.
Bevor ich die Eagle-Dateien freigebe, muß ich aber erst mal am
Prototypen prüfen ob die Bauteile passen und die Schaltung auch richtig
funktioniert. Es kann für Nachbauer auch Probleme mit den Bibliotheken
von Eagle geben, da ich sehr viele Bauteile selbst definiere und sie
somit fehlen.
So der Lötlack könnte nun trocken genug sein.
Gruß. Tom
Die Brücken sind bestückt, gab keine Probleme wegen zu kleiner Restringe
oder Lötbrücken wegen zu geringer Abstände. Habe die Bestückungsseite
mit den Brücken jetzt weiß lackiert, so werden die Brücken fixiert und
isoliert, falls mal der Schraubendreher oder was anderes Leitfähiges
runterfällt. Muß wieder warten bis der Lack ....
Bei Interesse könnten sich ja mehrere Leute zusammentun und gemeinsam
Platinen fertigen lassen, dadurch wird es sicher günstiger.
Bei der Gelegenheit fällt mir ein, daß ich hier mal ein kleines Lehrbuch
als PDF veröffentlicht hatte. Darin wird die Hardware des 8051 und sein
Befehlssatz, auf deutsch, beschrieben.
Hier der Link: Beitrag "MCS51-Kurs sinnvoll?"
Platine ist fertig und kann morgen getestet werden. Das bestücken war
nicht sonderlich kompliziert, das kann sogar ein Anfänger mit ein wenig
Löterfahrung.
Alle Bauteile passen, sogar der 1F GoldCap. Den schmalen RAM-Baustein
habe ich auch gesockelt, dazu mußte ich die Bohrungen auf 1,4mm
Durchmesser vergrößern und dann einzelne gedrehte Kontakte einsetzen
(Bild: Brücken). Der große Baustein hat einen normalen gedrehten Sockel
und liegt deshalb höher. So passen beide Bausteine übereinander und sind
dennoch gesockelt.
Ein Bild der bestückten Platine ist im Anhang. Links neben der Platine
ist ein kleiner gefädelter Programmieradapter für ISP zu sehen. Damit
kann der 51er in der Schaltung programmiert werden. Also das Basic oder
den Bootloader in den Baustein brennen. Die eigentlichen
Betriebsprogramme gelangen dann über die RS232 in den Arbeitsspeicher
der Platine.
Habe bis jetzt drei Fehler gefunden. Bei IC6 (74HC00) sollen nur die
drei Pins 3, 4 und 5 verbunden sein. Durch verschieben des IC habe einen
Pin auf die Leitung zwischen den Pins geschoben und das nicht bemerkt.
Am schmalen RAM IC2 ist der Pin OE (IC2-22) noch mit PSEN (IC1-29)
verbunden, für ein RAM muß er natürlich auf WR (IC1-16).
Dann ist noch die Anschlußklemme KL1 falsch herum, sie paßt nicht zu
meinen anderen Boards.
Habe die Änderungen im Layout schon gemacht und die Grundfunktionen
getestet. Durch den 14,745MHz Quarz funktioniert jetzt die Baudrate bis
115200 (Bild).
Das Basic werkelt, so weit ich das überblicke, anstandslos. RAM und
EEPROM im Bereich 8000h bis FFFFh ermöglichen die Speicherung von
Programmen. Die Stromaufnahme des RAM im Pufferbetrieb beträgt 0,3µA bei
fast vollem GoldCap (4,5V).
Das RAM von 0000h bis wird vom Basic erkannt und ohne dieses würde das
Basic gar nicht arbeiten. RS232 läuft sehr gut.
Die Erweiterungsstecker sind noch nicht geprüft, für den 34poligen muß
ich erst noch Hardware zum testen bauen.
Mit dem Bootloader funktioniert auch alles (bis 115kBaud), ausser dem
EEPROM. Ich nehme an, daß sich durch den neuen Quarz das Timing zu weit
verändert hat.
Sieht eigentlich schon ganz gut aus. Gruß. Tom
In der Fehlerbeschreibung habe ich den RAM-Fehler durch einen Fehler
ersetzt.
OE des RAM gehört auch nicht auf WR, sondern auf RD (IC1-17) des 51er.
:(
Ich muß mich mal mit etwas Anderem beschäftigen, um den Kopf wieder frei
zu bekommen. :P
Gruß Tom
Habe hier noch etwas nettes, die Bestückungs- und Testanweisung für das
Eingangs aufgeführte Experimentierbooard. Ob die Bauteilnamen IC1, R5
usw. für diese Version des Boards noch stimmen, habe ich nicht
überprüft.
Das Grundlegende kann man auch für das neue "Basic"-Board brauchen :)
Gruß. Tom
Mir ist noch was aufgefallen. Ist eher ein Sicherheitsaspekt.
Eine Freilaufdiode wird fast nie benutzt ist aber im Falle das mal die
Ausgangsspannung grösser als die Eingangsspannung ist ganz sinnvoll.
Noch ein Beispiel angehängt wie so was aussieht D3 ist die
Freilaufdiode.
Janus M. schrieb:> Eine Freilaufdiode wird fast nie benutzt ist aber im Falle das mal die> Ausgangsspannung grösser als die Eingangsspannung ist ganz sinnvoll.
Bei einem 7805 ist die unnötg! Da passiert nichts.
Schau ind Datenblatt.
Habe den kleinen Erweiterungsstecker, mit den Port 1 & Port 3 Signalen,
durchgemessen und mit bestehender Hardware überprüft - der funktioniert.
Den großen Stecker zur Ein/Ausgabe- oder Speichererweiterung konnte ich
nur durmessen, da mir dazu noch Hardware fehlt. Laut Messungen ist er
auch in Ordnung.
Muß jetzt nur noch überprüfen, ob sich das Layout wirklich mit der
Testversion von Eagle bearbeiten läßt.
Gruß. Tom
Habe in der Nacht noch versucht, unter Basic, den Port 1 der Schaltung
anzusprechen. Im Handbuch fand ich dafür die Bezeichnung "PORT1". Also
mit einem Draht Pins auf 0 gezogen und mit "PRINT PORT1" die Bitzustände
gelesen und im Terminal angezeigt - funktioniert gut.
Die Ausgabe zum Port kriege ich nicht auf die Reihe. Eigentlich sollte
doch ein "PORT1 = 128" die Bit 0-6 zu 0 und Bit 7 zu 1 schalten. Oder
liege ich da falsch? Bin leider kein großer Basic-Programmierer. Unter C
und Assembler geht es, liegt also nicht an der Hardware.
Habe es auch mal mit den empfohlenen Logikbefehlen PORT1 = PORT1.AND.128
versucht, ohne Erfolg. Was mache ich falsch? Oder hat das Basic einen
Fehler?
Gruß. Tom
Hier die Pläne zur neuen IS51 Platine. Die gefundenen Fehler sind
beseitigt und bei mir läuft der Prototyp ganz gut.
Gelegentlich bemerke ich noch einen Datenverlust des RAM bei
Batteriepufferung. Ob das nun an den verkleinerten Kondensatoren im
Netzteil, oder am 89S52 liegt, weiß ich noch nicht. In vergleichbaren
Schaltungen mit 89S825x passiert das nicht, dort habe ich aber größere
Kondensatoren im Netzteil. Abhilfe schafft, den Resettaster während des
ein- und ausschaltens gedrückt zu halten.
In den Datenblättern der µC finde ich für die 89S825x eine integrierte
Spannungsüberwachung, der 89S52 hat diese nicht. Ich vermute dort liegt
das Problem. Habe jetzt einen 89S8253 eingesetzt und werde das Verhalten
beobachten.
Die Eagle-Dateien brauchen noch eine Prüfung mit einer Demoversion, wird
also noch etwas dauern.
Gruß. Tom
Übrigens habe ich inzwischen den 89S52, 89S8252 und 89S8253 über ISP in
der Schaltung programmiert. Sowohl der Bootloader als auch das Basic
lassen sich mit einen kleinen Adapter über den Erweiterungsstecker
flashen.
Ist wirklich praktisch, bei Änderungen der Firmware (z.B dem Basic) den
µController nicht aus dem Sockel nehmen zu müssen.
Die eigentlichen Arbeitsprogramme werden ohnehin über die RS232 ins
RAM/EEPROM übertragen, da braucht es kein Programmiergerät. :)
Noch etwas, die Widerstände R5 (220 Ohm), R6 (10kOhm) und R7 (560 Ohm)
liegen als SMD Bauteile auf der Lötseite der Platine. Unter dem
Reset-Taster und beim Transistor TR2.
TomA schrieb:> Oder hat das Basic einen> Fehler?
Das Basic funktioniert. Lies doch mal den Port 1 ein, nachdem du
einzelne Pits in ihm auf low gesetzt hast.
Dazu muss man wissen, das der Port im Betrieb als Ausgang nur auf low
ziehen kann, normalerweise braucht man dort Pullups, die ihn bei
Inaktivität auf high ziehen. Im Zustand 'high' wird er dann auch als
Eingang benutzt.
Hallo Matthias,
einlesen vom Port 1 habe ich schon gemacht, geht einwandfrei. Nur einen
Wert ausgeben funktioniert nicht. An den Pullups kann es nicht liegen,
denn die Ports 1, 2 und 3 haben integrierte Widerstände (10k-47k) mit
Transistor zur Flankenunterstützung. Bei Port 0 fehlen diese
integrierten Widerstände, aber dafür ist das Widerstandsnetzwerk RN1 auf
der Platine.
Gruß. Tom
@TomA: Die Platinenfertiger, die ich kenne benötigen aber die Eagle BRD
Datei und können mit PDF's rein gar nichts anfangen..
Argh: Überlesen:
"Die Eagle-Dateien brauchen noch eine Prüfung mit einer Demoversion,
wird
also noch etwas dauern."
Sorry.
Peter
Hallo Peter,
überprüfung abgeschlossen. Habe mit einer Demoversion versucht Bauteile
zu verschieben und ein paar kleine Änderungen zu machen. Ließ sich alles
machen, denke ich kann es freigeben.
@All: Der Datenverlust im RAM bei Batteriepufferung liegt am 89S52. Habe
jetzt mit dem 89S8252 versucht den Datenverlust zu reproduzieren, ist
mir nicht gelugen. Wer also auf den Datenerhalt Wert legt, sollte einen
89S8252 oder 89S8253 verwenden.
Mit der Ausgabe zu Port 1 unter Basic bin ich noch nicht weiter
gekommen. Mit dem Bootloader und einem C-Programm kann ich die Ports
beliebig bedienen, lesen und schreiben funktionieren wie gewollt. Nur
unter Basic kann ich nicht schreiben. Weiß inzwischen, daß es mit "PORT1
= XX" funktionieren sollte. Da es unter C oder Assembler geht, kann ich
einen Hardwarefehler ausschließen. Es muß am Basic liegen!
Gruß. Tom
Hallo Peter,
keine Ursache, habe es gerne gemacht.
Wenn INTEL sich nicht zu schade ist das Basic zur allgemeinen Verfügung
zu stellen, brauche ich mich nicht zieren eine Hardware zu
veröffentlichen.
Werde als nächstes die kleine Ausgabeplatine für Alle zugänglich machen,
und noch eine Port-Erweiterungskarte für den großen Stecker.
Danach werde ich noch zeigen, wie man mit der Hard- und Softwareware
umgeht. Dabei liegt der Schwerpunkt aber beim Bootloader, C, Assembler
und wie man mit der Keil-Demo umgeht. Damit hat jeder Interessierte
Lehrmittel für wenig Geld zur Verfügung. Meine Empfehlung für den µC
wäre immer noch der 89S8252 (8K aber schon abgekündigt) oder 89S8253
(12K aktuell), sofern man ein Programmiergerät dafür hat. Bei ATMEL gibt
es auch die Pläne und Software für so ein Gerät an einer
LPT-Schnittstelle. Sich erst ein Programmiergerät dafür zu kaufen halte
ich für überflüssig, da man den µC nicht so oft flasht. Da wird das
Basic oder der Bootloader darauf gebrannt und das wars.
Aber zuerst muß ich mir den Augabefehler in Basic ansehen und die
Erweiterungsports in Basic zugänglich machen.
Gruß. Tom
Wieder ein Stück weiter. Den Ausgabefehler hatte ich selbst
programmiert. Meine Änderungen am Timer 2 ließen den Tokenscanner vor
dem Abarbeiten der ganzen Liste abbrechen, so kam er gar nicht mehr zum
PORT1-Token und Anderen. Habe meine Änderungen korrigiert und nun geht
Port1 wieder.
Die Befehle zur Ein/Ausgabeerweiterung muß ich gar nicht integrieren,
sie sind im Basic schon vorhanden. Die Erweiterungsports sind
memorymapped angelegt, so werden sie angesprochen wie Speicherzellen.
Die Befehle um in Speicherzellen zu schreiben oder aus ihnen zu lesen
kennt das Basic bereits. :)
Werde morgen eine kleine Ein/Ausgabeplatine fädeln und ausprobieren ob
das funktioniert wie erwartet.
Seit ich den 89S8253 verwende gibt es auch kein Problem mit dem
Datenerhalt im RAM mehr.
Habe testweise die ursprüngliche Eingaberoutine wieder aktiviert, damit
ist es unmöglich mit 115kBaud zu arbeiten.
Gruß. Tom
Hier noch das geänderte Basic, welches auch Ausgaben zu Port1
ermöglicht.
Und eine Version des Bootloaders, so wie er im Moment ist. Er arbeitet,
wie das Basic, mit einer Baudrate von 115200Baud.
Nachdem es schon sehr unübersichtlich mit den vielen Versionen ist,
werde ich am Ende ein Packet mit den endgültigen Versionen Hard- und
Software samt Quellcode schnüren.
Inzwischen steht fest, der 89S52 und ähnliche µC ohne integrierte
Spannungsüberwachung, sind nicht in der Lage eine brauchbare
Datenpufferung zu gewährleisten. Sie brauchen die ursprüngliche
Schaltung mit dem Überwachungschip TL7705. Wer nur mit Basic arbeitet,
bemerkt das Problem nicht, da das Basic bei jedem Start das RAM löscht.
Wer also ohnehin einen µC für das Board kaufen muß, sollte einen
AT89S8252 wählen. Der hat auch gleich den Vorteil daß er 12KByte
internen Programmspeicher besitzt. Da ist dann viel Platz für
Erweiterungen des Basic oder umgehen der 2K-Grenze der Keildemo.
Aber jetzt wird gefädelt. :)
Viel Erfolg und Spaß. Tom
Beim planen der Ein/Ausgabeerweiterung ist mir aufgefallen, daß das
Signal "ECS" den falschen Pegel (High-aktiv) hat, und damit nicht zu
meinen anderen IS5x-Platinen paßt. Damit ich auf Allen mit der gleichen
Hardware arbeiten kann, greife ich das Signal jetzt vor dem NAND-Gatter
IC6C ab, wo es Low-aktiv ist.
Gruß. Tom
Habe hier noch den Schaltplan und das Layout für die IS51-EA1 Platine.
Das ist die Ein/Ausgabeplatine für den kleinen Erweiterungsstecker.
Beschrieben ist sie im Handbuch der IS51. Auf ihr befinden sich zwei
Taster (INT0, T0) 8 Leuchtdioden und 8 Schalter. Sie ist für
Softwareexperimente gedacht, steuern kann man damit nichts.
Im Anhang das Layout und der Bestückungsplan. Leider sind in den
Eagledateien, zum zentrieren des Bohrers, Bauteile mit kleinen
Bohrdurchmesser verwendet, so daß man für industrielle Fertigung die
Bauteile erst austauschen muß. Selbstätzer können das Layout direkt
benutzen, für Andere werde ich das Layout ändern.
Mit der neuen Ein/Ausgabeplatine bin ich auch schon weiter. Anstatt sie
zu fädeln, habe ich gleich ein Layout gemacht und fädle nur noch was ich
an Leiterbahnen nicht untergebracht habe. Ist nicht viel mehr Aufwand
als nur fädeln, aber ich habe gleich eine Basisplatine.
Die neue Platine trägt 8 Erweiterungsports zu je 8 Bit, 4 Eingabeports
und 4 Ausgabeports. Muß die Platine noch bohren und bestücken, dann
folgen die Funktionstests.
Gruß. Tom
Habe die Platine jetzt gebohrt und die beiden Platinen, probeweise, zum
Sandwitch montiert. Sie passen perfekt aufeinander.
So ergeben die beiden Platinen einen netten kleinen Steuerrechner mit 9
1/2 Ports. 4 Eingabeports (4 x 8 = 32 Eingabebit), 4 Ausgabeports (32
Ausgabebit) und 1 1/2 bidirektionale Ein/Ausgabeports (Port 1 und 1/2
Port 3).
Dabei kam mir der Gedanke, das Projekt auf meinen VG Bus zu
konvertieren. Wenn man in der bisherigen Bauweise mehr Zusatzplatinen
wie A/D - D/A, Display, Relais, usw braucht, wird der Platinenstapel
immer höher :(
Bei VG steckt man einfach eine weitere Platine in den Bus.
Die Erweiterungsplatine ist fertig und alle 8 Ports funktionieren. Auf
die gleiche Art lassen sich bis zu 256 Eingabeports und gleichzeitig bis
zu 256 Ausgabeports realisieren. In einem der Portstecker befindet sich
eine kleine Testplatine mit 8 LED's und 8 Schaltern.
Das bestücken ist ganz einfach, aber das fädeln der Verbindungen des
Toplayer kann ich niemanden zumuten. Es ist sehr zeitraubend und man muß
sich stark konzentrieren. Da wäre es einfacher gewesen, die Platine nur
zu fädeln.
Ich könnte das Layout ändern, so daß teilweise zwei Leiterbahnen
zwischen zwei IC-Beinchen geführt sind, aber das können dann nur wenige
nachbauen.
Eine andere Lösung wäre, weniger Ports auf die Platine zu packen? Muß
mir deswegen noch was überlegen.
TomA schrieb:> Hier noch das geänderte Basic, welches auch Ausgaben zu Port1> ermöglicht.>> Und eine Version des Bootloaders, so wie er im Moment ist. Er arbeitet,> wie das Basic, mit einer Baudrate von 115200Baud.>> Nachdem es schon sehr unübersichtlich mit den vielen Versionen ist,> werde ich am Ende ein Packet mit den endgültigen Versionen Hard- und> Software samt Quellcode schnüren.>> Inzwischen steht fest, der 89S52 und ähnliche µC ohne integrierte> Spannungsüberwachung, sind nicht in der Lage eine brauchbare> Datenpufferung zu gewährleisten. Sie brauchen die ursprüngliche> Schaltung mit dem Überwachungschip TL7705. Wer nur mit Basic arbeitet,
Kann ich dieses Basic auch noch für meine Schaltung einsetzen. Hab jetzt
einen 89S52?
Hier noch der Schaltplan der Erweiterungskarte.
Die Karte kennt, für jede Richtung, 4 Adressen.
XPort0 = 0FF00h - 8Bit lesen, 8 Bit schreiben (ST2)
XPort1 = 0FF01h - 8Bit lesen, 8 Bit schreiben (ST3)
XPort2 = 0FF02h - 8Bit lesen, 8 Bit schreiben (ST4)
XPort3 = 0FF03h - 8Bit lesen, 8 Bit schreiben (ST5)
Der mögliche Adressbereich von 0FF00h bis 0FFFFh ist von der Karte nicht
vollständig dekodiert. Jede Adresse ist zweimal vorhanden, für lesen und
schreiben. Im Adressbereich 0FF00h bis 0FF80h erscheinen die vier Ports
gespiegelt alle vier Adressen. XPort0 also unter 0FF00, 0FF04, 0FF08
usw.
Die Hardware legt die Erweiterungsports in den Bereich des externen
Arbeitsspeichers (memory mapped I/O) und so werden die Ports
angesprochen wie Speicherzellen.
Zugriff auf XPort1:
Ausgabe Basic: XBY(Portadresse) = Wert, z.B: XBY(0FF01h)=0C3h
Eingabe Basic: PRINT XBY(Portadresse), z.B: PRINT XBY(0FF01)
Ausgabe Assembler: MOV DPTR,#0FF01h - MOVX @DPTR,A
Eingabe Assembler: MOV DPTR,#0FF01h - MOVX A,@DPTR
Ausgabe C: unsigned char xdata *bPtr = 0x0FF01; - *bPtr = 0x5B;
Eingabe C: unsigned char xdata *bPtr = 0x0FF01; - xy = *bPtr;
Hallo Janus,
das Basic wird mit dem 89S52 auch funktionieren. Das einzige Problem ist
die fehlende Spannungsüberwachung des Chips. Damit kann er den Inhalt
des Batteriegepufferten RAM's (8000h bis FFFFh) nicht gewährleisten. Mit
Basic wird dieses RAM nicht zwingend gebraucht, es dient, wie früher das
EPROM, der Speicherung von Programmen. Ob das Problem auch beim EEPROM
28C256 besteht, habe ich noch nicht untersucht.
Das RAM, welches das Basic zwingend benötigt (0000 bis max. 07FFFh) ist
davon nicht betroffen. Der Basicinterpreter löscht es bei jedem Neustart
ohnehin. Fazit: Das Basic läufz mit dem 89S52 hervorragend, es kann nur
keine Programme im externen RAM speichern.
!!!!! WICHTIGER Hinweis für alle !!!!!
Wird als µC der 89S8253 eingesetzt so MÜSSEN die kleinen Kondensatoren
C1 und C2 (22pF) am Quarz entfallen. Im Gegensatz zu anderen Controllern
der MCS51 Reihe braucht er nur 5pF und die sind durch das Layout
hinreichend gegeben. Bleiben die größeren Kondensatoren am Quarz, hat
der interne Oszillator Probleme beim anschwingen (schwingt nicht oder
falsche Frequenz).
Gruß. Tom
Hier noch ein kleines Testprogramm in Basic für die Erweiterungskarte.
Es zählt die Variable A von 0 bis 255 hoch und gibt den Inhalt der
Variable zum XPort0 aus, das ganze läuft in einer Endlosschleife mit
Zeitverzögerung, damit es nicht zu schnell für unsere Augen geht.
Damit möchte ich meinen Ausflug in Basic beenden, war interessant mal
über den eigenen Tellerrand zu blicken.
Im Moment arbeite ich an einer abgespeckten Version der Ein-
/Ausgabeerweiterung mit 4 Ports, 2 Eingabe- und 2 Ausgabeports. Mal
sehen ob dieses Layout "Bastelfreundlicher" wird.
Gruß. Tom
Habe die Platine der 4 Port Erweiterungskarte jetzt fertig. Muß sie noch
bohren bestücken und testen. Schon jetzt ist klar, sie ist viel
einfacher zu handhaben ist als die mit 8 Ports. Auf ihr brauchen zu den
Brücken keine weiteren Drähte zu verlegt werden. Konnte es mir aber
nicht verkneifen, teilweise zwei Leiterbahnen zwischen den IC-Pins zu
verlegen.
Auf ihr befinden sich 4 Ports mit je 8 Bit, 2 Ausgabeports und 2
Eingabeports. Sie ist beinahe vollständig dekodiert, mit ihren 4 Ports
belegt sie 8 Adressen (0FF00h bis 0FF07h).
Da die Schaltung der IS51EA4 im Grunde die gleiche wie bei der IS51EA8
ist, gehe ich davon aus, daß sie funktionieren wird.
Wie erwartet funktionieren alle 4 Ports der neuen Erweiterungskarte. Das
herstellen der Platine ist für einen geübten Platinenätzer kein Problem.
Der Aufbau ist deutlich einfacher als bei der großen Erweiterung. Für
Anfänger im ätzen und löten ist das Basic-Projekt allerdings nicht
geeignet.
Im Bild ist das Sandwich, auf der ein Programm läuft, das die
Schalterstellung einließt und zu den Leuchtdioden ausgibt.
Werde jetzt die Pläne zum veröffentlichen vorbereiten. Nun fehlt noch
eine Möglichkeit den Bootloader oder das Basic in den Chip zu brennen.
Hier die Pläne zum Nachbau der Erweiterungsplatine. Die Eagledateien
kommen auch noch.
Habe beide Erweiterungsplatinen auch mit dem Bootloader getestet,
funktionieren tadellos.
Der Bootloader ist ein Programm im µC-Chip, welches es dem Anwender
ermöglicht ein Programm, über die RS232 Schnittstelle, in den
Programmspeicher (RAM/EEPROM) der IS51 zu übertragen und dort zu
starten. Damit kann man auf dem PC ein MCS51-Programm erstellen und zur
Platine downloaden. Das Programm muß im IntelHex-Format vorliegen, aber
das kann jeder Assembler oder Compiler denke ich, µVision kann es auf
jeden Fall.
Werde jetzt noch eine einfache Möglichkeit zum flashen des µC suchen,
danach die Hardware dokumentieren und anschließend eine kleine
Einführung in die Programmierung der IS51 in C und Assembler, unter Keil
µVision und dem Bootloader zeigen.
Schöne Woche. Tom
Hier noch die Eagle-Dateien zur 4 Port Erweiterungskarte.
Habe mir den Kabelprogrammierer von ATMEL angesehen (bei ATMEL, bei den
Tools für 89S52 zu finden), der kann leider den AT89S8253 nicht.
Vermutlich wird die Programmiersoftware auch nur bis Windows XP
funktionieren :(
Gruß. Tom
Hallo Leute,
habe die letzten Tage etwas im Internet gestöbert, um ein praktikables
und nachbausicheres Programmiergerät für die MCS51 zu finden. Dabei fand
ich TCB "Tiny Control Basic". Es handelt sich dabei um ein abgespecktes
Intel-MCS51 Basic. Zu finden ist das ganze bei Elektor im Septemberheft
2004 Artikel "Swiss Army Knife" und auch als Download bei Elektor. Dort
kann man ein Terminalprogramm und zwei verschiedene Versionen des Basic
herunterladen. Einfach die Software downloaden. Das ganze (Terminal und
Basic) steckt in einer Zip-Datei.
Leider liegen dort nur die Hex-Files des Basic, keine Quellen. Habe das
Basic in den µC meiner Platine geflasht, es hat sich sofort gemeldet.
Ein Problem ist die Baudrate der Datenübertragung. Das "Army Knife"
arbeitet mit einem Quarz von 22,1184MHz, mein Board mit 14,745MHz.
Dazwischen liegt ein Faktor von genau 1,5.
Wenn ich in hterm die Baudrate auf 6400 stelle, paßt sie genau zur
erforderlichen Baudrate für das Basic. Das Basic möchte mit 9600Baud
arbeiten, durch den niedrigeren Takt wird bei mir daraus 6400Baud.
Eine andere Möglichkeit ist, nach Reset der Platine das Space-Zeichen
(0x20), innerhalb von zwei Sekunden, zu senden. Damit stellt sich das
Basich automatisch auf die verwendete Baudrate ein. Das funktioniert
aber nur bis maximal 19200 Baud.
Ich konnte mit dem Basic komunizieren, aber beim speichern und ausführen
von Programmen lief etwas schief. Habe mich dann nicht näher damit
befasst, da ich keine Quellcodes habe und das originale Basic gut
funktioniert.
Programmiergerät habe ich kein geeignetes gefunden, so muß ich selbst
eines konstruieren. Ich hatte schon zwei verschiedene Programmiergeräte
für die MCS51 entwickelt, aber beide haben einen Pferdefuß.
Eines wird an eine Druckerschnittstelle angeschlossen und bedient die
Signale mit Bitmanipulation. Das Problem dabei ist der Scheduler des
Betriebssystems, welcher ständig das Timing des Programms durcheinander
bringt. Seit Win7 funktioniert dieses Prinzip nicht mehr zuverlässig.
Das Andere ist über USB an den PC gebunden, das funktioniert auch unter
Win7 hervorragend. Leider ist mein USB nur VUSB und wird nicht von jedem
Betriebssystem unterstützt.
Im Moment arbeite ich an einem Programmiergerät, das nachbausicher ist
und ohne programmierbaren Baustein auskommt. Das Konzept und ein Teil
der Hardware steht schon. Mehr dazu, wenn es funktioniert.
Gruß. Tom
Sprichst Du von dem hier?:
https://www.elektormagazine.de/magazine/elektor-200409/1985
Ich hab hier noch einen Adapter für den Juniorprommer der selbst an den
PC und den Atari angeschlossen werden kann.
Mit diesem Adapter können 40-polige 8051-kompatible Microcontroller
mit Pinatubo sowie einem der unterstützten Eprommer programmiert
werden - im einzelnen sind das:
8751, 87C51, 8752, 87C52
89C51,89C52 (FLASH-Typen von Atmel)
sowie dazu kompatible Typen.
Anbei noch Schaltplan und Bestückung des Juniorprommers. Vielleicht
hilft es ja bei dem Vorhaben etwas.
Anbei noch das Programm um alles in Windows laufen zu lassen.
Hallo Janus,
danke für die Pläne. Leider sieht es so aus, als wäre das ein Programmer
für den Paralellmode und zudem hat er einen programmierten Baustein.
Ich denke, für die MCS51 mit ISP, an einen Programmer an RS232 (auch
CDC-USB) für ISP, welcher ohne programmierten Chip auskommt. Wenn jemand
anfängt sich mit der IS51 zu beschäftigen, soll er den Programmer
einfach nachbauen können, ohne bereits ein Programmiergerät zu besitzen.
Anfänglich muß nur das Basic oder der Bootloader in den MCS51 kommen.
Später ist es denkbar, Hardware und ein Programm für die IS51 zu
schreiben, welches diese zum Programmiergerät für alles mögliche macht.
Meine erste Programmer-Hardware war noch unstabil und synchronisierte
schlecht auf die Daten vom UART, aber inzwischen sind diese Probleme
gelöst. Habe heute erstmalig einen 89S52 angesprochen und bereits
Antwort von ihm erhalten. Bin gespannt, ob er sich auch programmieren
läßt.
Das Problem dabei ist das Betriebsystem, das ständig in das Timing des
Programmers pfuscht. Dadurch wird Bitmanipulation an LPT oder COM zum
Glücksspiel. Ich versuche das Problem durch den UART im PC zu lösen.
Wenn die Hardware des UART das Timing (über feste Baudrate) übernimmt,
kann der Scheduler des Betriebssystems nichts daran verändern. Damit
sollte der Programmer auch mit neueren Betriebssystemen harmonieren. Die
nächsten Tage werden zeigen, ob dieses Prinzip funktioniert.
Gruß. Tom
So sieht das Programmiergerät im Moment aus. Die Lochrasterplatine auf
der der erste Prototyp aufgebaut wird, ist im Hintergrund schon zu
sehen. Sie dient im Moment als Adapter zur Verbindung, über
Flachbandleitung, mit der IS51 (rechts oben im Bild).
Wenn der gefädelte Prototyp funktioniert, werde ich eine Platine dafür
entwerfen.
Hier noch ein paar Oszibilder zum Programmiergerät.
Bild "ProgBit.bmp" zeigt das Taktbit (SCL) im Verhältnis zum Datenbit
(MOSI). Die steigende Flanke des Taktsignals übernimmt das Datenbit im
Controller, sie liegt exakt in der Mitte des Datenbit.
Bild "ProgEna.bmp" zeigt die übertragung des 4-Byte Kommando ProgEna zur
Freigabe der Programmierung ACh, 53h, 53h, 53h. Jedes Datenbyte benötigt
8 Taktimpulse, die vier mal acht Taktimpulse sind schön zu sehen.
Bild "ProgAntw.bmp" zeigt oben (gelb) das Signal MOSI zum µC und unten
(grün) das Antwortsignal MISO des µC zum Programmer. :)
Das Prinzip des Programmiergerätes funktioniert. Habe die Hardware auf
dem Steckbrett fertig und etwas Software zum Ansprechen des Bausteins.
Kann einen 89S52 in den Programmiermodus versetzen und löschen. Habe es
mehrfach ausprobiert, klappt jedesmal auf Anhieb. :)
Am Oszi kann ich sehen, wie das Betriebssystem das Timing beeinflußt.
Dies gelingt ihm aber nur zwischen den einzelnen Bytes, die Datenbytes
selbst laufen im festgelegten Timing. Jetzt muß noch schreiben, lesen
... ausprobiert werden.
Gruß. Tom
TomA schrieb:> danke für die Pläne. Leider sieht es so aus, als wäre das ein Programmer> für den Paralellmode und zudem hat er einen programmierten Baustein.
Programmierten Baustein wie GAL oder EPROM hat er nicht. Das ist nur der
Textool Sockel vom Juniorprommer. In diesen wird dann der Erweiterung
für den 89C52 gesteckt.
Leider hat Matthias darauf hingewiesen, dass das dann nicht funktioniert
mit dem 89S52. In sofern hat sich das erledigt. ausser man hat noch ein
paar alte 89C52 in der Bastelkiste rumfliegen.
TomA schrieb:> So sieht das Programmiergerät im Moment aus. Die Lochrasterplatine auf> der der erste Prototyp aufgebaut wird, ist im Hintergrund schon zu> sehen. Sie dient im Moment als Adapter zur Verbindung, über> Flachbandleitung, mit der IS51 (rechts oben im Bild).>> Wenn der gefädelte Prototyp funktioniert, werde ich eine Platine dafür> entwerfen.
UPs das sieht ja wild aus. Bei solchen Verdrahtungsorgien kann man sich
leicht vertun.
Was mir bei dem Programmiergerät nicht so ganz einleuchtet ist, warum
dieser Aufwand. Es reicht doch ein AVRISP und ein Stecker. Oder soll das
AVRISP auch noch auf die Platine?
Geht das denn nicht so wie im Beispiel angefügt? Also einfach einen
Anschlussport auf die Platine und stecker zum AVRISP und der mittels USB
an den PC und dann kanns losgehen.
Hallo Janus,
auf dem Steckbrett sieht das wirklich wild aus. Inzwischen sogar noch
wilder, weil drei IC's dazugekommen sind. Da dieses "Drahtknäuel" aber
sehr gut funkftioniert, kann ich mir den Umweg über eine gefädelte
Platine möglicherweise sparen.
Hintergrund für den Aufwand ist das Kompletpaket MCS51-Harware. Was
hilft einem Einsteiger die schönste 51er Hardware, wenn er kein Programm
in dessen Flash bekommt. Natürlich kann man etwas Fertiges kaufen, wie
den AVRISP, aber das kostet Geld und schränkt ein. Der AVRISP kann z.B:
nur den 89S52, der bessere µC für die IS51 ist aber der 89S8253. Ich
hatte mich im Netz nach Programmiergeräten umgesehen, aber nichts
wirklich brauchbares gefunden. Es muß die verwendeten µC (wenigstens
89S52, 89S8252 und 89S8253) kennen, darf nicht viel kosten und es darf
keinen programmierbaren Baustein benötigen. Welche µC der Eigenbau
letztlich kennt, hängt vom PC-Programm ab, welches das Prog-Gerät
steuert. Da sind auch andere µC als MCS51 möglich.
Ich denke bei dem MCS51-Paket an Lehrwerkstätten, Schüler, Studenten und
interessierte Bastler, bei denen das Budget begrenzt ist. Die gesamte
benötigte Hardware kann für wenig Geld selbst gebaut werden. Ich achte
auch besonders darauf, nirgends exotische oder teure Bausteile zu
verwenden.
Wer schon ein Programmiergerät hat, welches den verwendeten µC kennt,
kann das natürlich verwenden. Alle benötigten Signale sind auf den
kleinen Erweiterungsstecker der IS51 geführt und damit über Adapter
zugänglich.
Habe das Programmiergerät jetzt mit einem USB-RS232 Adapterkabel
ausprobiert, klappt auch problemlos. Es braucht aber einen echten
RS232-Adapter mit den hohen +-Spannungspegeln, mit den einfachen 0/5V
TTL-Pegeln geht es nicht. Obwohl das auch noch eine Überlegung wert ist,
da ISP und Programmer eigentlich die TTL-Pegel benötigen. Aber noch sind
nicht alle Tests abgeschlossen, da kann noch viel schief gehen!
Gruß. Tom
Wenn das so gelingt, wäre das schon klasse. Ich würde das dann glatt bei
meiner Platine integrieren. Der Ansatz mit nicht exotischen Bauteilen
ist auch sehr gut.
Das ideale ist eigentlich ein Maschinchen was man dann mit Basic
beliebig über den PC programmieren kann um alles mögliche zu steuern.
Im Grunde fehlt noch eine sehr abgespeckte Version die dann in irgend
ein Projekt verbaut werden kann.
Im Grunde ist die Experimentierschaltung die Du gerade baust die
Vorstufe.
Läuft alles wie gewünscht dann sollte man eine Art Kopie vielleicht
sogar als SMD parat haben mit Anschlüssen zum Verbauen.
Hallo Janus,
den Programmer auf die Platine zu integrieren macht nur Sinn, wenn der
Controller ständig geflasht werden muß. Für Basic, oder den Boolaoder
werden diese Programme nur einmalig in den µC gebrannt, da ist es besser
einen externen Programmer zu verwenden. Falls der Programmer auf die
µC-Platine integriert werden soll, dann lieber einen Kompakten mit
programmierten Baustein.
Zum integrieren ist der Programmer zu groß. Habe zur Übersicht ein Bild
davon angehängt. Beim angleichen des Schaltplanes an das Steckboard
konnte ich noch zwei IC's einsparen. Es sind jetzt fünf 74HCxx-Bausteine
und nicht, wie im Bild, sieben. Er soll letztlich, wegen seines
Gehäuses, auf eine Platine der Größe der abgebildeten Lochrasterplatine
passen.
Gruß. Tom
Auf Lochraster ist es schon nicht mehr so unübersichtlich. Habe mich
entschieden nun doch eine Lochrasterschaltung zu machen. So kann ich
noch leicht etwas ändern aber es ist nicht mehr so ein "Drahtverhau".
Auch so funktioniert initialisieren und löschen eines AT89S52. Werde nun
die Software weiterentwickeln.
Schönen Sonntag
@Tom: Du warst hier immer nur als Gast angemeldet, sonst hätte ich dich
direkt angesprochen, ohne evtl. den Thread hier voll zu müllen ;-)
Meine Platinen sind gestern gekommen. Ich sagte ja, das ich das mit
Minimalsbestückung aufbauen wollte (USB-TTL Dongle)..
Habe nun 32k Sram small, die 3x74er IC's, 89S52, 14,7456MHz Quarz+2x22pf
bestückt. Diode gebrückt um 74Hc00 mit Strom zu versorgen und SIO
Schalter so gebrückt, das Rx+Tx an Max232 Fassung anliegen. 2x100nf
Abblock-C's sind ebenfalls bestückt.
(100k R-Array habe ich noch - ist aber noch nicht bestückt)
Das 2te Sram/bzw. 28C256 Eprom ist noch nicht bestückt.
USB-TTL Dongle dann:
+5V an 16
GND an 15
Rx an 12
Tx an 11 (+10 sind verbunden)
Läuft aber nicht?! Die Rx+Tx LED leuchten schwach..?
Am Teraterm kommt weder bei 9600 8N1 noch bei 115200 etwas an.
Musst du dich nicht mit auseinandersetzen.. aber evtl. fällt dir auf
Anhieb ein, weshalb das so gar nicht funktionieren kann..?
Im Source steht was von 12MHz.. Passt das mit der Baud und dem 14,x
Quarz denn dann trotzdem?
Noch etwas unschönes (hat mir gestern 3h extra gekostet - nur bevor das
jemand auch noch mal macht..). Im TOP PDF steht klar die IC-Kerbe nach
unten zum Resettaster drin. Im Bild 'Bestueckt' sieht man das schmale
Sram aber genau verkehrt herum eingesteckt.. Mann/ich könnte auf die
blöde Idee kommen, das gehört wirklich genauso orientiert rein, wie die
anderen IC's..
Ich bin zur Zeit auch bei anderen Themen stark eingebunden und werde das
hier dann einstellen, wenn ich keine Lösung sehe :-(
(Ich muss dazu sagen, das ich nur noch eingeschränkte Messmöglichkeiten
habe und auch nur noch wenig Bastelmaterial vorrätig)
(Nicht immer sind alle Projekte erfolgreich)
Peter
Hallo Peter,
der Bootloader und das Basic brauchen den 14,745MHz Quarz und arbeiten
mit 115,2kBaud.
Ich hatte nach dem veröffentlichen der Eagle-Quellen noch etwas
geändert, das ist weiter oben irgendwo beschrieben, werde nachher mal
nachsehen was das war. Das schmale RAM hatte ich verkehrt herum
eingesetzt und damit das Foto gemacht, in den Plänen ist es richtig
eingezeichnet.
Wenn du ein Oszilloskop oder einen Frequenzzähler hast, prüfe das Signal
am Pin-ALE, wenn der Prozessor läuft ist dort die Quarzfrequenz geteilt
durch 6 (2,457MHz) zu messen. Zur Not tut es auch ein Voltmeter, das
Impuls-Pausenverhältnis des Signals ergibt ca. Versorgungsspannung / 3 -
Bei 5V Versorgung damit ca. 1,6V. Wenn ALE vorhanden ist, ist sicher daß
die CPU läuft.
Hast du den µC mit dem Bootloader oder dem Basic geflasht?
@all Das Konzept des Programmiergerätes mußte ich verwerfen, zu
kompliziert und ständig fehlte hinten oder vorne ein Bit. Habe jetzt ein
Neues aufgebaut, das besteht nur aus einem MAx232 und ein paar diskreten
Bauteilen. Es funktioniert wunderbar. Kann bereits den AT89S8252
schreiben, lesen, Leertest, Vergleichen, löschen für EEPROM und Flash.
Für AT89S8253 und AT89S52 habe ich schreiben, lesen und Leertest
erfolgreich probiert. Ist nur eine Frage der Zeit bis die Software die
wichtigsten Funktionen der drei µC kann.
Die Betriebssoftware für den PC arbeitet nun doch mit Bitmanipulation,
aber ich versuche das Timing so gut ich es kann mit dem Scheduler zu
synchronisieren. Unter Windows 7 läuft es ganz gut.
Gruß. Tom
Hallo Peter,
hier sind Änderungen beschrieben. Bei IC6C ist jetzt eine Lötbrücke, um
die Ein/Ausgabeerweiterung High- oder Low-aktiv zu schalten, das hat
aber mit der Funktion der Grundplatine nichts zu tun.
Im Anhang der Schaltplan, so wie er bei mir gespeichert ist, auf dem
zweiten Blatt hat sich nichts geändert. Vielleicht ist ein Unterschied
zu finden?
Gruß. Tom
Hi.
Die beschriebenen Änderungen sind doch bereits im Layout mit drin wie du
schriebst..?
Im Source stand noch was von 9600 Baud. ok ist aber 115200 - verstanden.
Ich habe Basic geflasht.
Zu: ..prüfe das Signal am Pin-ALE..
werde ich machen.
Zu: ..Das schmale RAM hatte ich verkehrt herum eingesetzt und damit das
Foto gemacht..
absolut "tödlich", wenn man das als Referenze heranzieht :-( ;-)
Also: Ram MUSS mit Kerbe (Pin 1) Richtung Resettaster zeigen
(andersherum als die 74er IC's und die 89S52 CPU)
Danke+Gruß,
Peter
Das Programmiergerät ist nun brauchbar, im Anhang der Schaltplan.
Die Software ist noch nicht fertig, aber zum flaschen der µController
der IS51 genügen die vorhandenen Funktionen.
Die Hardware ist jetzt simpel und besteht im wesentlichen aus einem
MAX232. Sie kann leicht auf einem Steckbrett oder einer
Lochrasterplatine nachgebaut werden. Das Programmiergerät ist über den
kleinen Erweiterungsstecker mit der IS51, und über V24-Kabel mit dem PC,
verbunden.
Das V24-Kabel muß ein gekreuztes Nullmodem-Kabel sein, ein
Verbindungsplan ist mit auf dem Schaltplan. Der Verbindungsplan zeigt
die Minimalverbindungen für den selbstbau des Kabels. Ein
handelsübliches Kabel, mit allen Verbindungen, sollte eigentlich auch
funktionieren. Dieses Kabel ist auch zur Verbindung der IS51 mit dem PC
brauchbar, es genügt also ein Kabel zum flashen und im Betrieb der IS51.
Die Software ist unter Windows 7 geschrieben und getestet, ich denke sie
läuft auch auf anderen Versionen. Wäre dankbar für Rückmeldungen. Auch
eine Version für LINUX wäre denkbar.
@Janus: Diese Version des Programmiergerätes wäre kompakt genug, mit auf
die Platine zu kommen. Aber bitte erst als Muster aufbauen und
ausprobieren.
Anhang:
V24Prog.pdf - der Schaltplan des Programmiergerätes mit Kabelplan
V24PgBreak.jpg - ein Foto vom Programmiergerät auf Steckbrett
V24PG.exe - Das PC-Programm für das Programmiergerät
V24Prog.txt - eine Kurzbeschreibung des Programms
Wie man mit dem Bootloader Programme ins RAM downloaded steht im
Handbuch auf Seite 92.
Beitrag "Re: 8051 - Programm und Daten in einem 128kB Chip ohne Overlap"
Auf Seite 93 ist zu finden wie man Programmiergerätesoftware in Keil
µVision integriert. Das funktioniert mit Send und V24PG. Damit ist
sowohl das downloaden von Testprogrammen ins RAM, wie auch das flashen
von Firmware aus µVision heraus möglich.
Habe eben die Funktion des PC-Programms überprüft und dabei
festgestellt, daß ich eine Testversion veröffentlicht habe. Die
Arbeitsversion ist hier im Anhang. Zur Unterscheidung meldet sie sich
mit Version 1.1a anstatt V1.1 der Testversion.
An einem USB-RS232 Adapter funktioniert der Programmer auch, aber die
Software läuft um ein vielfaches langsamer als an einer echten
RS232-Schnittstelle.
TomA schrieb:> Wenn du ein Oszilloskop oder einen Frequenzzähler hast, prüfe das Signal> am Pin-ALE, wenn der Prozessor läuft ist dort die Quarzfrequenz geteilt> durch 6 (2,457MHz) zu messen. Zur Not tut es auch ein Voltmeter, das> Impuls-Pausenverhältnis des Signals ergibt ca. Versorgungsspannung / 3 -> Bei 5V Versorgung damit ca. 1,6V. Wenn ALE vorhanden ist, ist sicher daß> die CPU läuft.
Hi. Da schwingt offensichtlich nichts.. Multitool zeigt als Frequenz
nichts an. Multimeter zeigt High (4,9V) an.
??
Habe Quarz 14,7456 MHz mit 2x 22pf Kondensator dran.
Peter
Hallo Peter,
welchen µC verwendest du? Beim AT89S8253 entfallen die beiden 22pF
Kondensatoren.
Sonst kann es noch sein, daß der µC unter Reset steht. Die 51er haben
High-aktiven Reset, High-Pegel am Reset-Eingang blockiert den µC, zum
arbeiten braucht er Low an Reset. Beim DIL40 Gehäuse ist Pin 9 Reset.
Gruß. Tom
Hi.
Den 89S52.
Inzwischen habe ich eine Einschaltmeldung! An AEL liegen 1,67V an und
mein
Frequenz-Schätzeisen sagt etwas von 2,55MHz..?
R4 musste noch bestückt werden und der Tipp mit Reset nach +5V war auch
goldrichtig.. denn.. oh Schreck, OSHPark hat die Platine falsch
gefertigt!
Anstatt SMD auf der Unterseite haben sie Ausfräsungen hergestellt!?
Siehe die Bilder..
Ich habe das geflickt unter dem Resettaster. C4 + R1 bestückt. R5 als
Brücke (lag in der Ausfräsung; kann ich falls nötig noch gegen 330 Ohm
ersetzen die Brücke).
Nun liegt GND über 10k R1 an Reset Pin 9 und wenn Taster betätigt wird,
liegen +5V an. Reset funktioniert auch.
Bekomme nun zwar eine Einschaltmeldung mit Basic... und nach Return auch
'>' Prompt, aber wenn ich einen anderen Buchstaben (z.B. p für print)
eingebe, erscheint der Buchstabe und das System hängt sich auf..?
Bei nur Return sieht man das ein Zeichen vom Terminal gesendet und 2-3
Zeichen vom IS51 zurückkommen (>+CR+LF?). Bei 'p' geht auch ein Zeichen
raus aber der Rückkanal leuchtet danach dauernd - als wenn das Zeichen
und nur CR/Backspace ständig gesendet werden..?
Peter
Hallo Peter,
die Platinen sehen gut aus!
Glückwunsch, ich denke du hast bereits gewonnen. Bei mir verhält sich
das Basic genauso, es will nach jedem Kommando ein "CR" Zeichen haben.
Wenn ich das vergesse, sendet das Basic pausenlos irgendwelchen Unsinn
zum PC und kann nur durch Reset wieder beruhigt werden.
Ich umgehe das, indem ich das Terminalprogramm so einstelle, daß es an
jede Übertragung zum Basic ein CR anhängt, so wie es im Link, im unteren
roten Kringel, zu sehen ist.
Beitrag "Re: Layout für MCS51 Experimentierboard"
Das müßte dein Übertragungsprogramm auch machen, dann läuft das Basic
richtig.
Zur Kontrolle kannst du mal den Bootloader flashen, der sendet auch eine
Bereitschaftsmeldung und hängt sich danach nicht auf.
An ALE steht die Quarzfrequenz geteilt durch sechs an, wenn nicht gerade
auf den externen Datenspeicher zugegriffen wird. Die 14,7456Mhz
Quarzfrequenz werden damit zu 2,4576MHz an ALE, da liegt dein
Frequenzschätzer gar nicht so daneben :)
Weiter viel Erfolg und Spaß. Tom
Hi. Mit Hterm geht das so wie beschrieben.
Weisst du wie man damit ein ASCII (Basicprogramm) übertragen kann?
Sendfile macht irgendwelche komischen Sachen mit Repetition etc. pp??
Nur 'Normal'/Standard ist das sicher nicht, das man CR hinter jedem
Zeichen senden muss..? Ich hatte mal die Elektorplatinen.. da kann ich
mich nicht dran errinnern.. und bei dem PS3-DC Umbau ist das auch nicht
der Fall..
Na dann mache ich mich mal an den Umbau der Platine, wo noch das SRam
falsch herum eingelötet ist :-(
Peter
Hallo Peter,
bin kein Basic-Profi, muß mal ausprobieren eine Datei zum Basic zu
senden. In hterm gibt es doch eine Möglichkeit eine Datei zu senden.
Neben "Send on Enter" ist ein Knopf mit "Send file" das werde ich bei
Gelegenheit testen.
Soweit ich mich erinnere, ist der Eingabepuffer von Basic 70 Byte groß.
Eventuell muß man die Datei in Portionen kleiner 70 Byte übertragen.
Zeile für Zeile mit Pause dazwischen?
Ob das Verhalten mit dem fehlenden CR mit meinem umschreiben des Basic
auf den Eingabepuffer zu tun hat? Vielleicht sollte ich bei
Eingabetimeout automatisch ein CR an die Eingabe anhängen?
Hier die Rückmeldung von OSHPark (Platinenfertiger):
1
Hi Peter,
2
Oh man, that's gnarly, but it's actually fabricated as we would expect
3
from the input. There's a sneaky footprint issue on those three SMD
4
resistors which causes this. Those three resistors have a small outline on
5
the Milling layer. Since the Milling layer is used to indicate slots and
6
cutouts, we sent it to the fab, and they dutifully cut those sections of
7
the board out. Due to the fact that Eagle doesn't actually enable this
8
layer by default, it's pretty easy to miss on your end even if you know
9
about it. :(
10
11
12
The solution on this is to modify that footprint, and remove the outline,
13
or push it to a different layer. Likely the best layer for that is
14
tKeepOut. Eagle uses that layer as a physical part boundary, and will
15
throw DRC warnings if you overlap them from different components. You
16
might also just put it on tPlace if you simply want some silkscreen for
17
it.
Da soll also eine Umrandung im Milling Layer drin sein bei den 3 SMD
Widerständen, die dazu geführt haben, das da Ausfräsungen sind, wo
eigentlich keine hingehören..?
@Tom: Kannst du das Eagle BRD bitte mal dahingehend prüfen und ggf.
bereinigen?
Meine 2te Platine läuft nun auch..
Als nächsten werde ich das Eeprom 28C256 bestücken (dazu muss noch eine
weitere Brücke für +5V an Pin 28 dran - JP2).
Ich denke das mit dem extra CR muss noch abgestellt werden, sonst kann
das mit dem Programmupload in Basic nicht funktionieren..
Peter
Hallo Peter,
habe meine Eagle-Bibliothek mit dem SMD-Widerstand überprüft, der hatte
tatsächlich ein Rechteck mit abgerundeten Ecken auf dem Milling-Layer.
Damit gab es noch nie Probleme, hatte erst kürzlich Platinen damit
machen lassen. Vermutlich benutzt der deutsche Platinenfertiger den
Milling-Layer nicht. Wie dem auch sei, habe das Rechteck jetzt entfernt
- danke für den Hinweis.
Bei mir funktionierte das EEPROM auf Anhieb. Habe aber etwas anderes
herausgefunden. Im IntelHex-File des Basic gibt es ein Problem, da
überlagern sich Speicherbereiche und kein Programm bemerkt den Fehler.
Weder der Keil-Compiler, noch die Software zum GALEP-Programmer melden
einen Fehler. Dabei ist die Überlappung ganz offensichtlich. Der
Speicherbereich ab 1F78h ist doppelt vorhanden. Habe das im Bild
markiert.
Die Frage ist nun wie den Fehler beheben? Die gepufferte Eingabe
zurücknehmen? - dann muß auch die Baudrate wieder auf eine Kleinere
zurückgestellt werden!
Den Quellcode nach überflüssigen Code durchsuchen? - sehr aufwändig und
vermutlich gibt es da nicht mehr viel Überflüssiges.
Oder einen Chip mit mehr Speicher verwenden? - dann muß einiges am Basic
umgeschrieben werden!
So wie es jetzt ist, wird ein Teil des Basic nicht funktionieren.
Übrigens habe ich inzwischen eine Platine für das Programmiergerät
gemacht. Sie funktioniert schlechter als der fliegende Drahtverhau. Ein
kleiner Kondensator direkt an der Versorgung des MAX202 (ähnlich MAX232
aber 100nF Kondensatoren) hat etwas Besserung gebracht, aber das
Steckbrett funktioniert noch immer besser.
Gruß. Tom
Hi Tom.
Kannst du bitte die korrigierten Eagle-Dateien hier einhängen?
(Auch wenn später mal ein Gesamtpaket kommt).
Ich würde den Input-Buffer rausnehmen und die Baudrate auch wieder
runternehmen. 9600 Baud sollte ok sein. 19200/38400 auch gut.
Beim Programmdownload muss normalerweise sowieso ein Wait nach jedem
Zeichen und am Ende der Zeile rein..
Evtl. spart das auch wieder etwas Platz um die fehlerhafte
Doppelbelegung wegzubekommen?
Evtl. kann man das EEprom schreiben noch etwas 'sicherher' machen..?
Ich werder auch mal messen, ob da nicht doch noch durch die Ausfräsungen
um TR2 herum eine Leitung unterbrochen ist, die das Ram nicht braucht,
aber das EEprom..?
Ich will die Tage sowieso mal den 1.31 Standard Source assemblieren für
IS51 und sehen wie das läuft mit Bauderkennung (9600) und dem EEprom
schreiben..
Schönen Sonntag + Nikolaus.
Peter
TomA schrieb:> Ob das Verhalten mit dem fehlenden CR mit meinem umschreiben des Basic> auf den Eingabepuffer zu tun hat? Vielleicht sollte ich bei> Eingabetimeout automatisch ein CR an die Eingabe anhängen?
Im Original der Version 1.3 des Intel Basic ist das alles nicht nötig -
HTerm ist aber zur Kommunikation mit Intel Basic sowieso schlecht, ein
normales Terminal wie Putty ist da wesentlich einfacher zu handhaben.
Für die PS3 musste ich ja auf Halbduplex umbauen, und ich nehme putty
mit lokalem Echo und das klappt zuverlässig und jedesmal. Ein CR ist
hier nur nötig, um das Kommando entweder abzufahren oder die Zeile in
den Speicher zu kloppen.
Die Autobaudrate erwartet normalerweise ein SPC als erstes Zeichen, ob
die Routine allerdings nach all dem Rumgefummele an MC Erkennung und
-Unterstützung, den die Jungs eingebaut haben, noch funktioniert, kann
ich nicht sagen, weil ich die Routine rausgeschmissen habe.
Hallo Peter.
habe mir das Basic noch einmal vorgenommen. Die Überlappung konnte ich
durch entfernen von überflüssigen Code (LCALL zu ACALL) beseitigen. Die
jetztige Version 1.3 im Anhang.
Das downloaden von Dateien zum Basic ist nicht so einfach zu
bewerkstelligen. Dafür gab es also früher dieses Terminalprogramm. Im
Handbuch des Basic ist auf S.190 das dazu zu finden.
MCS BASIC-52 is actually capable of accepting characters at 38,400 baud.
The problem is that after MCS BASIC-52 receives a carriage return (cr),
it tokenizes the line of text that was just entered. Depending on how
complicated and how long the line is, MCS BASIC-52 can take up to a
couple of hundred milliseconds to tokenize the line. If the user keeps
stuffing characters into the serial port while MCS BASIC-52 is
tokenizing the line, the characters will be lost. What the user must do
in the download routine is wait until MCS BASIC-52 responds with the
prompt character (>) after a carriage return is sent to the MCS BASIC-52
device. The prompt (>) informs the user that MCS BASIC-52 is ready to
receive characters from the console device.
Nach jeder übertragenen Zeile, welche mit "cr" abgeschlossen ist,
beginnt der Interpreter sie auszuwerten. Das dauert mehrere hundert
Millisekunden. Erst wenn der Interpreter fertig ist, sendet er sein
Eingabepromt ">" zurück und ist wieder bereit eine neue Zeile entgegen
zu nehmen. In dieser Wartezeit ist die Übertragung vom PC schon viel
weiter oder sogar schon abgeschlossen.
Man braucht also eine Übertragung, die nach jeder Zeile wartet bis das
Promt ">" kommt, bevor eine neue Zeile gesendet wird. Das ist nicht
weltbewegend und ein kleines Programm dafür ist schnell geschrieben.
Werde mich die nächsten Tage darum kümmern. Das vorgesehene
Terminalprogramm kann mit der hohen Baudrate nicht arbeiten. Wenn ich
die Quellen hätte, könnte ich versuchen das umzuschreiben.
Die ursprüngliche 1.3 Basicversion hat einen Fehler, sie wollte bei mir
nicht laufen. Wenn man allerdings die Baudrate auf eine feste einstellt,
dann sollte sie gehen. Die hohe Baudrate ist eigentlich dem Bootloader
geschuldet, damit wird das Hardwaredebugging unter Keil-ISD51
beschleunigt.
Werde demnächst die aktualisierten Eagle Dateien einstellen. Wenn das
Programmiergerät fertig ist, werde ich eine Beschreibung für alles
machen und und das Komplettpaket schnüren. Danach soll es noch ein
Softwarepaket geben, das dem Einsteiger den Weg ebnet.
Habe mein EEPROM (ATMEL AT28C256-200C) nochmal getestet. Ich stecke nur
den Jumper JP1 von Batterie auf VCC um, und schon geht es. Ich tausche
also nur das RAM gegen das EEPROM aus. Kann dann mit "Prog" Programme
speichern, aus/einschalten, mit "rom" ins EEPROM wechseln und das
Programm mit "run" starten, mit "xfer" das Programm ins RAM verschieben
und es im RAM mit "run" starten. Im Basic mußte ich dafür nichts ändern.
Danke, dir auch einen schönen Nikolaustag. Tom
P.S. Um nicht jedes Programm immer neu eintippen zu müssen, kopiere ich
es zeilenweise aus dem Editor (Zeile markieren dann Strg-c) in die
Eingabezeile von "hterm" (Strg-v). Ist immer noch umständlich, aber
wesentlich bequemer als ganz neu eintippen :)
Hallo Matthias,
ich kenne Putty nicht, aber wenn das mit dem Basic sauber
zusammenarbeitet wäre diese Schlacht doch geschlagen. Danke für den
Hinweis.
Ich erinnere mich, daß sich das Original 1.3 Basic bei mir totgestellt
hatte bis die Baudratenerkennung durch die Festeinstellung ersetzt war.
Habe jetzt die gepufferte Eingaberoutine umgeschrieben, daß sie das "cr"
nach Timeout automatisch anhängt.
Bleibt zu überlegen, das Originalbasic auf IS51 lauffähig zu machen, um
die Unterschiede zum umgeschriebenen Basic zu sehen?
Schönen Nikolaustag und Gruß. Tom
Hi. Werde die neue Hex mal testen. Ist immer noch 115200 Baud?
Ich habe ja keine Batt. dran. Nur +5V und liegt an Pin 28 an.
Das mit dem Download hatte ich einfach gelöst mit kleinem Wait nach
jedem Zeichen (10ms) und großem Wait (500ms) am Ende der Zeile (damit
der Tokenizer seine Arbeit machen kann..). Dafür nutze ich bisher
Teraterm.
Nur ein CR an jedes Zeichen anhängen kann Teraterm nicht (ist auch eine
eher unübliche Anforderung). Mit reicht 9600 Baud. 19200 natürlich auch
ok..
Auf Prompt warten ist sicher eine bessere Lösung.
Genau das EEprom sollte/muss aber funktionieren. :-(
Peter
Habe jetzt das mir vorliegende original Basic 1.31 assembliert
(mit der Freeware MC-51 IDE + Freeware ASEM Assemnbler)
Link:
http://www.ieap.uni-kiel.de/surface/ag-berndt/lehre/fpmc/index-e.html
Hatte nur XTALV angepasst auf die Quarzfrequenz von 14,7456 MHz in Zeile
5813:
XTALV: DB 128+8 ; DEFAULT CRYSTAL VALUE
DB 00H
DB 00H
DB 56H
DB 74H
DB 14H
Läuft im IS51 Board mit Bauderkennung+9600 Baud.
EEprom geht aber auch damit nicht bei mir.. evtl. doch noch HW
Problem..?
Hier braucht es kein CR hinter jedem Zeichen. Programm Download geht
also.
10ms pro Zeichen und 500ms pro Zeile Verzögerung in Teraterm
eingestellt.
Hänge Source+HEX hier mal als ZIP dran.
Peter
Hallo Peter,
ich habe genau das gleiche gemacht. In der original 1.32 Version den
Quarz angepaßt und ausprobiert - läuft gut mit hterm, aber auch mit dem
MCS51-Terminal. Damit kann man auch gespeicherte Dateien von Festplatte
zum Basic übertragen :) Leider geht das aber nicht besonders schnell,
die maximale Baudrate ist 9600.
Bei herunspielen mit dem EEPROM hat sich bei mir auch etwas verstellt,
plötzlich kamen bei Zugriffen ständig Fehlermeldungen. Das löschen des
EEPROM mit "ERASE" hat das Problem wieder beseitigt. Wenn also an
bestimmten Stellen im EEPROM etwas falsches steht dann klemmt es.
Vielleicht genügt bei dir auch ein einfaches löschen des EEPROM.
Ich werde versuchen, das IS51Basic auch wieder auf automatische
Baudratenerkennung zurück zu stellen, dann kann man die Baudrate wieder
umstellen. Mal sehen ob das noch in den Speicher paßt.
Das originale Basic sendet ein "cr" nur bei betätigen der ENTER-Taste.
Das ist auch sinnvoll, denn es puffert die Eingabezeichen nicht. Jedes
eingegebene Zeichen wird sofort zum Basic geschickt, da würde ein
automatisches CR alles durcheinanderbringen. Damit sind aber dann keine
Baudraten über 38400 möglich. Das zwischenpuffern und abschließend ein
cr anfügen erlaubt deutlich höhere Baudraten.
Habe beim Programmiergerät jetzt noch eine Drossel in die
Versorgungsleitung gelegt und nun funktioniert es wie gewünscht. Muß
jetzt noch die Software vervollständigen.
Gruß. Tom
Hallo Peter,
das löschen ist recht langsam. Das dauert für die 16K schon, wie im
Handbuch beschrieben, 2 Minuten und 45 Sekunden. Mit 32k dauert es dann
5 1/2 Minuten :(
Aber das von dir gepostete Listing bringt mich auf eine Idee. Laut
Datenblatt kann das EEPROM auch im Page-Mode programmiert werden, dabei
sind bis zu 64 Byte in einem Schreibzyklus machbar. Da sehe ich
dieMöglichkeit das löschen, vielleicht auch das schreiben, deutlich zu
beschleunigen und vielleicht dabei noch ein paar Codebytes zu sparen. :)
Das war eine gute Idee, danke dir. Werde es mir jetzt genauer ansehen.
Gruß. Tom
Sehr gerne.
Bin inzwischen ein wenig weiter.. das PROG geht jetzt, nachdem ich den
AT28C256 im externen Programmer mit 0xFF gefüllt hatte.
Interessant dabei.. der TL866A macht bei Erase = nichts! Baustein ist
gefüllt wie vorher - bringt aber auch keine Fehlermeldung..?
Hänge hier mal ein EEprom.BIN an und eine txt Datei dazu mit 5 kleinen
Programmen im EEprom gesichert. Programm 2 erzeugt sozusagen das DIR
Listing in der txt Datei.
Peter
Hallo Peter,
ich bin auch etwas weiter gekommen. Wenn ich die Größe des zu löschenden
Bereiches auf 8000h setze wird das EEPROM gelöscht, aber es gibt eine
Fehlermeldung. Zudem dauert es ca. 5 Minuten bis gelöscht ist.
Ich denke es ist besser weniger zu löschen. Warum die Speicherbereiche
löschen, die unbenutzt sind? - Das zieht sich von den Zyklen der
Lebensdauer des EEPROM ab. Die ist mit 100000 zwar großzügig, aber warum
nicht sparsam damit umgehen. Sollte der kleine Bereich irgendwann
verschlissen sein, können unsere Enkel einfach den Speicherblock
umschalten und die Schaltung ihren Kindern vererben. :)
Aber zurück in die Realität. Ich konnte das EEPROM löschen auf
Blockmodus umschreiben (Quellbereich im Anhang). Dadurch läuft es jetzt
64fach schneller. Die 32k dauern nun ca. 5 Sekunden, aber die
Fehlermeldung bleibt. Habe den zu löschenden Speicherbereich auf 8K
reduziert, die sind in ca. 1 Sekunde gelöscht.
Im Moment arbeite ich mit dem eigenen Programmiergerät, das läuft
tadellos, aber etwas langsam. Das sollte ich auch auf Pagemode
umschreiben, dann geht es 256fach schneller, denn der 89S52 arbeitet mit
256Byte Pages. :)
Gruß. Tom
Das Programmiergerät schreibt den AT89S52 jetzt auch im Pagemode.
Dadurch verkürzt sich die Programmierdauer der 8k des Basic von ca. 100
Sekunden auf nicht einmal 10 Sekunden.
Anstatt des MAX202 kann auch ein MAX232 verwendet werden, der braucht
dann aber 10µF Elkos anstelle der 0,1µF Kondensatoren. Die Drosselspule
L1 sollte so nah als möglich an den Stecker ST1, ihr Wert ist unkritisch
10 bis 100µH.
Der Kondensator C6 (100nF) wird so nah als möglich an die
Versorgungspins des MAX2xx gebracht.
Die Schaltung ist einfach und kann schnell auf einem Steckbrett oder
einer Lochrasterplatine aufgebaut werden.
Die zugehörige Software "V24PG.EXE" kann auch in die Programmierumgebung
(z.B: Keil) integriert werden.
Gruß. Tom
@Tom: Könntest du mir bitte die korrigierte Eagle BRD Datei zur
Verfügung stellen? Der Platinenfertiger OSHPark hat sich bereit erklärt
die Platinen aus Kulanz nochmals anfertigen zulassen, obwohl der Fehler
ja nicht bei ihm lag.
Danke+Gruß, Peter
Hallo Peter,
hier die Version mit geänderten Widerständen. Sorry für die Umstände,
aber mir war das nie aufgefallen.
Das EEPROM scheint beim Ein/Ausschalten keine Probleme mit Datenverlust
zu haben. Ich arbeite im Moment mit einem AT89S52 dem im EEPROM
gespeicherten Zählerprogramm (Zählstand mit LED's anzeigen. Das blinkt
lustig vor sich hin, egal wie oft ich aus- und wieder einschalte.
Beim RAM kann man, um sicher zu sein keine Daten zu verlieren, während
des schaltens den RESET-Taster gedrückt halten.
Gruß. Tom
Kein Ding. War mir ja auch nicht aufgefallen und leider der Preview auch
nicht..
Aber sicher, das ich das jetzt so zum Fertiger schicken soll?
JP3 ist da jetzt neu drin, den es nicht im Schaltplan (bei mir) gibt..?
Und so eine GND wire, die so ganz alleine steht - siehe Bild und
violetter Pfeil..
Ideal wäre jetzt nicht unbedingt eine neue Version (es sein denn sie ist
100% kompatibel), sondern eher die orig. Version - nur ohne Milling
Outline and den 3 SMD Widerständen.
Wenn du aber sagts.. alles ok, ab zum Fertiger, mache ich das..
EDIT: Habe jetzt aus der 'alten' BRD die 3 SMD Widerstände gegen welche
aus der Eagle Standard resistor lib SMD 1206 ersetzt. Jetzt sollte/ist
der Milling Layer weg. Ich denke ich werde das zum Fertiger senden..
Peter
Peter S. schrieb:> Und so eine GND wire, die so ganz alleine steht - siehe Bild und> violetter Pfeil..
Vielleicht eine "Hilfe" damit das Ground-Polygon da durchliesst ?
Weil es wegen der eingestellten Isolationsabstaende vieleicht
nicht machen wuerde.
Das faellt mir ein, weil ich sowas schon mal gemacht habe.
Gruss Asko.
Hallo Asko,
genau deshalb!
@Peter: Am besten schickst du dein geändertes Layout zum
Platinenhersteller, denn ich weiß im Moment nicht was ich ausser der
Lötbrücke noch geändert habe.
@All: Sorry, war eine Zeit nicht hier, habe aber in dieser Zeit begonnen
ein kleines Terminal für das Basic zu schreiben. Ist noch nicht fertig,
aber die Hauptfunktionen (Download von Basicprogrammen zur IS51 und
diese starten) funktionieren schon.
Wie funktioniert es? Windows-PC über RS232 mit IS51 verbinden. IS51
rücksetzen. Terminal starten, Baudrate und Schnittstelle wählen, dann
"Initialisieren" drücken. Wenn es funktioniert hat erscheint der
Basic-Meldetext im Textfenster des Terminal. Wenn es nicht funktioniert
hat, IS51 nochmal rücksetzen und "Initialisieren". Dabei wird einfach
der "Spacecode 20H" zur automatischen Baudratenkennung zum Basic
gesendet.
Um ein Programm zur IS51 zu schicken, die Datei "Laden" und zur bereiten
IS51 senden ("Datei senden").
Weitere Funktionen erkennt man an der Beschriftung der Knöpfe.
Es funktioniert bei mir, auch mit dem Originalbasic mit bis zu
115200Baud, da kann ich mir den Eingabepuffer im Basic sparen.
Das Ausgabefenster ist noch kein Editor, es dient lediglich der Anzeige.
Programme werden mit einem beliebigen Editor geschrieben und mit dem
Terminal nur zur IS51 übertragen.
Leider funktioniert das automatische scrollen des Anzeigefensters noch
nicht :( Vielleicht weiß jemand wie man das macht (VC++8, RichTextBox)?
Viel Erfolg und Spaß. Tom
Hi Tom,
> Leider funktioniert das automatische scrollen des Anzeigefensters noch> nicht :( Vielleicht weiß jemand wie man das macht (VC++8, RichTextBox)?>
Soweit ich mich erinnere muss HideSelection der Box auf False gesetzt
werden und mit AppendText der Text hinzugefügt werden. Dann scrollt die
Box auch wenn der Focus nicht mehr auf der Box liegt.
Lg Sven
Hallo Sven,
habe das Problem inzwischen mit "ScrollToCaret()" gelöst. Sollte sich
zeigen daß das nicht wie gewollt funktioniert, greife ich gerne deinen
Vorschlag auf.
Vielen Dank und Gruß. Tom
P.S. Habe aus meinem Basic jetzt den reingeflickten Eingabepuffer wieder
entfernt. Mit dem Basic-Terminal oder hterm läuft es auch so mit
115200Baud.
Das Terminalprogramm ist nun soweit fertig. Es hat jetzt einen einfachen
Zeileneditor (Die aktuelle Zeile im Anzeigefenster. Zum aktivieren mit
der Maus anklicken) und sechs frei definierbare Userbutton. Der Text
wird durch drücken der Eingabetaste zur IS51 gesendet.
Die definierbaren Userbutton sind unten im linken Buttonfeld und gelb
hinterlegt. Im Menüitem "Einstellungen" (Bild: BasicTerm3) können sie
einzeln ausgewählt werden.
Die Einstellungmöglichkeiten zeigt Bild: BasicTerm4. "Titel" ist der
Beschriftungstext des Button. "Funktion" ist der Text, welcher bei
betätigen zum Basic gesendet wird. "Tip" ist der Hilfstext, der beim
berühren des Button mit der Maus gezeigt wird.
Es werden noch nicht alle Fehler abgefangen, aber das Terminal ist schon
brauchbar. Das Terminal ist zum "fersteuern" des Basic gedacht, größere
Programme schreibt man besser mit einem Texteditor.
Gruß. Tom
Hier noch das Terminalprogramm. Übrigens wird es jetzt über ein
Configfile initialisiert. Das heißt es speichert seine Einstellungen und
startet mit diesen beim nächsten mal.
Hmm.. musste ja einen Grund haben, warum es so klein ist..
depend zeigt MSCOREE.DLL an als fehlend = .NET Framework.
Kann man das 'static' mit nötigen Libs binden?
Peter
Hallo Peter,
muß mir das mal ansehen, hatte mich auch schon über die schmale Größe
gewundert. Habe in der Werkstatt noch einen PC stehen, auf dem das VC++
nicht installiert ist, dort könnte ich testen ob das Terminal läuft.
Inzwischen ist eine erste Version des Handbuch zum Terminalprogramm
fertig, da sollte dann das Programm dazu auch funktionieren :)
Gruß. Tom
Das Problem ist größer als gedacht. Auf meinem Werkstattrechner läuft es
auch nicht. Obwohl darauf .NET ist und ich extra vcredist_x86
installiert habe. Er bringt eine Fehlermeldung, aber die blitzt nur kurz
auf und ist nicht zu lesen.
Habe nach dem Fehler gegoogelt, aber alle Lösungsvorschläge schlugen
fehl :(
Statisches Einbinden der Dll's bringt VC++ zum heulen. Ich kriege das
Terminalprogramm nur auf dem PC zu laufen, auf dem es geschrieben wurde?
Werde weiter versuchen das Problem zu lösen.
Das Problem mit dem Terminalprogramm ist beinahe gelöst. Bevor ich
Stunden/Tage damit vergeude eine Lösung zu basteln, und jeder Anwender
danach auch basteln muß, habe ich das Terminal einfach in VC# neu
geschrieben. Es läuft auf meinem Werkstattrechner völlig Problemlos.
Bis auf die Config-Datei und die definierbaren UserButton geht Alles
schon wieder. :)
Nun funktioniert auch das Config-File, wodurch die getroffenen
Einstellungen gespeichert und wieder hergestellt werden. Einzig die
"UserButton" werden noch nicht bedient. Das ist aber nicht schlimm, denn
man kann alle Befehle auch mit der Tastatur eingeben.
Das neu Programm paßt nun nicht mehr zur Beschreibung, diese werde ich
später noch anpassen. Hier mal das neue Terminal in seiner VC#-Version,
zum ausprobieren ob es jetzt läuft. Dazu die Config-Datei, sie muß im
gleichen Verzeichnis wie das Terminal liegen.
Gruß. Tom
Hallo Peter,
bei mir zickt es, seit das Config-File wieder integriert ist, auch. Habe
jetzt ein Setup-Paket erzeugt, das läßt sich auf meinem Werkstatt-PC
installieren und läuft. Das Ganze ist zusammen mit dem dazu passenden
Handbuch und dem Handbuch des Basic in der ZIP-Datei.
Aufruf von Setup.exe installiert das Terminal. Es läßt sich über die
Systemsteuerung - Software problemlos wieder deinstallieren. Bin
gespannt ob das jetzt bei dir auch funktioniert?
Das Terminal ist jetzt fertig, auch die UserButton sind wieder aktiv und
das Handbuch ist angepasst.
Gruß. Tom
Hmm. Hatte ich erwähnt, das ich noch WinXP nutze..?
Läuft nicht nach Install - gleiche Fehlermeldung..
(Ist für mich auch nicht soo wichtig.. komme gut mit Teraterm zurecht).
Peter
Hallo Peter,
eigentlich sollte es unter WinXP auch funktionieren, ich kann das leider
nicht prüfen, habe nur Win7. Was das Terminal braucht ist NET und eine
RS232-Schnittstelle.
Nachdem ich das Paket einmal installiert hatte, genügt es jetzt die EXE
zu aufzurufen. Kann, nach Programmäderungen, das Terminal sogar vom
USB-Stick auf dem Werkstattrechner starten.
Auf dem Werkstattrechner ist nur NET 4.0 installiert, das Terminal wurde
für NET 2.0 geschrieben.
Habe es inzwischen auch an einem Laptop ohne RS232 ausprobiert. Da
bricht das Terminal mit der Fehlermeldung "Programm funktioniert nicht
mehr" ab. Stecke ich einen USP-RS232 Adapter an, funktioniert es wieder.
Ich denke auf einem PC mit installierten MSVC# sollte die EXE alleine
lauffähig sein. Auf anderen PC's nach Installation des Terminal-Paketes,
das die passende Umgebung, unter NET, für das Terminal einrichtet?
Habe keine Ahnung, Warum es bei dir nicht geht. Vielleicht kommt noch
eine Rückmeldung von jemand der weiß wie das Problem zu lösen ist?
Gruß. Tom
Hallo Peter,
ich hatte jetzt die Gelegenheit das Terminal mit WinXP zu testen. Es
lief reibungslos, sogar die VC++-Version. Auf dem PC waren die
Netversionen 2.0, 3.0, 3.5 und 4.0 installiert, aber keine
MSVisual-Entwicklungsumgebung.
Meine Probleme mit der Fehlermeldung "Programm funktioniert nicht mehr"
sind gelöst, es lag am Zugriff zur RS232-Schnittstelle.
Habe noch ein paar kleine Fehler am Terminalprogramm beseitigt, es läuft
nun zufriedenstellend. Werde es im 8051-Bereich veröffentlichen, damit
es auch Leute finden, die diesen Thread nicht verfolgen.
Gruß. Tom
Das Terminalprogramm wurde in den Bereich "PC-Programmierung"
verschoben:
Beitrag "Terminal für INTEL-MCS51-Basic"
Da gehört es eigentlich auch hin, ist es doch ein Windows-Programm.
Abschließend hier noch das aktuelle IS51-Basic als Assembler-Quelldatei
und Hex-Datei für den Programmer.
Werde mich nun um ein kleines Handbuch für den einfachen IS-Programmer
kümmern und dann fehlen auch noch die Handbücher für die Platine und vor
allem für den Bootloader.
Gruß. Tom
Heute sind die geänderten Platinen gekommen und sehen gut aus.
Die Ausfräsungen an den 2 SMD Widerständen sind verschwunden.
Geänderte Eagle Dateien anbei.
Die 3 Platinen + prog. AT89S52 sind unter Rubrik: Markt zu haben.
Peter
Ich weiß.. ist schon ein Weilchen her.. habe nun aber zum ersten Mal
eine Version mit RS232 hier (sonst USB-TTL Wandler) und dabei
festgestellt, das aus meiner Sicht Rx und Tx an der Buchse vertauscht
werden sollten, damit es dem 'Standard' entspricht.
Nun ich habe mal NUR das PCB entsprechend geändert (Nur Rx+Tx=Pin 2+3
getauscht an der Buchse). Ist so NICHT getestet!!
Inkl. Gerber für Elecrow/JLCPCB) - siehe auch Ausschnitt Bild.
Ohne jede Gewähr!
Hier gibt es noch eine schönes ANSI/VT100 Mandelbrotprogramm dafür:
http://www.dusko-lolic.from.hr/i8052fract/
Und ein Arecibo Message Generator hänge ich hier auch mal an.. evtl.
möchte ja mal ein Hobbyfunker eine solche ins All abstrahlen ;-)
(Port1.0 wird je nach Bit in der Message geschaltet)
Die Message selbst wird hier sehr schön erläutert:
http://www.signale.de/arecibo/gesamt.html
;-)
Peter
Peter S. schrieb:> Inkl. Gerber für Elecrow/JLCPCB) - siehe auch Ausschnitt Bild.
Aus Interesse, was ist der Hintergrund für die kurzen Leiterbahn Stücken
an den Pads? Das habe ich bisher nur bei 5mm LEDs gesehen, um die Wärme
los zu werden.
