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:
1 | XTALV: DB 128+8 ; DEFAULT CRYSTAL VALUE |
2 | DB 00H |
3 | DB 00H |
4 | DB 92H |
5 | DB 05H |
6 | DB 11H |
Für dich wäre also
1 | XTALV: DB 128+8 ; DEFAULT CRYSTAL VALUE |
2 | DB 00H |
3 | DB 00H |
4 | DB 00H |
5 | DB 00H |
6 | DB 12H |
richtig.
@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
Hmm. Jetzt bräuchte es nur noch eine Layout Datei, die man so zum Platinenfertiger seines Vertrauens schicken könnte ;-) Peter
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
ok. Viel Erfolg! Werde mir dann sicher eine Platine anfertigen lassen.. Danke+Gruß, Peter
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
Sehr schön. Da steckt eine MENGE Arbeit in den PDF's! Warte noch auf das Eagle Layout, dann werde ich mir eine Platine anfertigen lassen.. Peter
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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
@TomA: Vielen Dank!! Werde mich nun darum kümmern mal eine Platine zu bekommen. Peter
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
Ich meine den "AT89S8253", nicht den "AT89S8252". Obwohl der auch geht, aber er hat nur 8K Speicher und ist bereits abgekündigt. Sorry
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.
Meine Platine(n) zur Hauptplatine ist beim Fertiger. Wird aber noch 2-3 Wochen dauern. Werde dann hier berichten.. Peter
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
...sieht ja richtig super aus. Warte noch auf den Schaltplan :-) Das wäre eine Alternative zu diesen ganzen Arduino Bausätzen.
@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
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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
:
Bearbeitet durch User
Hmm. Nun AT28C256 Eeproms drin.
PROG antwortet
1
Error Programming
>
??
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
:
Bearbeitet durch User
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
Das mit ERASE probiere ich aus. Da scheint es auch noch einen Fehler im Source zu geben. Da sind wohl nur 16kb EEprom vorgesehen.
1 | ;***************************************************************************** |
2 | ;****** The new command "ERASE" to fill a EEPROM with 0FFH ******************* |
3 | ;****** Boehling 3 *********************************************************** |
4 | ; |
5 | CERASE: mov R7,#40H ;Erase 16K byte |
6 | mov R6,#00H |
7 | mov R2,#HIGH ROMADR-1 ;Startaddress EEPROM |
8 | mov R0,#LOW ROMADR-1 |
9 | mov DPTR,#PROGS ;Point to EEPROM timeing |
10 | acall LD_T ;Load the timer |
11 | ; |
12 | ERA1: lcall INC3210 ;Bump pointers |
13 | mov A,#0FFH ;Fill the EEPROM with 0FFH |
14 | acall PG7 ;Write the byte |
15 | jnz PG6 ;Exit if error |
16 | DJNZ R6,ERA1 |
17 | DJNZ R7,ERA1 ;Do the loop |
18 | ajmp C_K ;Exit to command mode |
19 | |
20 | ..müsste also mov R7,#80H oben sein.. |
21 | ..ROMADR steht richtig auf 8000H (32k).. |
22 | |
23 | PG6/7 code: |
24 | PG6: JNB DIRF,PG31 ;EXIT IF IN RUN MODE |
25 | MOV DPTR,#E16X ;PROGRAMMING ERROR |
26 | ERRLK: LJMP ERROR ;PROCESS THE ERROR |
27 | |
28 | PG7: MOV R4,A ;SAVE THE BYTE IN R4 for error detect |
29 | mov dph,r2 ;load data pointer with eeprom address |
30 | mov dpl,r0 |
31 | movx @dptr,a ;write the byte |
32 | DB 07DH ;mov r5,#0 |
33 | ; |
34 | ZRO: NOP |
35 | NOP ;SETTLEING TIME + FP ZERO |
36 | NOP ;Atenttion. This 6 NOP's a not only |
37 | NOP ;for settleing time, it is also the |
38 | NOP ;floating point zero! |
39 | NOP |
40 | MOV TEMP5,#12 ;DELAY 30uS AT 12 MHZ |
41 | DJNZ TEMP5,$ |
42 | ACALL TIMER_LOAD ;START THE TIMER |
43 | JNB TF1,$ ;WAIT FOR PART TO PROGRAM |
44 | movx A,@DPTR ;Read back for error detect |
45 | xrl A,R4 ;Test for error |
46 | jz PG31 |
47 | djnz r5,ZRO |
48 | PG31: RET |
49 | |
50 | ..auch lustig: mov r5,#0 wird als db 07DH abgebildet?.. |
51 | ..und da ist ein delay der sich auf 12MHz bezieht.. sollte bei 14,7456MHz ggf angepasst werden?.. |
Peter
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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
Bas51Terminal läuft leider nicht. .Net 4 kommt muss .Net 2 haben. .Net 2 kommt unerwarteter Fehler... Peter
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
Das Programmiergerät mit Handbuch ist hier Beitrag "Einfaches Programmiergerät für RS232" zu finden.
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.
1 | Standard: |
2 | 9-pol sub-d (5 - GND) Kabel dazwischen PC - 9-pol sub-d (5 - GND) |
3 | Stecker/Male/Männlich/M Buchse-Buchse Stecker/Male/Männlich/M |
4 | 2 - Rx Nullmodem Rx - 2 |
5 | 3 - Tx Rx<->Tx gekreuzt Tx - 3 |
6 | |
7 | 9-pol sub-d (5 - GND) Kabel dazwischen PC - 9-pol sub-d (5 - GND) |
8 | Buchse/Female/Weiblich/F Stecker-Buchse Stecker/Male/Männlich/M |
9 | 2 - Tx 1:1 Verlängerung Rx - 2 |
10 | 3 - Rx Rx<->Tx Nicht gekreuzt Tx - 3 |
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
:
Bearbeitet durch User
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.
Noch ein Tipp: Hier: http://www.jcbrolabs.org/8051-arduino wird beschrieben, wie man die 85S52 per Arduino programmieren kann. Anstatt Steckbrett tut es auch z.B.: https://www.ebay.de/itm/51-MCU-minimum-system-board-STC89C52-AT89S52-development-board/40120316842 Habe ich gerade getestet und funktioniert gut (Prog. Zeit etwas lang..) Peter
Mist. Link geht nicht. Hier ein neuer Versuch: https://www.ebay.de/itm/51-MCU-minimum-system-board-STC89C52-AT89S52-development-board/401203168429?hash=item5d699284ad:g:e8cAAOSw-CpX-ayd Suchen nach '51 MCU minimum system'. Kostet 1€. Peter
Man könnte sich aber auch einen AT89LP51RD2 kaufen und dann per RS-232 mit Flip programmieren. https://www.microchip.com/wwwproducts/en/AT89LP51RD2
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.