Announcement: there is an English version of this forum on Hallo Jörg, vielen Dank für Deine Antwort - so hatte ich es mir auch zurechtgereimt, kann aber immer noch nicht erkennen, weshalb das "alte" Programm nicht auf der 644-Version lief. Nachdem ich die "Datas" und korrespondierend auch "icomm" in den Byte-Bereich gelegt hatte, lief das meißte aber. Mittlerweile funktioniert zum Glück alles und ich freue mich über die neuen grafischen Möglichkeiten und die vervierfachung des Speichers, welche es mir ermöglicht, alle Anzeigen zu realisieren...... Viele Grüsse Otto PS: Die Programme haben eine unterschiedliche Zeilenzahl (1=95, 2=94, 3=92, 4=93) EPOKE kann nicht mit EP abgekürzt werden BORDER ist z. Zt. nicht in der Dokumentation
Guten Abend Herr Wolfram, zu Ihrem kleinen Mega644 Selbstbau- Computer habe ich folgende Fragen: 1. Auf Ihrer HP steht, das nur 95 Programmzeilen erlaubt sind. Ist der Programmcode auf 95 Zeilen begrennzt? Falls ja, kann man nur Miniprogramme erstellen... 2. Kann man ggf. den Speicher für den Programmcode vergrößern? 3. Gibt es bereits ein Softwarearchiv für Ihrem Computer? Mir ist die Basic (Programmier-)Sprache bekannt, allerdings wüsste ich gerne, was andere Besitzer des Computers bereits in den kleinen Speicher (?) hinein gepresst haben... 4. Ist im Shop (https://www.it-wns.de/themes/kategorie/detail.php?artikelid=134&source=2) auch ein passendes Gehäuse vorhanden? 5. Was benötige ich noch, wenn man den im oben genannten Shop gekauften Bausatz fertig gelötet hat, um Ihr OS auf dem Computer zu bringen (Programmerkabel, Softwareumgebung, Hostbetriebssystem) ? Ich denke, das reicht für das erste... Vielen dank für Ihre Antworten in voraus, Ronny
@Otto Freut mich, dass es soweit funktioniert. Allerdings haben bei mir alle Programme 95 Zeilen. EP mache ich wieder mit rein, kein Problem und die Doku ist auch fast fertig wobei ich Sachen wie das API erstmal draussen vor gelassen habe) @Ronny 1.+2. Die Anzahl der Zeilen ist durch das verfügbare RAM begrenzt. Für eine RAM-Erweiterung müsste wahrscheinlich sehr viel am Konzept geändert werden. Der ATMega 128 geht leider nicht, auch wenn man ihn auf 20MHz übertakten würde. Aber mittels GOSUB P,N kann man den Code auch auf mehrere Programme verteilen. 3. Gibt es (leider) nicht, ich hatte sowas schonmal angedacht aber aufgrund des zeitlichen Auwandes zur Pflege des Archives schnell wieder verworfen. 4. Wahrscheinlich nicht. Allerdings habe ich auch nicht direkt etwas damit zu tun. Einfach mal nachfragen... 5. Ein Kabel von 9-polig DIN auf Scart, für die Hexfiles einen funktionierenden Programmer für 10-poligem ISP-Anschluß und ein Steckernetzteil mit ca. 7-9V. Für den Programmaustausch mit dem PC eine serielle Schnittstelle und ein Terminalprogramm, Betriebssystem ist dafür weitestgehend egal. Gruß Jörg
> Autor: Joerg Wolfram > 1.+2. Die Anzahl der Zeilen ist durch das verfügbare RAM begrenzt. Für > eine RAM-Erweiterung müsste wahrscheinlich sehr viel am Konzept geändert > werden. Der ATMega 128 geht leider nicht, auch wenn man ihn auf 20MHz > übertakten würde. Aber mittels GOSUB P,N kann man den Code auch auf > mehrere Programme verteilen. ok, das müsste ich mal mit dem atmel emulator testen... eines der guten alten textadventures, auf dem pc portiert, bracht wohl ein paar codezeilen mehr... > 3. Gibt es (leider) nicht, ich hatte sowas schonmal angedacht aber > aufgrund des zeitlichen Auwandes zur Pflege des Archives schnell wieder > verworfen. du hast aber ein paar codebeispiele online, die beim bauen eigener programme helfen... > 4. Wahrscheinlich nicht. Allerdings habe ich auch nicht direkt etwas > damit zu tun. Einfach mal nachfragen... schon erledigt. antwort sollte auch bald da sein... > 5. Ein Kabel von 9-polig DIN auf Scart, ein serielles kabel nach scart zum programmen...? > für die Hexfiles einen > funktionierenden Programmer für 10-poligem ISP-Anschluß und ein > Steckernetzteil mit ca. 7-9V. Für den Programmaustausch mit dem PC eine > serielle Schnittstelle und ein Terminalprogramm, Betriebssystem ist > dafür weitestgehend egal. so ein programmer kostet mir 20-40€.. mal schauen, welcher am besten geeignet ist. ab betriebssystemen steht mir eigendlich alles, was rang und namen hat, zur verfügung... also, win + linux + mac os + diverse opensource betriebssysteme (tyndur, deskwork, reactos usw...)
nachtrag: würde dieser programmer laufen? -> http://cgi.ebay.de/USB-ISP-Programmer-fuer-ATMEL-AVR-ATmega-ATTiny_W0QQitemZ390043966886QQcmdZViewItemQQptZBauteile?hash=item390043966886&_trksid=p3286.c0.m14&_trkparms=72%3A1229|66%3A2|65%3A12|39%3A1|240%3A1318|301%3A1|293%3A1|294%3A50
Hallo Ronny, das Kabel von 9-polig D-Sub auf Scart ist für den Fernseher-Anschluß und hat nix mit dem Programmieren zu tun. Der von Dir verlinkte Programmer sollte aber funktionieren. Code-Beispiele habe ich auf der Homepage, die sind aber auch in der Doku mit drin. So einen Step-by-step Kurs hatte ich schonmal angefangen, aber erstmal auf Eis gelegt. Für ein Text-Adventure wäre es vielleicht sinnvoller, die Daten zu den einzelnen Orten in einer extra Datei auf dem Dataflash zu halten und nur im BASIC auszuwerten. Gruß Jörg
So, lange genug hat es ja gedauert, aber jetzt ist die Version 1.00 endlich fertig. Die Dokumentation ist aber leider noch nicht vollständig, die API-Funktionen sind noch nicht vollständig beschrieben. Neue Features wird es wohl nicht mehr geben, dazu ist einfach der Flash zu voll. Was gibt es neues? Zuerst einmal, mit 4 (bei RGB reichen auch 3) Widerständen lässt sich der Computer auf 16 Farben "aufrüsten". Dafür ist der Autostart-Jumper einer "intelligenteren" Lösung gewichen. Dann noch 8 Videomodi, davon 2 mit benutzerdefinierten Zeichen. Bei Videomodus 1 kann für jeweils 8x8 Pixel Vorder- und Hintergrundfarbe festgelegt werden. Unterstützung für Binärprogramme (bis 3KBytes), diese können auch Routinen enthalten, die vom BASIC aufrufbar sind. Dateitransfer vom Hauptmenü aus über X-Modem, REPEAT-UNTIL Schleifen, Lautstärkesteuerung... Die Doku habe ich auch erweitert, allerdings sind die Beispielbilder aus der BASIC-Referenz rausgeflogen. Dafür wird es wahrscheinlich demnächst eine Art kleinen "Programmierkurs" geben. Viel Spaß damit, wer Fehler findet, bitte melden. Gruß Jörg
Hallo Jörg, vielen Dank für die neue Version - leider habe ich es jetzt erst gesehen. Auf jeden Fall werde ich heute mit Spannung die Dokumentation lesen. Aber so weis ich auf jeden Fall, was ich am nächsten Wochenende tue.... Viele Grüsse Otto
Ein Update nimmt schon langsam Gestalt an, auch werde ich entgegen meiner Ankündigung noch neue Features einbauen. Leider ist das Feedback derzeit praktisch Null, ein paar Bugfixes werden aber auch dabei sein. Was mich in letzter Zeit geärgert hat, ist die starre Abhängigkeit von den Zeilennummern. Jedesmal wenn man eine Zeile einfügt oder löscht passen die Ganzen GOTO und GOSUB Werte zur Hälfte nicht mehr. Die nächste Version enthält dafür zwei neue Befehle VSET und ASET, mit denen die aktuelle Zeilennummer in eine Variable oder ein Array-Element geschrieben werden kann. Der Programmtext:
1 | ASET 300: GOTO AR(300) |
wird damit in jeder beliebigen Zeile eine Endlosschleife erzeugen. Das API wird auch noch ein bisschen erweitert und die Konfigurationsseite werde ich etwas aufräumen (Auswahl per Cursor-Tasten). Veröffentlichungstermin wird am WE oder eher nächste Woche sein, je nach dem, was mir noch einfällt... Gruß Jörg
Insgesamt ein total tolles Projekt ;) Werd mir mal den Bausatz zum Sommerurlaub bestellen g Vielleicht bekomm ich ja meine Kinder dazu auch ein wenig zu spielen :) Gruß Anselm
Hallo, es gibt wieder eine "Zwischenversion" als Hexfile zum Testen. 1. Den Ansatz mit VSET und ASET habe ich wieder fallen lassen, ganz einfach deswegen, weil mir eine bessere Idee gekommen ist, Sytemvariablen! Diese bestehen aus der Tilde (~) und einem Buchstaben, und können wie Konstanten benutzt werden. ~P ist das aktuelle Programm (1-8) ~L ist die aktuell abgearbeitete Programmzeile (1-95) ~S gibt die gerade aktive Bildschirmzeile zurück ~V gibt an, aus wieviel Bildschirmzeilen ein Halbbild besteht (263/313) ~X Anzahl der Pixel in horizontaler Orientierung ~Y Anzahl der Pixel in Vertikaler Orientierung ~X und ~Y hängen dabei vom gerade aktiven Videomode ab. 2. EPEEK(N) liefert ab N=3072 die Programmbytes für die Programme 1-8 wobei gilt: N=3072*Programmnummer(1..8), ab N=6144 stehen z.B. 12 bytes für den Programm-Namen von Programm 2 3. Nachdem eine Realisierung im BASIC einfach zu umständlich und zu kompliziert , die Funktionalität aber notwendig war, gibt es einen neuen Befehl: SCALE
1 | SCALE Variable,Y1,Y2,X1,X,X2 |
Die angegebene Variable anthält nach dem Aufruf den Wert Y, der relativ gesehen so zwischen Y1 und Y2 liegt wie X zwischen X1 und X2. Damit das Ergebnis hinreichend genau ist, wird dabei intern teilweise mit 32 Bit gerechnet. Um z.B. einen 10 Bit ADC-Wert in Prozent-Angaben zwischen -100% und +100% umzurechen ist nur folgendes notwendig:
1 | 10 A=ADC(0); |
2 | 11 SCALE R,-100,100,0,A,1023 |
3 | 12 ? R |
4. Ich habe die Config-Seite umgebaut, da die Bedienung über die Funktionstasten einfach zu unübersichtlich geworden ist und ein Abbruch ohne Reboot nicht mehr möglich war. Jetzt geht es so: - Mit den Cursor Tasten (nach unten/nach oben) wird die zu ändernde Einstellung ausgewählt. Dabei ist der aktuelle Wert invers dargestellt. - ESC bricht ab, ohne die Konfiguration zu speichern - Mit F1 wird der Wert geändert - mit F2 werden die aktullen Einstellungen gespeichert und ein Reboot ausgelöst. - Mit F4 kann das Sytem, wie gehabt, geclont werden. Viel Spaß damit, Jörg
Endlich ist mit der Version 1.02 auch die API-Dokumentation der mittlerweile etwas über 100 Funktionen abgeschlossen. Ein paar Bugfixes sind auch noch dabei: - GOSUB-RETURN innerhalb von FOR-NEXT Schleifen führte zu Fehlermeldungen - Nach dem Update via Bootloader funktionierte die Konfigurationsseite nicht mehr richtig Die LaTex und XFig Dateien für die Dokumentation werde ich auch über Berlios bereitstellen, Homepage wird nachher noch aktualisiert. Gruß Jörg
@Joerg: Wie währe es wenn du Zeilennummern nur noch als Labels siehst? Also das Konstrukte wie das da möglich sind:
1 | 10 print "foo" |
2 | for x = 1 to 10 |
3 | if y = 5 then x = 10:goto 20 |
4 | rem irgendwas sinnvolles mit y |
5 | 20 next x |
@Bernd Das geht leider nicht so einfach, denn die Zeilennummern existieren ja im Programm selbst gar nicht. Da jede Zeile, gleich welchem Inhalts, immer 32 Bytes groß ist, wird bei einem GOTO 5 die Abarbeitung einfach bei Adresse 128 weitergeführt. Gruß Jörg
Im API bis Version 1.02 gibt es einen Fehler, api_dataptr lieferte leider eine falsche Adresse zurück. Außerdem wird es noch zwei zusätzliche API-Routinen geben die CCHAR im Basic entsprechen. Momentan gibt es nur das aktuelle BIN File, welches via XMODEM über den Bootloader geflasht werden kann. Jörg
Die aktuelle Version 1.03 muß letztendlich doch geflasht werden, da es auch im oberen Speicherbereich eine Änderung gab. - Bugfix in api_dataptr (siehe letzten post von mir) - API-Funktionen um BASIC-Routinen erweitert - Oszi-Beispielprogramm aktualisiert Programme, deren Namen mit einem Unterstrich beginnt, werden beim Speichern nicht mehr tokenisiert und können auch nicht mehr gestartet werden. Damit kann man den Editor (eingeschränkt) auch als Texteditor verwenden. Jörg
Hi Joerg, find ich gut das du immernoch so engagiert an dem BASIC-PC arbeitest. Ich flashe nach wie vor jede neue Version darauf und es macht auch immernoch Spaß damit zu proggen ;) Gruß Robin T.
Hallo Jörg, seit ungefähr einem Jahr verfolge ich die Entwicklung des Chipbasic Computers, Hut ab vor dem was Du da auf die Beine gestellt hast. Schon lange war ich auf der Suche nach so etwas womit man mal schnell was steuern oder regeln kann. Dein Projekt zielt wahrscheinlich nicht primär auf MSR, was die zahlreichen Möglichkeiten der Videoprogrammierung erklärt. Das ist jedoch nicht weiter schlimm, man kann sich eben mit den vorhandenen I/O Befehlen helfen. Nun zu meiner Frage: Ich habe mir den Rechner auf Lochraster aufgebaut und um einige I2C Bausteine für spezielle Aufgaben ergänzt. Die generische I2C Rautine klappt auch soweit, ich habe jedoch bei über Kabel angeschlossenen Bausteinen wie dem von Dir mit der temp() funktion supporteten LM 75 das Problem das dieser aufgrund von Störpegeln bzw. der hohen Taktfrequenz von mindestens 100khz auf dem Bus bei einer schon relativ kurzen Kabellänge von unter einem Meter austeigt und einen I2C Error bringt oder das System sich aufhängt. Gibt es eine Möglichkeit vielleicht durch einen Poke in eine Speicherstelle die Taktfrequenz auf dem Bus rapide herabzusetzen, vielleicht so auf 1khz um eine höhere Kabellänge zu den Sensoren zu realisieren? Roger
> Schaue dir mal www.DieProjektseite.de an.
Weshalb ?
Otto
erstmal btt: der chipbasic2 ist garnicht mal so uninterissant. man braucht, zum bausatz. noch ein programmerkabel für den atmel. ich hab mich bishher eher nur für den propeller mcu interissiert. eigendlich komme ich aber eher aus der programmierer szene. zuletzt hatte ich, bevor ich mir ein hive-computer gebaut habe, vor 10 jahren mal herum gelötet... nun suche ich seit monaten eigendlich nach kleinen elektronik projekten, wo ich wieder etwas in die technik herein finde. zum chipbasic2: der computer hat einen einfachen aufbau, wie ich ihm vom c=64 und anderen homecomputern kenne. was mich an den pc stört, ist einzig und allein die begrenzung auf 95 zeilen und dem damit verbundenen, sehr kleinen programmspeicher. es gibt zwar ein eeprom mit 8 plätzen, dieser ist aber schnell belegt, wenn ich darauf ein paar zeilen basic tippe. ich denke da an das eine oder andere textadventure (i love him), oder einen kleinen sidescroller. 95 zeilen hören sich viel an, aber wenn man mehr als 1 level bauen will, dann wirds da schnell eng... von daher...: ich hab mit den "computer", den hansi hier vorstellte einmal angesehen. an sich ist der computer eine gute creation. im shop gibt es aber keine platinen. diese muss man sich selbst anfertigen. man kann das ganze auf lochraster nachbauen, oder die platinen selbst fertigen, bzw. fertigen lassen. letzteres jedoch nicht beim betreiber der homepage... ich persönlich habe ein hive ( mehr dazu hier: Beitrag "Projekt: HIVE - retro style computer" oder auch auf http://www.hive-project.de ). ich bin auch im forum team (nickname: borgkönig) aktiv. fazit: der chipbasic ist eigendlich gut durchdacht. es gibt, in meinem augen, nur eine schwachstelle: man kann nur 95 zeilen/ programm eingeben. der basic interpreter sollte soviele zeilen schlucken, wie realer ram verfügbar ist...
@hobby-coder: Dafür kostet das Hive auch gleich um einiges mehr. Minimalstbeschaltung des AVR-ChipBasic lässt sich mit Bauteilen für ~5 Euro machen, zieh einen guten Euro ab wenn du einen PC mit USB als 5 Volt Steckdose missbrauchst. Und genau darum geht es hierbei, mit geringsten Mitteln einen voll funktionsfähigen Computer bauen welcher am Fernseher angeschlossen werden kann und eine Tastatur besitzt. Und ich schätze mal wenn man ein paar Chinesen für dieses Teil begeistern könnte, könnte man den ChipBasic in Vollausstattung, fertig gelötet im Gehäuse, für maximal 10 Euro kaufen.
Mein Beetle ist irgendwie das Zwischending vom ChipBasic und dem Hive. Durch das modulare Konzept vom Beetle kann man das System noch massiv erweitern. Die Zeilengrenze vom ChipBasic gibt es bei mir auch nicht. Erst einmal stehen 64 kB RAM zur Verfügung und durch den Chain-Befehl sind theoretisch unendlich große Programme möglich. Erweiterungsmodule und Programme werden laufend entwickelt. Auch Lehrgänge wird es immer weitere geben. Habe gerade erst mit der Entwicklung eines weiteren größeren Programmes und einer Hardwareerweiterung begonnen. Das Preview werde ich wohl Anfang nächster Woche auf meiner Seite (www.DieProjektseite.de) vorstellen können.
@Roger die demnächst kommende Version 1.10 wird (zumindest Byteweise) lesenden und schreibenden Zugriff auf alle I/O Register haben. Mittels Datenblatt lassen sich dann leicht andere Werte für TWBR und TWSR einstellen. @hobby-coder etwas hast Du da durcheinandergewürfelt. Die 8 Programme sind alle im internen Flash, internes und externes EEPROM kann nur noch zur Speicherung von Daten benutzt werden. Zusätzlich gibt es ein externes Dateisystem auf Dataflash. Die Dateien können bis zu 32K groß werden und seitenweise in das Array eingelesen werden. Für ein Textadventure müsste man nur die Engine in BASIC schreiben, die die Daten blockweise in das Array nachlädt. Die nächste Version wird auch eine Änderung enthalten, die eventuell bestehende Programme betreffen kann. Und zwar habe ich GOSUB mit ein und zwei Parametern wieder in GOSUB und CALL getrennt. Dafür können dann bis zu 5 Parameter übergeben werden, mit RETURN N auch ein Rückgabewert. Für reine BADIC-Programme ist das nicht unbedingt notwendig, aber das Schreiben von externen Assembler-Routinen wird um einiges leichter. Jörg
@Joerg: Wie führst du AVR Assembler aus? Flasht du jedes mal den AVR neu? Oder kann Chipbasic jetzt auch mit dem AVR-FPGA umgehen und doch nativen AVR Code ausm Arbeitsspeicher ausführen?
Die Programme werden in das Flash geschrieben, z.B. beim Laden vom Dataflash-Modul. BASIC-Programme werden beim Speichern auch in Tokencode übersetzt und dann in das Flash geschrieben. Das mit dem Asseblercode stimmt nicht ganz, der muß natürlich vorher auf einem PC in Maschinencode übersetzt werden... Um das Programmieren zu erleichtern, gibt es ein API mit über 100 Funktionen, die in eigene Programme eingebunden werden können. Jörg
Hi ich hab mir den Bausatz organisiert, aufgebaut und ausprobiert. Beim PONG Startet das Spiel nicht und eine Fehlermeldung RETURN ohne GOSUB in Zeile 49 erscheint. Hat jemand eine Idee? Chipbasic V1.0 ist in Verwendung Grüße PS Jörg: Wahnsinns Projekt !
Hallo StefanG, benutze bitte die aktuelle Version (1.03), in die 1.0 ist leider ein Bug reingerutscht, der die Fehlermeldungen verursacht. Jörg
So, ich hoffe, dass nicht allzuviele neue Fehler reingekommen sind... Folgendes hat sich geändert: - Aufspaltung von GOSUB in GOSUB und CALL - bis zu 5 Parameter könen übergeben werden ~(1)...~(5) - Anzahl der übergebenen Parameter mit ~N - RETURN kann einen Rückgabewert erhalten ~R Die Funktionsparameter und der Rückgabewert existieren nur einmal, das ist insbesondere bei verschachtelten GOSUB-Aufrufen zu beachten. - IN und OUT im Adressbereich $4xx greifen nun direkt auf die I/O Register des Mega644 zu Und schließlich noch ein paar Bugfixes und Erweiterungen im API, um z.B. aus nativen AVR-Programmen auf die Funktionsparameter zuzugreifen. Jörg
Hallo zusammen, eigentlich möchte ich Jörg hier nur meine Anerkennung aussprechen. Dein Projekt Chipbasic ist schon klasse! Ich habe meine Erfahrung und Begeisterung mit dem Chipbasic2 auf meiner Homepage niedergeschrieben. Schaut doch mal rein http://www.dh2faa.de dann Projekte und aus der Liste den Eintrag 15 anklicken. Eine kleine frage hätte ich noch: Welche EEPromtypen werden unterstützt? Danke und Gruß Heiko
@ Joerg Wolfram: Mich stört am gesammten Projekt eigendlich nur die 95 Zeilen Begrenzung. Im großem ganzem ist Dein Projekt einfach klasse. Ein OS + IDE + Keyboard + Grafik in ein MCU zu packen, ist eine große Leistung. Mich würde mal interissieren, wie man das Problem, das man nur 95 Zeilen pro "Seite" hat, umgehen kann ohne externe Dateien verwenden zu müssen... Zu C=64 Zeiten hatte man ja auch oftmals sein Programm in eine Datei gesteckt... Zum Dataflash Modul: Gibt es dafür ein Bausatz? Wenn nein, wie hoch ist der Aufwand, einen solches auf einer Lochraster Platine nach zu bauen? Und, welche Bauteile braucht man dafür, neben dem Flash Chip?
@ jörg wolfram: vielen Dank für die Implementation des direkten Zugriffs, ich habe es gestern ausprobiert und die Bitrate reduziert, man kann so die mögliche Leitungslänge der Sensoren erheblich steigern. Gruss Roger
@Heiko EEPROMS gehen eigentlich alle 24xx mit zwei Adressbytes, also 24C32 bis 24C512. Beim 24C16 gibt es verschiedene Varianten, manche adressieren mit 3 Bits im ersten Byte und 8 Bits im zweiten, diese funktionieren nicht. @Roger freut mich, dass es so geklappt hat. @Ronny Die 95 Zeilen sind systembedingt und lassen sich auch nicht so schnell erweitern. Die wesentlichste Einschränkung kommt vom Fullscreen-Editor und dem verfügbaren RAM. Und natürlich aus dem Umstand, dass jede Zeile genau 32Bytes groß ist, egal ob leer oder vollgeschrieben. An diesem system werde ich auch nichts mehr ändern, zumindest bei diesem Projekt. Das DataFlash-Modul ist sowohl in der Doku als auch auf meiner Webseite beschrieben, neben dem Flash-Chip braucht es nur noch einen 3K3 Widerstand, einen 10µF keramischen Kondensator und eine LED mit ca. 1,8V Flußspannung. Jörg
Joerg Wolfram schrieb: > @Ronny > Die 95 Zeilen sind systembedingt und lassen sich auch nicht so schnell > erweitern. Die wesentlichste Einschränkung kommt vom Fullscreen-Editor > und dem verfügbaren RAM. Kann man das Ram Problem umgehen, wenn man größere EEProm's verwendet? Natürlich vorausgesetzt, das man kompartible EEProms verwendet... > Und natürlich aus dem Umstand, dass jede Zeile genau 32Bytes groß ist, > egal ob leer oder vollgeschrieben. An diesem system werde ich auch > nichts mehr ändern, zumindest bei diesem Projekt. Das klingt so, als ob Du an einem Nachfolger bastelst...?! > > Das DataFlash-Modul ist sowohl in der Doku als auch auf meiner Webseite > beschrieben, neben dem Flash-Chip braucht es nur noch einen 3K3 > Widerstand, einen 10µF keramischen Kondensator und eine LED mit ca. 1,8V > Flußspannung. > > Jörg Ich denke mal, dass man das auf ein Stück Lochrasterplatine nachbauen kann... Ich probiere das einfach mal aus... BTW...: Sind die Sourcen zu den ChipBasic Computern (Atmega 8 - Atmega 644, bzw. ChipBasic1 - ChipBasic2) Open Source...? Ronny
@Ronny Das RAM Problem kann man so einfach nicht umgehen, außer mit mehr (z.B. externem) RAM. EEPROM ist definitiv zu langsam, eine Zeile einfügen oder löschen würde dann ein paar Sekunden dauern. Es werden ja keine Zeilennummern mit abgespeichert, sondern die Adresse einer Zeile im Speicher lässt sich einfach ausrechnen: Basis + (Zeilennummer-1) *32 Das ist zwar etwas Speicherplatzverschwendung, hat aber gerade aufgrund des deterministischen Zeitverhaltens auch einige Vorteile. Es wäre auch kein Problem, Programme bis zu 255 Zeilen (bei kleinen Änderungen bis zu 32767) aus einem externen EEPROM abzuarbeiten, nur editieren könnte man sie nicht mehr. Dazu könnte man (in ASM) einen kleinen Zeilenlader in eins der 8 Programme schreiben, der die gewählte Zeile aus dem externen Speicher in den Buffer lädt und mit api_basrun ausführen lässt. Zu Nachfolgeprojekten gibt es derzeit nur ein paar Konzeptionen, aber nichts konkretes. Deine letzte Frage verstehe ich nicht ganz, bei allen Projekten steht sowohl auf meiner Homepage als auch in den Dateiarchiven (die auch den Source-Code enthalten), dass die Projekte unter der GPL stehen. Jörg Die gesamten
O.k. Danke für Deine Infos. Wie sehen Deine Konzepte zur Zeit aus...? Letzteres hat sich von selsbt erledigt. Ich habe die Hinweise auf die GPL Linzens übersehen...
@Joerg: Wie sähe es eigentlich mit einer AVR32 Portierung aus? Die Dinger werden ja auch immer billiger und einen einsamen SMD Chip löten sollte selbst der größte Lötkolbenlegasteniker hinbekommen.
Das Problem ist halt, so einen AVR32 baut man nicht schnell mal auf Lochraster oder nem Steckbrett auf. Und damit steigt meiner Meinung nach ganz einfach die Hemmschwelle, so etwas einfach mal aus Spaß nachzubauen. Auch denke ich, dass in dem Projekt noch wesentlich mehr Möglichkeiten stecken. Konkret arbeite ich derzeit ein einer BCD-Arithmetik-Bibliothek, die einfach auf einen der 8 Programmplätze geladen werden kann. Über CALL mit den entsprechenden Parametern kann man dann die einzelnen Funktionen abrufen. Ein-/Ausgabe sowie die Grundrechenarten sind schon fertig, müssen aber noch optimiert werden. Nachdem das Operieren mit Binärzahlen bei der Ausgabe einfach "seltsame" Ergebnisse ausgegeben hatte, bin ich jetzt bei BCD Festkomma mit 8 Vorkomma- und 8 Nachkommastellen angelangt. Aber das muß nicht der Weisheit letzter Schluß sein... In punkto Hardware gibt es ein paar Ideen, aber nichts konkretes. Jörg
1 | "Das RAM Problem kann man so einfach nicht umgehen, außer mit mehr (z.B. |
2 | externem) RAM." |
Das schreit ja förmlich nach dem ATmega1284P, hat auch DIP40. Mit 16kb Ram und einer zweiten USART geht doch noch was. Gruß Rene
Der Mega1284p wäre schon interessant, wenn es ihn denn zu kaufen gäbe. Besonders, da man so die vorhandene Hardware weiternutzen kann. Allerdings ist das dann wieder eine neue "Baustelle", die gepflegt sein will. Und dazu habe ich momentan weder Zeit noch Lust. Da der AVR halt nur Code aus dem Flash ausführen kann, sind die Möglichkeiten, einen "richtigen" Computer damit zu bauen, eher begrenzt. Und bevor ich dasselbe Konzept auf einen anderen Controller portiere, lasse ich mir lieber was neues einfallen. Jörg
Gibt ja immer noch diesen AVR FPGA, wenn ich mich recht entsinne sogar als PLCC, also Rasterbrett tauglich. Ansonsten könnte man sich auch überlegen das ganze auf Z80 zu portieren, die Dinger wirds wohl auch noch in 9001 Jahren geben...
Meine Überlegungen würden dann eher Richtung S12X gehen. Den gibts bis zu 32K RAM und 40MHz Bustakt, lässt sich auch schön in ASM programmieren. Die Videoausgabe könnte dann der XGATE übernehmen. Jörg
Hallo, mal ein kurzes Update. Für die nächste Version habe ich vorgesehen, den bisher eingebauten Videomodus 7 wieder zu entfernen. Dafür wird es einen "Mechanismus" geben, mit dem eigene Videotreiber auf Programmplatz 7 installiert werden können. Die müssen nicht unbedingt Video ausgeben, sondern können z.B. auch ein Text-LCD am Parallelport ansteuern. Die erste BCD-Bibliothek ist in Grundzügen fertig, aber noch zu langsam und zu unflexibel. So komme ich auf etwa 8ms für eine Division mit 6 Vorkomma- und 6 Nachkommastellen, eine Multiplikation braucht ca. 3ms. Momentan experimentiere ich mit einer flexiblen Binär-Festkommaarithmetik mit 7...247 Bit, mal sehen was dabei herauskommt... Auch ein etwaiges Nachfolgeprojekt nimmt langsam konkrete Züge an. Ein Mega8515 plus ein kleines CPLD und 64K RAM liefern 320x240 Vollgrafik in s/w an wahlweise VGA/TV/LCD (umschaltbar). Schnittstellen sind PS2-Tastatur, SPI (Dataflash, Datenaustausch) und ein paralleler I/O Bus. Auf dem Controller selbst läuft ein minimales BS, die Anwenderprogramme werden von einer virtuellen Maschine aus dem RAM ausgeführt. Jörg
Ui! Wenn du es schaffst einen Z80 als VM zu bauen könnte man damit Sinclair BASIC laufen lassen. :)
Bernd schrieb: > Ui! > Wenn du es schaffst einen Z80 als VM zu bauen könnte man damit Sinclair > BASIC laufen lassen. :) So einen hab ich hier auch noch :) Leider ist die Tastatur kaputt :(
Eine Z80 Emulation hatte ich auch schon mit ins Auge gefasst, allerdings ist ein realitätsgetreues Timing mit meinem Konzept nicht möglich. Außerdem lässt sich die Geschwindigkeit der VM steigern, wenn der AVR bestimmte Operationen nativ bewältigen kann (z.B. Multiplikationen). Und kompatibel zu irgendetwas muss sie meiner Meinung auch nicht sein. Jörg
Zumindest in der letzten Version (1.10) ist ein Bug bei ACOPY drin, der das System abstürzen lassen kann. Update kommt so bald als möglich, zusätzlich werde ich noch Shift-Operationen für schnelle Multiplikationen/Divisionen mit Potenzen von 2 einbauen. Jörg
Die neue Version gibt es vorerst nur als Hexfile, sobald die Doku fertig ist auch wieder ein komplettes Paket. Die zusätzlichen Befehle sind: LSHIFT variable,anzahl und ASHIFT variable,anzahl L steht für logisch und A für arithmetisch, die Anzahl ist positiv für linksschieben und negativ für rechtsschieben. LFIND variable,code dieser Befehl ist für das Auffinden von Assemblerbibliotheken gedacht. Jede Bibliothek hat eine (hoffentlich) eindeutige Kennung, über die sie gesucht werden kann. In der Variable steht dann der erste gefundene Programmspeicherplatz oder 0 für nicht gefunden. Die erste Bibliothek ist auch in einem fortgeschittenen Stadium, auch die Geschwindigkeit ist recht akzeptabel geworden. Bis zum Release wird es aber noch etwas dauern. Jörg
Angehängte Dateien:
-
fractal2.png
2,2 KB -
fractal3.png
1,2 KB -
fractal4.png
2,4 KB
Hier schon mal ein "Ausblick" auf die kommende Version 1.22 und die Festkomma-Bibliothek. Letztere kann zur Laufzeit auf 2-32 Vorkomma- und 0-30 Nachkommastellen konfiguriert werden. Realisiert sind Eingabe/Ausgabe über Text, Import/Export von 16Bit Integer-Werten, Addition, Subtraktion, Multiplikation und Division, Multiplikation und Division mit 2, Absolutbetrag etc. In der Testphase ist noch eine Scripting-Engine, mit der sich relativ einfach weitere mathematische Funktionen realisieren lassen. Die Beispielbilder sind aber noch "Zu Fuß" mittels CALL Befehle aus dem BASIC heraus berechnet, allerdings war die Bildausgabe währen der Berechnungen abgeschaltet. Release-Termin für das Paket wird wohl frühestens so Mitte Dezember sein, da die Dokumentation auch noch überarbeitet und erweitert werden muß. Jörg
Joerg Wolfram: "Auch ein etwaiges Nachfolgeprojekt nimmt langsam konkrete Züge an. Ein Mega8515 plus ein kleines CPLD und 64K RAM liefern 320x240 Vollgrafik in s/w an wahlweise VGA/TV/LCD (umschaltbar). Schnittstellen sind PS2-Tastatur, SPI (Dataflash, Datenaustausch) und ein paralleler I/O Bus. " Wäre da nichtr ein Board per 'ATxmega128A1' und ggf. Verwendung einer Adapterplatine wie http://shop.embedded-projects.net/product_info.php/info/p173_ATxmega128A1-TQFP-100-auf-einer-DIP-Adapterplatine.html sinnvoller ? Der könnte per 512k SRAM und DMA locker auch eine 320*240 8 Bit Farbgrafik selbst generieren (wohl nicht VGA) und hat schon 4* I2C onboard ?! Auch sind die 32 MHz für obige Grafikfeatures natürlich auch sinnvoll.
... sinnvoller .... Sinnvoll ist z. B. ein AT91SAM7S64 oder ein anderer Controller aus der ARM7-Serie bzw. deren Nachfolgern.
Der 'AT91SAM7S64' ist nicht für externes RAM konzipiert. Und wie Beitrag "ARM7 uC mit external RAM/ROM als Forenprojekt?" zeigt wird bei ARM7 doch schon in ganz anderer Größenordnung gedacht.
den ATXMEGA hatte ich eigentlich eine Zeit lang als Nachfolger im Visier, das Ganze ist aber wieder vom Tisch und auch mein Demoboard habe ich wieder verkauft. ARM lässt sich meiner Meinung nach nicht besonders schön in ASM programmieren (hatte mal mit nem Cortex M3 angefangen) und sind deswegen auch keine Alternative. Gut, man könnte auch in C programmieren, aber das sollen dann die Leute machen, die Lust dazu haben. Beim HCS12 ist halt leider die allgemeine Verfügbarkeit für "Privatmenschen" sehr eingeschränkt und nicht jeder hat ein passendes BDM-Interface zuhause rumliegen. Also ist es für mich momentan das sinnvollste, das Projekt weiterzuentwickeln und ich denke, dass da noch viel mehr Potenzial drin steckt. Natürlich hat es irgendwo seine Grenzen, aber die gilt es erstmal herauszufinden... Jörg
Joerg Wolfram schrieb: > den ATXMEGA hatte ich eigentlich eine Zeit lang als Nachfolger im > Visier, das Ganze ist aber wieder vom Tisch und auch mein Demoboard habe > ich wieder verkauft. warum eigentlich ?
Hauptgrund war das geänderte Programmierinterface. Davon abgesehen, dass man den XMEGA auf dem XPLAIN Board nicht über den darauf befindlichen USB-Anschluß programmieren kann, braucht man in den meisten Fällen einen neuen Programmer und die Clone-Funktion lässt sich auch nicht mehr so einfach realisieren. Alles in Allem ist es (für mich) den Aufwand nicht wert, da das Projekt OpenSource ist, kann sich ja jeder selbst mit einer Portierung versuchen. Jörg
Hallo Jörg, ich bin grad am überlegen, ob ich meinem Sohn einen Experimentier- computer mit Deinem Basic zu Weihnachten bauen soll, und bin beim Suchen über das gestolpert: http://home.arcor.de/wehrsdorf/Oled-Display-Recycling.html Ich hab mir so ein Teil besorgt. Meinst Du, dass man Dein Basic einfach an diese Platine anpassen könnte? Der Mega 168 ist zwar etwas knapp, aber den könnte man ja gegen einen 328 austauschen. Ein mobiler Basic Computer mit Grafik Display wäre schon nett. Evtl. könnte man auch eine Tastatur über die Infrarot Schnittstelle anschliessen. Gruß Karl
möglich wäre es schon, z.B. die Mega32 Version an einen Mega328 anzupassen. Notwendig wäre hauptsächlich ein neuer Videotreiber, der z.B. die Umgebung des Cursors auf dem OLED darstellt. Ich hatte mal etwas ähnliches konzipiert (AVR-Handheld), die Entwicklung aber wieder eingestellt, da es mir zuviel Aufwand war, die abgespeckte BASIC-Runtime mit der des ChipBasic2 zu synchronisieren. Deshalb kann die nächste Version vom ChipBasic2 auch alternative Treiber laden, die z.B. LCDs über den Parallelport ansteuern. Im Moment habe ich aber nur den originalen "Vektortreiber" und einen TILE/SPRITE Treiber mit "Finescrolling" realisiert. Außerdem wird es endlich Unterstützung für den zweiten USART des Mega644P geben, wobei die Transfer-Operationen weiter über den Software-System-UART laufen werden. Allerdings wird sich die Doku noch etwas hinziehen, bei Bedarf kann ich aber wieder Hexfiles hier reinstellen. Jörg
Hallo Jörg Ich habe den AVR Basiccomputer nachgebaut. Er funktionierte fast auf Anhieb.Jetzt meine Frage, könnte man auch ein Farbdisplay(SHARP LQ 9D01L) mit 640x 480 Pixel anschließen? Das lag bei mir so in der Bastelkiste rum!Meine zweite Frage ist, ich möchte statt des Flashs eine Speicherkarte anschließen. Das müßte doch ohne größeren Aufwand möglich sein, den in den Speicherkarten stecken doch sicher auch nur Flashbausteine. Rudolf
Hallo Rudolf, 1. Das von Dir genannte Display ist nicht anschließbar, da es einen ganz anderen Grafikcontroller braucht. 2. Theoretisch ist es machbar, allerdings ist das Dateisystem speziell auf die Dataflash-Bausteine zugeschnitten. Man könnte das fast 1:1 auf eine SD-Karte übertragen, indem man dort nur 264 Bytes je Sektor nutzt. So ließen sich 256 Dateien mit jeweils maximal 32K unterbringen, was einem Speicherbedarf von effektiv 16MiBytes auf der Karte entspricht. Die Nutzung irgendwelcher PC-Dateisysteme wird allerdings wohl am fehlenden Programmspeicherplatz im Mikrocontroller scheitern. Und, auch wenn etwas schwerer beschaffbar sind die Dataflash-Bausteine günstiger als neue SD-Karten. Jörg
Hallo Jörg Das das LCD so nicht gehen wird das konnte ich mir auch denken. Meine Frage war falsch formuliert. Deshalb noch einmal neu: Könnte man den Atmel dazu bringen das LCD anzusteuern.Ich könnte mir vorstellen, das es zu zeitkritisch wird und wohl deshalb nichts daraus wird. Möglicherweise könnte man die Signalaubereitung Pixcelclock, hsync, vsync extern aufbereiten und dann mit der Datenausgabe verbinden. Ich hatte da irgendwo gelesen das es einen IC von Maxim, denk ich,gibt, der das kann. Das mit den SD Karten kann ich nicht nachvollziehen. Die Karten werden einem schon fast hinterhergeschmissen.Die Fassungen dafür gibts im Elektronikversand auch für wenig Geld. Selbst wenn viel Speicherplatz auf der Karte verschenkt wird,was vielleicht sogar ganz gut ist, den dann werden die Speicherzellen nicht so oft beschrieben und halten länger. Würde es Dir viel Arbeit machen das Teil in den Basiccomputer mit zu integrieren? Das wäre echt Spitze. Ansonsten ist Dein Projekt echt gut, wenn man bedenkt was alles in den einen Chip passt, und was an Gehirnschmalz darin steckt! Ach so noch eins. Der Comp reagiert sehr unwillig auf das Niederdrücken der Tasten auf der Tastatur. Die Pfeiletasten werden sofort erkannt und man kann damit im Menüe hin und her fahren. Auf die ESC Taste und die vier Funktionstasten reagiert der Computer nur sehr unwillig wenn überhaubt.Ich habe schon mehrere Tastaturen ausprobiert, manche gehen gar nicht, wie Du das schon vorausgesagt hast, und die ps2 Tastatur funzt gleich nicht, da bricht der ganze comp zusammen. Rudolf
Ach so was ich noch vergessen habe. MEINE Tastatur ist eine AT. Angeschlossen wird sie über einen industrieellen Adapter an den ps2 Eingang des Computers. Nur damit gehts! Rudolf
>Und, auch wenn etwas schwerer beschaffbar sind die Dataflash-Bausteine >günstiger
als neue SD-Karten.
TME.eu hat massenweise und verschiedene Bauformen und Speichergößen der
DataFlashs.
CSD-electronics hat auch die wichtigsten und liefert an privat.
Hallo Jörg, kannst Du das mit den ladbaren Displaytreibern etwas näher erklären? Wie wird das praktisch aussehen? Vielleicht kann ich mit dem Treiber für das Oled zur Hand gehen. Dieses spezielle Display hat den Vorteil, dass das komplette Gerät (inclusive Spannungswandler und ATMega16) für 5-6 Euro zu haben ist, was ein ziemlich unschlagbarer Preis ist. Da überlegt man isch schon, was man mit dem Ding alles anfangen könnte. --Karl
@Rudolf Ich denke, um ein solches Display vernünftig anzusteuern braucht man schon einen Displaycontroller oder etwas vergleichbares. So, wie Du das mit den Tastaturen beschreibst, würde ich eher auf ein elektrisches Problem schließen. Eventuell mal 3K3 Pullups an die Daten- und Taktleitung hängen. Während des Startbildschirmes kann man übrigens auch mit der rechten Shift-Taste in den "Keyboard-Debug-Modus" wechseln, in dem die von der Tastatur gelieferten Scancodes angezeigt werden. Ich selbst sehe in SD-Karten anstelle von Dataflash-Bausteinen keinerlei Vorteil, außer dass man sie halt an jeder Ecke zu kaufen bekommt. Wobei das langsam aber auch nicht mehr stimmt, denn meistens sind das ja neuerdings SDHC-Karten, die dann von der Ansteuerung her wieder nicht mehr kompatibel sind. Den Aufwand würde ich nicht allzu hoch schätzen, solange die Dateisystemstruktur beibehalten wird und jemand schon genügend Erfahrung damit hat. Dann könnte man einfach die Libdfl ersetzen, wobei dann allerdings die Möglichkeit, Dataflash Bausteine anzusteuern verlorenginge. Alternativ könnte man "Programm von SD laden" und "Programm auf SD speichern" in ein ladbares Binärprogramm packen und darüber ausführen. Dieser Weg steht auf jeden Fall offen, die Frage ist nur, ob sich jemand der Scahe annimmt... Jörg
@Karl Das geht aber nur beim ChipBasic2, bei der Mega32-Version wäre es theoretisch auch mögich allerdings sind die beiden Systeme nicht zueinander kompatibel. Aussehen wird es so, dass man den Treiber einfach auf Programmplatz 8 lädt und über VMODE 7 aktivieren kann. Nach dem Aufruf der Initialisierungsroutine im Treiber werden sowohl die Bildausgaberoutine als auch die Ausgabefunktionen (PRINT, PLOT...) auf diesen Treiber umgeleitet. Wird wieder zu einem anderen Video-Modus zurückgewechselt, wird eine Shutdown-Routine im Treiber aufgerufen und danach alle Ausgaben wieder auf die internen Treiber umgestellt. Mit 2 Konfigurationsbits im Treiber kann man die Ausgaben zum Parallelport unterbinden und externe I/O (z.B. über I2C) ab Adresse 0x500 aktivieren. Dazu wird es wahrscheinlich später einen Mega 16/32 als IO-Erweiterung geben. Jörg
@Jörg
Hast du dir für ein Nachfolgeprojekt eigentlich auch mal den Parallax
Propeller Chip angeschaut? Das ist der ideale Chip für ein solches
Projekt.
- mehrere parallele Prozessoren
- Video Generator mit Farbe möglich (Hardware 3 Widerstände)
- VGA und controllerlose LCDs ansteuerbar
- SD Treiber (auch SDHC mit FAT32), PS/2 und so weiter schon als
einbindbare Objekte verfügbar.
- Im DIP40 erhältlich, per serielle Schnittstelle programmierbar
>> Ich selbst sehe in SD-Karten anstelle von Dataflash-Bausteinen keinerlei
Vorteil, außer dass man sie halt an jeder Ecke zu kaufen bekommt
Das liegt dann wohl daran dass du den ~ 1000 mal grösseren Speicher
nicht nutzen kannst. Mit dem Propeller kann man z.B WAV-Dateien spielen,
was sehr schnell nach etwas mehr Speicher verlangt...
Andi
@ Andi > Das liegt dann wohl daran dass du den ~ 1000 mal grösseren Speicher > nicht nutzen kannst. Mit dem Propeller kann man z.B WAV-Dateien spielen, > was sehr schnell nach etwas mehr Speicher verlangt... > Nein, ich WILL den größeren Speicher nicht nutzen. Denn dann wird das Ganze irgendwann derart aufgeblasen, dass man sich auch gleich ein kleines ITX Board kaufen kann... Für den Propeller gibt es ja bereits HYDRA als Spielkonsole und den HIVE. Dem muß man meiner Meinung nach nicht unbedingt noch ein drittes ähnlich gelagertes Projekt hinzufügen. Da ist dann ein S12 oder S12X (für mich) schon eine interessantere Herausforderung, abgesehen davon dass ich zum Programmieren des Propellers Dinge benutzen müsste, die ich ganz einfach nicht benutzen möchte. Jörg
OK, wenn du natürlich nicht nach einer einfachen, leistungsfähigeren Lösung suchst, sondern nach einer Herausforderung, dann ist jeder Tipp überflüssig. Denn nur du kannst wissen, was dich herausfordert. > Für den Propeller gibt es ja bereits HYDRA als Spielkonsole und den > HIVE. Hydra ist zu teuer und nicht offen, Hive ist zu kompliziert und niemand programmiert was dafür. Aber da gibt es noch viel mehr Hardwareplattformen mit dem Propeller. Die Herausforderung wäre halt die Software. > ... zum Programmieren des Propellers Dinge benutzen müsste, die ich > ganz einfach nicht benutzen möchte. Wenn du damit Windows meinst - es gibt alternative IDEs für Linux und MacOS. Wenn du Spin meinst - Es gibt auch C, und Assembler geht immer. Andere Hindernisse fallen mir gerade nicht ein. Andi
Andi, kannst du bitte einen Link mit C-Compiler und/oder IDE für den Propeller posten? Ich kenne nur das da http://propeller.wikispaces.com/Linux+Development und das ist nicht grad' was ich mir vorstelle.
> Hydra ist zu teuer und nicht offen, Für die interissiere ich mich auch, aber ca. 250€ für ein paar elektronische Bauteile...? Nein danke. Da nehm ich lieber dieses Ding hier: http://www.microcontroller-starterkits.de/propeller.html > Hive ist zu kompliziert und niemand > programmiert was dafür. Aber da gibt es noch viel mehr > Hardwareplattformen mit dem Propeller. Die Herausforderung wäre halt die > Software. Für den Hive wird Programmiert. Die meisten Projektbeteiligten, dazu gehöre auch ich, sind aber eher die Bastler... Auf der Projekt Homepage wird das HiveOS vorgestellt. Einige haben sich das IOS näher angesehen und dieses etwas angepasst. Es gibt Hacks für den Grafiktreiber. Dann gibt es ein Hack/ Workaround für die Signalstörung zum TDA7050 Verstärker-IC und, es gibt bereits einen - noch in der Entwicklung befindlichen - Rom- Switcher. Programmiert wird für den Hive natürlich auch. Meistens sind es aber nur Kleinigkeiten. Es gibt schnelle Ports einiger Spiele, die auf dem Propeller MCU portiert worden waren. Ausserdem hatte ich begonnen, ein E-Mag für den Hive zu schreiben. Entsprechendes kann man im Forum lesen... Einige Links: Projekt Homepage -> http://hive-project.de/ Forum -> http://hive-project.de/board/ Wiki -> http://hive-project.de/wiki/ So, nun aber wieder BTT :)
Oje, ich wollte hier keine Propeller Diskussion auslösen. Darum antworte ich auch nicht detailliert auf die letzen Beiträge. Aber Links sollten eigentlich schon sein, wenn man was behauptet, darum liefere ich die noch nach: IDE: http://forums.parallax.com/forums/default.aspx?f=25&m=298620 http://propeller.wikispaces.com/Mac+and+Linux+native+development C Compiler: http://forums.parallax.com/forums/default.aspx?f=25&m=388930 es gibt auch noch einen kommerziellen im Parallax Store. >So, nun aber wieder BTT :) genau
Ich muss Jörg recht geben. Ich weiß nicht recht, wofür der Propeller Chip gut sein soll. Das ist ein typisches Nerd Produkt. Er hat zwar einen interessanten Videogenerator, aber viel zu wenig RAM, um ihn sinnvoll zu nutzen. Die aktuellen Projekte benutzen umständliche Tricks, die nie so vorgesehen waren, um Code nachzuladen und externen Speicher zu benutzen, was aber die Ausführung so langsam macht, dass der Propeller seine Vorteile nicht mehr ausspielen kann. Wenn man viel Zeit hat, kann man mit dem Propeller Sachen machen, die andere Controller von Hause aus können (meistens besser und billiger), und sich Tools selbst schreiben, die es anderswo kostenlos dazu gibt (z.B. C-Compiler, Debugger). Man kann's aber auch bleiben lassen. Da kauf ich mir lieber für das selbe Geld ein ARM oder Mips Board. Schaut euch mal an, was man für 50 Euro schon alles bekommt: Ein ARM Board mit 16MB RAM, 4MB Flash, WLAN, Ethernet, USB Host, RS232, JTAG, mit Ethernet Bootloader und kompletter Linux Distribution. Auch Router genannt. Das Chipbasic ist deshalb cool, weil es auf einem einzelnen AVR ohne viel drumherum läuft, und weil die Entwicklung auf dem Gerät selbst läuft, ohne PC mit Toolchain.
Hallo Jörg! Ich habe die zwei Pullupps an die beiden Leitungen gehangen. Funzt einwandfrei.Die beiden Widerstände solltest du gleich mit auf der platine integrieren. Ich habe auch zusätzlich noch einen kleinen Resettaster auf die Platine gesetzt, um nicht immer das Steckernetzteil ziehen zu müssen, wenn ein Neustart sein muß. Jetzt noch eine Frage zum Übertragen von Dateien vom PC zum AVR. Bis jetzt kommt immer nur Schrott oder nichts auf dem AVR an. Ich kann machen was ich will alle Einstellungen die möglich sind, habe ich ausprobiert. Gibts noch etwas was ich nicht beachtet haben könnte? Manchmal bricht auch der AVR völlig zusammen, das Bild ist weg und es geht garnichts mehr, auch kein Reset. Dagegen hilft nur den seriellen SUB rauszuziehen, dann startet der AVR wieder allein. Rudolf
Hallo! Das bin ich noch ein Mal! Ist die Englishe Dokumentation schon verfügbar? Ich kann die nicht finden.
Hallo Jörg! Hat sich erledigt. Habs auf die Reihe bekommen.Programme lassen sich laden und starten.Die Einstellung ist `simple` in AVR Config,2400 Baud,2 Stopbits ,Parität keine.Eins ist aber immernoch:wenn ich einen Kaltstart mache mit meinem Resetknopf, stürtzt der AVR ab. Erst das Abziehen des Steckers von der Seriellen Schnitstelle bringt wieder Leben in das Teil. Rudolf
@Rudolf Welche Version benutzt Du, wie sind die Fuses gesetzt? Mit den Fusebytes LOW 0xe6 HIGH 0xd1 EXT 0xfc wird der Bootloader abgeschaltet, mit LOW 0xe6 HIGH 0xd2 EXT 0xfc ist er aktiv und sollte auch beim Kalt-Start (serielles Kabel angesteckt) der Bootloader (oben eine grüne Textzeile) kurz zu sehen sein. Anstelle von RESET sollte CTRL+ALT+DELETE für einen Warmstart eigentlich immer gehen. @Klima Im Moment ist nicht mal die deutsche Doku vollständig, ob es jemals eine englische von mir geben wird, ist bei meinem derzeitigen Zeitbudget eher fraglich. Und weil ich gerade dabei bin, die nächste Version wird es wohl erst im neuen Jahr geben. Hauptgrund ist ein erweitertes Treiberkonzept mit definierten Schnittstellen. Jörg
Hallo Jörg! Ich benutze die Version 1.20 .Warum der AVR abstürtzt ist mir jetzt auch klar geworden. Die grüne Zeile nach dem Einschalten ist nicht zu sehen. Der AVR springt sofort auf den blauen Bildschirm mit dem symbolischen Chip drauf.Ich denke die Grüne Zeile müßte eigendlich zu sehen sein, selbst wenn die fusebits verkehrt sind, da diese ja nur den Speicherbereich gegen überschreiben schützen und der Bootlader als Programm ja vorhanden ist,oder liege ich da verkehrt?. Rudolf
Hallo Jörg! Alles klar habs auf die Reihe bekommen. Alles funzt wie es sein soll. Die Erweiterung bau ich demnächst auf, sobald der IC eingetroffen ist. Frohe Weihnacht und einen guten Rutsch ins neue Jahr wünscht Rudolf
Hallo Jörg! Erstmal beste Neujahrswünsche an alle.Ich habe schon wieder ein Problem. Nachdem der AT Flash bei mir eingetroffen war hab ich das Modul zusammengebaut. Es ist aber kein AT45DB08 an Bord sondern ein AT45DB161.Der Baustein wird aber vom AVR nicht erkannt wie es aussieht. Weil ich dachte, ich hätte mich bei der Bestellung geirrt ließ ich nochmal einen AT 45DB08 kommen. Wieder hat man den 161 ersatztweise reingepackt. Er unterscheidet sich nur in der Größe der Pageseiten nämlich mit 528 Bytes, statt beim 08 der nur 264 Bytes hat. Natürlich sind die S-Ram Data Buffers auch größer. Wie läuft eigendlich die Erkennung des Flashmodules? Welche Parameter werden abgefragt? Läßt sich der AVR nicht so umstellen, daß auch diese Flashbausteine erkannt werden? Rudolf
Hallo, auch von mir Neujahrsgrüße an alle. Der Flash-Typ wird über die Device-ID bestimmt. Ich werde mal schauen ob man den Treiber an den 161 anpassen kann, allerdings wird er dann als 81-er behandelt. Ansonsten müsste man einen neuen Dateisystemtreiber schreiben. Wenn wir gerade bei den Treibern sind, die kommende Version wird da wesentlich flexibler sein. Z.B. 4- und 8-Kanal Soft PWM (ca. 60Hz) am Parallelport wobei nur noch die ersten 24 Zeichen je Zeile dargestellt werden habe ich bereits realisiert. Grafik- und Text LCD Treiber sind ebenso geplant wie LED Multiplex Treiber. Die Clone-Funktion habe ich wieder entfernt, dafür gibt es jetzt ein ladbares Programm, mit dem man auch die Konfiguration des zu clonenden Controllers einstellen kann. Ebenso wird es nur noch eine Tastaturtabelle geben, die aber via Binärprogramm änderbar ist. Jörg
Hallo, erstmal Glückwunsch zu diesem ebenso simplen wie tollen Projekt! Ich habe über die Feiertage auch endlich meine Platine zusammengelötet und werde damit meine ersten Spielereien machen. Damit rutscht man ja fast wieder in die Zeit der alten Heimcomputer - nur mit mehr Rechenpower. Womit wir beim Thema sind: Die Beispielcodes sind zum ersten Testen ja sehr schön, aber hat von Euch vielleicht jemand auch noch eigene Tools, Spiele, Demos geschrieben und im Internet zur Verfügung gestellt? Ich selbst habe z.B. noch viele alte "Happy Computer" usw. mit vielen kleinen Listings für diverse Heimcomputer. Damals habe ich die schon z.B. von ZX Spectrum auf ATARI XL portiert. Das könnte man teilweise auch mal für das Board ausprobieren. Ein digitaler Joystick sollte sich ja an den Parallelport anschließen lassen (kann man den per Basic einlesen?). Wenn das funktioniert, würde ich die Sourcen auch irgendwo ablegen. Gruß, Rene
@Rudolf Support für den 45DB161 und den 45DB321 sollte in der nächsten Version mit drin sein, allerdings muss ich noch testen, ob das auch so funktioniert. Wichtig ist aber auch, dass diese (zumindest laut meinem Datenblatt keine 5V an den Eingängen vertragen wie der 45DB081. Hier ist also auf jeden Fall eine Pegelanpassung notwendig. @Rene Digitaler Joystick sollte kein Problem sein, einfach die Schalter zwischen I/O und Masse. Gelesen wird dann mittels IN(n). An Pin16 (/INIT) der paralellen Schnittstelle kann man getrost auch +5V nach aussen führen, ohne dass ein angeschlossener Drucker Probleme macht. Das wird auch in der nächsten Doku mit drin sein. Und das mit der Programmsammlung wäre eine feine Sache, ich habe aber ehrlichgesagt momentan weder Zeit noch Lust, so etwas zu pflegen. Support für den Mega644P ist fast fertig, dazu kann der Input-Pin der seriellen System-Schnittstelle (also der immer vorhandenen) per Konfiguration zwischen PD1 und PD3 gewählt werden. Der Controllertyp wird automatisch beim Systemstart erkannt und auch angezeigt. Beim Editor gibt es ein paar kleine Änderungen, insbesondere werden die Cursorpositionen beim Verlassen des Editors im EEPROM gespeichert. LCD- bzw. DUAL-Treiber (die Anzeige ist parallel auch über den TV-Ausgang verfügbar) habe ich für 1x16 und 2x20 Zeichen Displays fertig, andere habe ich z.Zt. nicht rumliegen. Allerdings fehlt hier noch die Doku komplett. Release-Zeitpunkt wird wohl am WE sein, wahrscheinlich aber nur für das "Hauptpaket". Jörg
Mit einem AT45DB321 habe ich es gestern getestet und es funktioniert. Der AT45DB161 müsste eigentlich auch gehen. Wichtig ist, zuallererst in die Config-Seite zu gehen, und den Input-Pin für die serielle Schnittstelle auf "PD3" zu stellen da er bei der bisherigen Schaltung dort liegt. Jörg
Hallo Jörg! Mit der neuen Software hat der AVR das Flashmodul sofort erkannt. Das Abspeichern der Programme scheint auch zu funzen. Ein Problem scheint es beim Lesen zu geben, denn es werden nur Fragmente der Dateien ausgelesen. Könnte das möglicherweise eine Signalpegelunterschied der Leseleitung zwischen dem AVR und dem AT 45DB161 sein, oder habe ich den Flash schon geschrottet?. Im Moment habe ich keine Zeit weiter nach Ursachen zu forschen. Bis auf weiteres. Rudolf
Hallo Rudolf, bei mir hatte es eigentlich funktioniert. 3 Dinge fallen mir dazu ein: 1. Wie erzeugst Du die 3,3V? Nachgemessen? 2. Bei der Schaltung mit LED eventuell den Abblockkondensator vergrößern 3. SPI-Takt probeweise auf 156 KHz stellen Bis zum nächsten Release wird es noch ein klein bisschen dauern, da ein paar generelle Dinge zu Binärprogrammen noch konkret definiert werden müssen. Jörg
Ich habe gestern festgestellt, dass durch die Änderung im DataFlash-Treiber Dateien tatsächlich nicht richtig geschrieben werden. Das Problem lässt sich allerdings nicht so einfach lösen und deswegen habe ich die Unterstützung für den AT45DB161 und den AT45DB321 erstmal wieder entfernt. Jörg
So, endlich geschafft! Die aktuelle Version hat mittlerweile die Nummer 1.27 und jede Menge Neues zu bieten. Neben Bugfixes und Erweiterungen im BASIC habe ich vor allen Dingen das Bibliotheks- und Treiberkonzept stark überarbeitet. So lassen sich jetzt verschiedene Text und Grafik LCDs an den Parallelport anschließen oder der Parallelport als 4 oder 8 Kanal PWM nutzen. Zur Spieleprogrammierung gibt es einen Tile/Sprite Treiber mit horizontalem und vertikalem Fine-Scrolling und den ehemaligen Videomode7-Treiber. Über einen seriellen Lader kann das Ganze auch ferngesteuert mit neuen Programmen versehen werden, ein passendes Terminalprogramm ist auch dabei. Da die Datenmenge wieder etwas angewachsen ist und nicht jeder alles benötigt, habe ich das Ganze auf 3 Pakete verteilt. Viel Spaß damit, Jörg Was ich übrigens sehr interessant fand, dass es auf meine vagen Projektankündigungen recht viele Beiträge gab, zum eigentlichen Projekt eher weniger...
Sehr schöne Arbeit :) Endlich wieder was zum testen und spielen ;) Danke dir.
In der Doku sind leider ein paar Bilder verkehrt, da muss ich mir zum WE das Build-Script nochmal ansehen. Dann wird auch die Homepage wieder aktualisiert. Jörg
Homepage ist jetzt aktualisiert, es hat sich leider auch noch ein Fehler ins Programm eingeschlichen. Durch die Umstellung auf das Mega644p Includefile hatte der Wert von SPDR0 plötzlich den Wert Null, ohne dass der Assembler etwas anmeckern konnte. Die SPI() Funktion hing sich deswegen auf und auch im Clone-Programm bestand das Problem. Da ich bis vor kurzem mit einer modifizierten Include-Datei gearbeitet hatte, ist mir das beim testen gar nicht aufgefallen... Mit der aktuellen Version 1.28 sollte das Problem behoben sein. Um den Server hier nicht allzusehr zu strapazieren, verweise ich auf meine Webseite bzw. die BERLIOS Downloadseite: http://developer.berlios.de/projects/avr-chipbasic Der treiber für 128x64 GLCD ist leider noch nicht fertig, wird aber als nächstes in Angriff genommen. Jörg
Hallo Jörg, da ich in der Röhrenzeit meine ersten Elektronikerfahrungen gemacht habe, und Basic der Einstieg in die Computerei war, bin ich begeistert, was ein Chip alles kann. Großes Lob für das fundierte Projekt. Mit dem angegebenen Universal-Layout und der V.1.26 habe ich den Basic-Computer in Betrieb genommen. Display ein LC-TFT Monitor TM-70003A mit Video-Eingang. SW-Bild mit BAS-Signal ist ok, aber das Bild rollt langsam über den Bildschirm. Messung der Bildfrequenz ergab 15735,9 Hz (63,55us) statt 15625 Hz. Die Quarzfrequenz liegt bei direkter Messung mit einem Tastkopf einige 100 Hz tiefer. Gibt es eine Möglichkeit die geteilte Frequenz am Prozessor zu messen? Hat jemand zu meinem Problem einen Tipp? Karl-Anton
Hallo Karl-Anton, die 15735,9 Hz sehen mir sehr nach NTSC aus. Und wenn das Bild langsam durchläuft, könnte das an HSYNC statt CSYNC liegen. Kontrolliere deshalb bitte, dass keiner der beiden Jumper J2/J3 geschlossen ist und die beiden Pull-Ups an PC2 und PC3 dran sind. Jörg
Hallo Jörg, ohne Prozessor habe ich die Schaltung um die Video-Ausgabe nochmal mit dem Ohmmeter durchgemessen - alles ok. Nach dem Einschalten und ESC steht auf dem Startbildschirm: MCU:644, VID:NTSC, KBD:DE. Die gemessene Spannung an PC2 und PC3 beträgt aber 4.94V bei 5.00V Betriebsspannung. Der Monitor (Pollin) kann angeblich PAL und NTSC, eine Möglichkeit zum manuellen Umschalten habe ich aber noch nicht gefunden. Kann man über eine falsch programmierte Fuse diesen Effekt erreichen? Karl-Anton
Hallo Karl-Anton, ich habe es jetzt nochmal sowohl mit einem Mega644 als auch einem Meg644P versucht, beide zeigen PAL an, wenn kein Jumper gesetzt ist. Wichtig sind auf jeden Fall die beiden externen Pull-Ups, vielleicht mal auf z.B. 2K2 verringern. Und hole Dir bitte auf jeden Fall die aktuelle Version (1.28). @ alle Die .SYS Datei im Binärpaket ist die, über die man mit dem Bootloader ein Update machen kann. Gruß Jörg
Hallo Jörg, habe mit Erfolg Deinen PWM Treiber ausprobiert, er funktioniert sehr gut. Um jedoch ein RC Servo anzusteuern reicht die Auflösung von 8 Bit jedoch nicht aus. Bei der geforderten Impulsbreite von 1-2ms habe ich gerade mal 16 Einstellmöglichkeiten, was etwas wenig ist. Da das sicherlich für viele hier interessant wäre Modellbauservos anzusteuern möchte ich Dich fragen ob Du hier eine Möglichkeit siehst, eventuell mit einer Erweiterung des PWM Treibers. Gruss Roger
Hallo Roger, dazu müsste man einen neuen Treiber schreiben. Grund ist, dass bei dem eingesetzten Prinzip die Auflösung durch die Horizontalfrequenz vorgegeben wird. Man könnte nun die Pulserzeugung in die nicht sichtbaren Zeilen 270 bis 302 verlegen (geht nur mit PAL) oder nur 20 Text-Zeilen darstellen und dafür 32 Bildzeilen für die Pulserzeugung verwenden. Eine Pause zwischen den Impulsen von ca. 20ms sollte ja eigentlich nichts ausmachen. Möglich wäre es also schon, aber eben nur mit einem neuen Treiber... Jörg
Ich habe das mal mit den Taktzyklen durchgerechnet, das Ganze ist nicht ganz trivial. Letztendlich komme ich auf ca. 64 Einstellmöglichkeiten ohne Beeinträchtigung der anderen Funktionen (insbesondere Keyboard und seriell). Und dann wahlweise 4 oder 8 Kanäle. Für den Modellbau wären vielleicht auch Kombinationen interessant. Z.B. 2xServo out, 2xPWM wie beim jetzigen PWM Treiber und 6 I/O (wenn man BUSY und STROBE mit hinzunimmt) oder halt eine andere Kombination. Vielleicht gibt es ja noch mehr Anregungen, dann könnte ich mich mal drüber machen... Jörg
Angehängte Dateien:
-
644P.gif
12 KB
Hallo Jörg, das Scrollen ist weg! Trotz Versuchen mit der Hardware und Programmieren eines neuen 644P blieb der Effekt unverändert. Zufällig fand ich beim Stöbern in der readme bei den binaries die richtigen Fuse-Einstellungen und damit läuft alles prima. Vorschlag: In der Dokumentation "chipbasic2_1.28_doc" die Fuse-Einstellungen als eigene PDF für die Leute mit viereckigen Augen angeben. Unter Windows hatte ich Probleme beim Programmieren des 644P mit dem aktuellen PonyProg2000 - V. 2.07c Beta Jan 6 2008. Die P-Version des Prozessors 644 wird nur mit der alten Version 2.06g Beta Apr 25 2007 unterstützt!? Zur Anzeige dient mir neben dem TV ein LCD-Display mit 480x234 Bildpunkten. Dabei zappeln die Buchstaben wegen den nur 234 Zeilen teilweise zwischen den Zeilen hin und her. Gibt es dafür einen besseren Modus als 1?
Hallo Karl-Anton, das mit den Fuse-Einstellungen werde ich beim nächsten Update in die Doku mit reinschreiben, wahrscheinlich bei der Hardware. Ich selbst nutze zum Programmieren Avrdude (unter Linux), die von Dir geschilderten Probleme mit Ponyprog halte ich trotzdem für etwas seltsam. Die meisten kleinen LCD-Monitore lassen bei PAL einfach Zeilen aus. Bei manchen ist das statisch, bei anderen scheint das aber zu wechseln. Wenn man den Computer mit gesetztem NTSC-Jumper startet, sollte aber ein ruhiges Bild zu sehen sein. Sämtliche Auflösungen (außer dem ladbaren 24x40 Treiber) haben weniger als 234 sichtbare Zeilen. Gruß, Jörg
Hallo Jörg, vielen Dank für Deine Überlegungen bezüglich der Servoansteuerung. Ich denke dass eine Kombination wie von Dir vorgeschlagen insbesondere für diejenigen die etwas steuern wollen das richtige wäre. Vielleicht bekommst Du ja bei dem Kombitreiber wenigstens einen PWM Ausgang mit 14 oder 16 Bit hin, evtl. unter Verzicht auf einen Teil der Bildschirmausgabe.... Die Frequenz von ca. 61Hz passt ja, den Rest (Trimmung des Servo) kann man sich ja dann in Basic programmmieren. Gruss Roger
Hallo Jörg, noch ein kleiner Nachtrag: könnte man auf die Audioausgabe verzichten und das vielleicht mit dem Timer 2 hinbekommen? Gruss Roger
Hallo Roger, die Timer 2 PWM hat nur 8 Bit. Bei 50Hz Wiederholfrequenz hätte man eine zeitliche Auflösung von ca. 78 Mikrosekunden, Was im Zeitbereich von 1-2 ms ungefähr 13 Einstellungen erlaubt. Eine Lösung wären 64 Einstellmöglichkeiten über einen Videotreiber mit 20 Text Zeilen und das ganze mit relativ wenig Aufwand. Die zweite Möglichkeit wäre, den Interrupt über mehrere Zeilen auszudehnen und das Timing für diese Zeit "von Hand" im Treiber zu machen. Das ist aber nicht ganz einfach, dafür sollten im Bereich 1-2ms aber 256 oder gar 1024 Schritte drin sein. Jörg
Hallo Jörg, im Prinzip reichen 64 Einstellmöglichkeiten wahrscheinlich in den meisten Fällen, jedoch bekommt man das Servo dann bestimmt nicht mehr getrimmt ohne auf etliche Einstellmöglichkeiten zu verzichten wenn man die Endlagen genau einstellen will. Ich denke um eine Steuerung zu realisieren kommt man auch mit einem relativ abgespeckten Videotreiber aus, der Anzeigebedarf ist meist geringer, man könnte auch mit weniger als 20 Zeilen auskommen... Der vorhandene 4xPWM Treiber +4x IO ist schon gut und praktikabel, wenn ein oder 2 PWM Kanäle von der Auflösung her für Servos geeignet sind wäre das super. Gruss Roger
Angehängte Dateien:
-
Foto_V2.0_k1.jpg
52 KB
Hallo Jörg, mit NTSC-Treiber macht der Mini-BASIC-Computer richtig Spaß. Inzwischen habe ich auch mit KiCAD ein neues Layout mit zweiter Sub-D Buchse, zusätzlichem Hohlstecker, Chinch-Buchse und 16-Farb-Erweiterung fertiggestellt. Wichtig waren mir auch die 4 Befestigungslöcher an den Ecken. Die einseitige Platine im 1/2 Europaformat mit 15 Brücken auf der Bestückungsseite ist jetzt voll. Das Foto zeigt die V2.0, Erfahrungen beim Aufbau sind in die aktuelle V2.1 eingeflossen. Wenn gewünscht, lade ich die PDF's von Schaltplan, Layout und Bestückung und die Stückliste gerne hoch.
Hallo Karl-anton D., ich habe starke Interesse an die PDF's. Wollte einen ChipBasic-Bausatz für meinen Sohn machen. MfG
Hallo Karl-Anton, ich habe es nur kurz "überflogen", dabei ist mir etwas aufgefallen: die zweite Schnittstelle beim Mega644P sollte mit der Schaltung wie bei der ersten nicht funktionieren, da dafür das Eingangssignal invertiert werden muß. ein NPN-Transistor sollte eigentlich ausreichen. Jörg
Hallo Jörg, danke für den Hinweis. Einleuchtend, da der MAX232 die Signale invertiert. Die beim Zusammenlöten gemachten Erfahrungen habe ich in ein neues Layout V2.2 einfließen lassen, dieses habe aber noch nicht aufgebaut. Anbei Schaltplan, Layout, Bestückung, Stückliste und etwas Kommentar dazu als ZIP. Wer beim Schaltplan oder Layout Probleme sieht, bitte melden. Wenn sinnvoll, kann ich dann ja noch eine V2.3 erstellen. Karl-Anton
Hallo Jörg, eben habe ich mit dem Mode1-Oszi gepielt. Dabei fiel mir auf, dass die binary und die doc-Version nicht übereinstimmen und der Messbereich nur 2,5V statt 5V ist. Meine eigentliche Frage: kann man von der Basic-Oberfläche die Referenzspannung zwischen 1,1/2,5 und AVCC umschalten oder muss man direkt die Register poken? Gleiches gilt für die zuschaltbare Vorverstärkung.
Hallo Jörg, bei der 2. seriellen Schnittstelle sind in der Doku die folgenden Baudraten angegeben. n Bitrate (Bps) 0 1200 1 2400 2 4800 3 9600 (default) 4 19200 5 31250 (MIDI) 6 38400 7 57600 beim Senden zum PC mit ESPUT A (A=65 bis 89) und Einstellen der Baudrade mit EBAUD (2 Stoppbits) funktionieren die folgenden Werte: 1 1200 2 2400 3 4800 4 9600 6 19200 Höhere Baudraten fand ich keine. Sind diese noch nicht implementiert oder soll ich meine Hardware mal genauer untersuchen? Karl-Anton
Hallo Karl-Anton, anbei eine neue "Zwischenversion". Mit dem ADC hast Du recht, im Demoprogramm werden falsche Werte angezeigt. Die Standardeinstellung werde ich aber so lassen wie sie ist, da dann die bereits vorhandenen Programme unter Umständen nicht mehr richtig funktionieren. Aber ich habe die Funktion ein wenig erweitert, mit Werten von $100 bis $1FF kann nun das ADMUX Register direkt gesetzt werden. Die Baudraten sind wohl alle halb so groß wie beabsichtigt geraten. Das U2X1 Bit war nicht gesetzt. Allerdings habe ich momentan keine HW da, bei der ich das mal schnell ausprobieren kann. Jörg
Hallo Jörg, danke für die schnelle Antwort. Was mir noch gefallen würde, wäre eine Echtzeituhr mit Einbindug in Basic: z.B. DS1307 mit 3V Li-Bat. IC und Quarz hätten statt einem der beiden 24C512 noch Platz auf dem Board. Mit der Batterie wird es etwas eng. Lieferant Reichelt, passender Quarz mit 10 pF Lastkapazität lieferbar (+Trimmer 5pF) , IC z.Zt. nur als 8-pol SMD statt 8-pol DIL lieferbar. Karl-Anton
Hallo Karl-Anton, dafür brauchst Du Dir nur eine kleine Bibliothek zu schreiben und fertig. Das geht auch einfach in BASIC. Zum einem ist im RAM kein Platz mehr für die Systemzeit, zum anderen hat bei den RTC jeder seine Vorlieben, ich benutze meist die DS3232, die ist sehr genau und hat Temperatur- und Alterungskompensation und braucht keinen externen Quarz. Ist allerdings auch ein bisschen teurer, aber für Outdoor-Geräte optimal. @Roger Treiber habe ich angefangen, braucht aber noch ein bisschen Zeit, Auflösung wird wahrscheinlich bei ca. 300 Schritten im Bereich von 1-2ms liegen. Problem ist momentan die beiden anderen PWM Kanäle einigermassen jitterfrei zu halten und auch noch die serielle Schnittstelle zu bedienen, dazu muß das Timing auf den Takt genau stimmen und letztendlich noch in 3K reinpassen. Möglich sollte es aber sein... jörg
Hallo Jörg, beim Versuch, die auf dem Bildschirm angezeigten Werte im Sekundentakt zusätzlich über sie serielle Schnittstelle 1 auszugeben, habe ich ein Problem. Möglicherweise ein Formatierungsproblem, aber ich habe in der Referenz kein Beispiel gefunden. Kannst Du bitte mein angefangenes Programm mal anschauen? Karl-Anton
Hallo Karl-Anton, vielen Dank, ja, das liegt nicht an Deinem Programm, es war schlicht noch ein Fehler im System. Und zwar kam der durch die Erweiterung um Kanal 4 für die zweite serielle Schnittstelle, da ist das XL-Register nach dem POP nochmal benutzt worden. Also gibt es mal wieder eine neue Version... Jörg
Hallo Jörg, danke für die V1.30. Die Serielle Ausgabe läuft jetzt auf Anhieb. Mit dem anhängenden Programm läßt sich ein Temperaturprofil steuern. Die Datenpaare enthalten immer Zeit,Temperatur. In längeren Zeitabschnitten gibt es Probleme mit dem Integer-Zahlenbereich in Zeile 38. Bei Änderungen der Anzahl Datenpaare am Programmanfang auch in Zeile 54 die Zahl 10 anpassen. Für Erweiterungen sind noch 40 Zeilen frei. Karl-Anton
Nachtrag: Irgendwer hat die Zeile 33 versteckt - hier ist sie: 33 B=B/C:A=100-B/12:T=10*B/4 Karl-Anton
Hallo Jörg, beim Abspeichern des Programms auf dem PC über Seriell 1 wird die 12.Stelle vom Namen nicht übertragen - ist kein aktuelles Problem. Bei der Gelegenheit die weitere Programmvariante V1.2 + Doku. Der Schaltpunkt erfolgt jetzt durch Vergleich der Temperaturwerte (0-250) und nicht mehr der Kurvenpunkte. Noch eine generelle Frage: Gibt es weitere Anwendungsprogramme oder beschäftigt sich dieses Forum überwiegend mit der Systemprogrammierung? Karl-Anton
Hallo Karl-Anton, ich kann mir denken, woran das liegt. Irgendwann habe ich das Senden dahingehend geändert, dass die Programmnummer nicht mit übertragen wird. Der danach folgende Doppelpunkt und der Programm-Name sind aber 13 Zeichen... Werde ich mir heute abend mal ansehen. Zu Deiner Frage bezüglich Anwendungsprogrammen. Im Forum hier geht es mehr um den AVR-Code, in diesem Fall das, was Du als Systemprogrammierung bezeichnest. Für Anwenderprogramme, Bibliotheken etc. gibt es keine eigene Plattform und auch hier im Thread ist nur wenig davon zu lesen. Obwohl das Projekt gerade durch das erst in letzter Zeit neu hinzugekommene Treiber- und Bibliothekskonzept sehr viel Potenzial für verschiedenste Anwemdungen hat. Es gab schon mal Vorschläge für eine "Programmsammlung", herausgekommen ist aber dabei nichts, mir selbst ist der Aufwand dafür aber einfach zu hoch. Ich hab ehrlichgesagt keine Lust jeden Tag nach irgendwelcher Potenztablettenwerbung zu suchen um diese zu löschen, aus diesem Grunde gibt es auf meiner HP auch kein Gästebuch mehr. Jörg
Hallo Jörg, seit 10 Jahren betreibe ich zu meinem Vergnügen die Homepage von meinem Heimatdorf, so ist mir das SPAM-Problem leider auch bekannt. Ich stimme Dir zu, dass der 644P-Basic-Rechner eine interessante Basis für Steueraufgaben in der realen Welt bildet. Zum Spielen bietet mein alter Commodore mehr Möglichkeiten. Bis Widerspruch kommt, werde ich das eine oder andere an Hardware oder Programmen posten. Zum AVR-Code: Eine vorhandenes Netzgerät würde ich gerne mit einem dual 12-Bit DAC with SPI (MCP4922-E/P) ansteuern. Macht es viel Aufwand, einen Basic-Befehl (ähnlich TEMP() oder XPOKE X,Y) zu erfinden, um ein 16-bit-word über das 2-wire Serial Interface zu senden? Karl-Anton
Ich weiß zwar nicht ob das nicht vieleicht Zweckentfremdung ist aber könnte man nicht den SVN-Server von dem Forum benutzen um BASIC-Programme von User für User hochzuladen?
Hallo, passend zu meinem 644P-Basic-Board (s.o.) hier eine universelle einseitige Erweiterungskarte V1.0 im halben Europaformat mit Steckern und freier Lochrasterfläche. Einzelheiten siehe ZIP-File. Karl-Anton
Hallo Karl-Anton, SPI über das TWI geht zumindest hardwaremäßig nicht. Dazu müsste man das TWI abschalten und die Portpins PC0 und PC1 per Software steuern. I2C-Bausteine lassen sich dann aber nicht mehr nutzen. Besser wäre es, auch den SPI/ISP-Anschluß mit auf das Zusatzboard zu bringen, dann könnte man das mit der Funktion SPI() erledigen. Z.B:
1 | 10 OUT $200,$10 |
2 | 11 A=SPI(HI(C))*256+SPI(LO(C)) |
3 | 12 OUT $200,$FF |
gibt den Inhalt der Variable C mit msb zuerst auf die SPI-Schnittstelle aus. In Zeile 10 wird die Schnittstelle konfiguriert und SS auf LOW gezogen, in Zeile 11 findet der Datenaustausch statt (A=gelesener Wert) und in Zeile 12 wird SS wieder auf "1" gesetzt. Eine weitere Möglichkeit wäre ein "Soft-SPI-Treiber" für die parallele Schnittstelle. Jörg
Hallo Jörg, danke für die ausführliche Antwort. Da bin ich wohl den Abkürzungen zum Opfer gefallen. Die I2C=TWI(bei AVR) Schnittstelle habe ich für das beim IC MCP4922 angegebene SPI-Interface gehalten!? Mit einem Pfostenstecker im Lochrasterfeld kann ich die SPI-Schnittstelle problemlos auf das AddOn Board bringen und dank Deines Beispiels den DA-Wandler verwenden. Karl-Anton
Hallo Jörg, nochmal ein Versuch, Schnittstellen zu ergänzen. Bei Reichelt gibt es den 18Bit AD-Wandler MCP 3421A0T-E/CH mit I2C-Interface für gut 2€. Obwohl im 6-Pin SOT23-6, sollten sich die 2x3 Beinchen im 0,95mm Raster noch von Hand löten lassen. Macht es Sinn, dieses IC mit einem eigenen Basic-Befehl einzubinden? Karl-Anton
Hallo Karl-Anton, ich denke nicht, dass das sinnvoll ist. Die "TEMP()" Funktion für den LM75 ist eigentlich auch nur noch aus Kompatibilitätsgründen zu den Vorgängerversionen drin. Am System selbst will ich eigentlich auch nicht mehr als unbedingt notwendig ändern, Bugfixes sind da natürlich die Ausnahme. Die Gesamtanzahl aktueller Downloads und somit Nutzer hält sich in Grenzen und für mich reicht die Funktionalität bei weitem aus. Weitere Treiber und Bibliotheken wird es aber noch geben, auch wenn sich die Entwicklungsgeschwindigkeit zugunsten neuer Konzepte verlangsamen wird. Jörg
Hallo Jörg, schade, aber ich kann Deine Argumente verstehen. In der Doku zu V1.28 habe ich zum Thema Schnittstellen und Assembler nachgelesen. Dazu zwei Fragen: 1. In "interna.doc" unter "2.7 Adressbereich für I/O-Erweiterungen" sehe ich die Möglichkeit, mittels Binärprogramm weitere Schnittstellen einzubinden. Hast Du dazu weitere Infos (Beispiel?), denn so bin ich ziemlich ratlos. 2. Für die Erstellung von Binärprogrammen in der Windows-Welt mit Assemler/C bietet sich AVR-Studio 4 von Atmel an. Gesucht wir ein Profi, der ein Beispiel mit zugehörigem make-file für die Binärdatei mit 3072 Bytes und der erforderlichen Datenstruktur als Grundlage für eigene Applikationen zur Verfügung stellt. Genug der Wünsche! Danke Jörg für das tolle Projekt. Karl-Anton
Das is ja mal ein geniales Projekt ;) Ich würd gern Screenshots sehen, falls es jemand zufällig demnächst an einer Fernsehkarte angeschlossen hat.. Der Handheld interessietr mich auch sehr, bin gespannt, was draus wird ;)
Chris (fchriis) schrieb: > Der Handheld interessietr mich auch sehr, bin gespannt, was draus wird > ;) Geben tuts den Handheld schon ;)
@ Karl-Anton, die I/O Erweiterung läuft über einen Treiber auf Programmplatz 8. Hierzu gibt es zwei Einsprungadressen für IN() und OUT. Alle IN() und OUT Befehle mit Adressen ab 0x800 greifen auf diese Routinen zu, bei Adressbereichen die nicht bedient werden muß einfach nur das Fehlerregister auf 40 (NO IO DRIVER) gesetzt werden. Was man letztendlich mit den Befehlen realisieren will bleibt einem selbst überlassen, die Adressen für die 4 Erweiterungsmodule habe ich einfach erstmal willkürlich festgelegt. Eine Möglichkeit wäre z.B. ein über I2C angeschlossener Mega16, der dann weitere I/O zur Verfügung stellt. Anwendungsprogramme in C zu schreiben wird wahrscheinlich schwierig werden, mit einer C-Library die auf das API zurückgreift aber vielleicht nicht unmöglich. Beim AVR-Assembler muss man wohl die normale API-Include (ohne Makros) nehmen. Das build-bin Script lässt sich ja vielleicht durch eine passende Batch-Datei ersetzen. Da bei der Übertragung mittels X-Modem nur 3072 Bytes empfangen werden, sollte es auch möglich sein, im Assembler-Programm 3K Nullbytes an den Code hintenranzuhängen. Die Übertragung der dann vllt. 5K großen Binärdatei wird halt vach 3K vom ChipBasic2 abgebrochen. @ Chris Screenshots mit einer Fernsehkarte sind aber nur s/w, da kein Composite-Signal erzeugt wird. Der Handheld existiert schon (es gibt auch einen Thread dazu) wird aber von mir weder weiterentwickelt noch dokumentiert. Deshalb ist er auch auf meiner Homepage nicht zu finden. @ Roger Treiber ist in Arbeit, es ist aber nicht ganz einfach da ich den Code für Sound, Keyboard und Seriell in kleine Stücke "hacken" muss. Auflösung sollte etwa 250 Schritte im Bereich von 1-2ms sein. Jörg
Den Treiber habe ich heute testen können, er funktioniert auch soweit. Es gibt lediglich einen kleinen Jitter um ca +- 3 Taktzyklen aber damit müsste man leben können. Auflösung bei den beiden Pulskanälen ist 4µs (0-2240µs), dazu gibt es noch zwei PWM-Kanäle (wie bei den anderen PWM-Treibern) und 6 normale I/O. Den Code muss ich noch ein bisschen aufräumen und die Doku fertig machen. Ich kann ihn im Laufe der Woche vorab veröffentlichen, ansonsten ist er beim nächsten Release mit drin. Jörg
Hallo Jörg, vielen Dank für deine Mühe und Zeit die Du in diesen Treiber gesteckt hast, ich bin schon sehr gespannt ihn mit einem Servo auszuprobieren. Ich werde dann hier berichten. herzlichen Dank Roger
Hier ist mal die aktuelle Version zum Test, sollte auch mit der Version 1.28 gehen. Hinter der Funktionsbeschreibung stehen immer die I/O Adressen für OUT und IN()
1 | D0-D3 als I/O nutzbar (0x800-0x803 Daten, 0x810-0x813 Datenrichtung) |
2 | D4 Pulsausgang 0 (0x900) |
3 | D5 Pulsausgang 1 (0x901) |
4 | D6 PWM-Ausgang 0 (0x902) |
5 | D7 PWM-Ausgang 0 (0x903) |
6 | STROBE als I/O nutzbar (0x808 Daten, 0x818 Datenrichtung) |
7 | BUSY als I/O nutzbar (0x809 Daten, 0x819 Datenrichtung) |
Die PWM-Kanäle gehen, wie bei den anderen PWM Treibern von 0-255, die Pulsausgänge von 0-559 bei einer Auflösung von 4µs. Bildschirmausgabe entspricht dem Mode 0, allerdings sind nur 20 Zeilen je 28 Zeichen sichtbar. Jörg Wie ich gelesen habe, gibt es bei AVRA einen neuen Projekt-Admin. Damit sollte auch bald der auch ATmega644(P) von der offiziellen Version unterstützt werden.
Da sich niemand über den Treiber beschwert hat nehme ich mal an dass er so funktioniert. Das nächste Release wird wohl noch ein bisschen brauchen, da insbesondre die Doku überarbeitet und erweitert werden muss. Das System unterstützt jetzt bis zu 8MB externes RAM am Parallelport, realisiert habe ich aber nur ein 64K-Modul mit zwei SRAM und einem CPLD. Letzteres ist notwendig, um bei nur 10 Leitungen (D0-D7, Strobe und Busy) einen vernünftigen Speicherdurchsatz zu ermöglichen. Damit sind dann sogar 320x240 Pixel in 16 Farben möglich, allerdings bei derzeit saumäßiger Performance. Momentan arbeite ich auch noch an einem 8080 Emulator, um vielleicht den CP/M Emulator aus Beitrag "CP/M auf ATmega88" auch auf dem ChipBasic2 System ans Laufen zu bekommen. Hier schon mal ein paar vielversprechende Benchmark-Resultate, die sich auf die im o.g. Thread bezogene Tests beziehen. Getestet habe ich mit abgeschaltetem Video (VID 0), im Videomode 0 (PAL) und in einem neuen monochromen Textmode mit 24 Zeilen zu je 60 Zeichen.
1 | Test Messwert VID 0 Video Mode 0 24x60Z Video |
2 | ------------------------------------------------------------- |
3 | erster 8080 Speed 3,604MHz 1,201MHz 1,441MHz |
4 | zweiter Laufzeit 2,6s 7,8s 6,4s |
Desweiteren wird es wohl eine Art "Fortsetzung" mit dem ATMega1284P geben, allerdings mit etwas anderen Konzepten. Jörg
Halloe. Erstmal natürlich gratz zu so einem tollen Projekt. Wirklich mal was nettes zum Nachbauen und experiementieren. Nun aber auch gleich zu meinen "dummen" Frage. Hat von euch schonmal jemand den UNI- Video zu SCART Adapter nachgebaut ? Ich wundere mich gerade über die Belegung des Steckers. Wenn man in der Tabelle schaut müssten die Pins 1-3 erst Blau, dann Rot und zum schluss auf Pin 3 grün als Farbe haben. Wenn ich nun aber in der Wickipedie nach SCART suche, finde ich für den Scart anschluss eine belegung, nach der die Kanäle Rot und Grün in der Abbildung des Scart adapters vertauscht zu sein scheinen. Siehe hier http://de.wikipedia.org/wiki/SCART bzw. hier http://www.jcwolfram.de/projekte/avr/chipbasic2/hard.php Ist da evtl. in Wolframs abbildung ein Fehler drinn, oder irrt sich der Wikipedia eintrag ? Ich kann das ganze leider nicht mal so eben ausprobieren, ohne gleich ne Stange Geld in die Hand zu nehmen. Ich habe aus den Vorlagen eine neue Platine designt, auf der unter anderem die SCART- Buchse gleich mit drauf ist. Und es wäre echt schade, wenn ich da eine Platine praktisch umsonst mache nur weil die SCART- Belegung evtl. einen Fehler hat. Freundliche Grüße Frank
Hallo, bin z.Zt. in Urlaub. Es kann schon sein, dass noch Fehler in den Zeichnungen sind. Jörg
Halloe. Um meinen Eigenentwurf mal auszuprobioeren habe ich den SCART- Anschluss, einen BAS-Anschluss (Chinch) und den Keyboardanschluss mal auf einer Laborkarte zum Test aufgebaut. Über den Chichausgang bekomme ich auf einem alten 1084S Monitor ein sauberes Graustufenbild zu sehen. Die BAS- Signalgenerierung scheint also zu klappen. Wenn ich aber versuche die Schaltung an meinen Philips- Röhren-Fernseher (Model 28PT440801) über SCART anzuschließen sehe ich zwar das er versucht ein Farbsignal auszugeben. Jedoch scheint sich das TV nicht auf das BAS- Signal zu synchronisieren. Es flackert alles wild hin un her. Mein Controller ist ein 644 (nicht P) und die Softwareversion 1.30 hier aus dem Forum. Vorgegangen beim Nachbau bin ich praktisch 1:1 nach dem Schematas auf der Homepage zum UNI-Video-Anschluss. Zum Test habe ich auch mal den Rot und den Grünkanal getauscht, was jedoch für den SYNC keine verbesserung brachte. Hatte die hoffnung das der Controller SYNC-ON-GREEN evtl. mit unterstützt und nur wie oben beschrieben ein Fehler in der Beschreibung des SCART-UNIVIDEO Adapters drinn ist. ( p.s. Wenn man das Schema des UNI-Adapter mit dem Schema des direkten Scart anschlusses genau vergleicht kommat man darauf das Rot und Grün in beiden Abbildungen vertauscht sind.) Habt ihr vieleicht einen Tip für mich, wie ich das ganze doch noch ans laufen unter PHILIPS-RGB-SCART bekomme ? Grüße Frank
Hallo Frank, im Schaltplan sind offenbar Ein- und Ausgänge vertauscht (das allerdings konsequent ;) ) Lt. Wikipedia ist der FBAS-Ausgang Pin 19 (und nicht 20). Für RGB sind Ein- und Ausgang jeweils derselbe Pin, deswegen kommt die Farbe wohl durch. Also einmal Pin tauschen, gucken - und berichten. Gruß, DetlevT
Detlev T. schrieb: > im Schaltplan sind offenbar Ein- und Ausgänge vertauscht (das allerdings > konsequent ;) ) Lt. Wikipedia ist der FBAS-Ausgang Pin 19 (und nicht > 20). Für RGB sind Ein- und Ausgang jeweils derselbe Pin, deswegen kommt > die Farbe wohl durch. Hm, das klingt irgendwie komisch. So wie ich das aus der WIKI beschreibung heraus gelesen habe ist der PIN20 schon ok. Der AVR sendet über die RGB- Kanäle sie "Farbinformationen" an den Fernseher. Da aber für RGB keine eigenen SYNC- Kanäle vorhanden sind, zieht sich der Fernseher den SYNC aus dem FBAS- Signal das man zusätzlich an PIN 20 anlegen muss. Zitat aus dem Wiki:
1 | Da auf den RGB-Leitungen 7, 11 und 15 keinerlei Impulse zur Bildsynchronisation mitgesendet werden |
2 | (außer beim sogenannten „Sync-on-Green“-Modus, der bei einigen Geräten aktiviert werden kann [s. Manual]), |
3 | bedient sich der Empfänger zur Synchronisation im RGB-Modus (also bei angelegter RGB-Schaltspannung (Pin 16)) |
4 | des zusätzlich mitübertragenen Signals am Videoeingang (Pin 20). |
5 | |
6 | In den meisten Fällen werden dort nicht nur die benötigten Synchronimpulse, sondern ein vollwertiges FBAS-Signal übertragen, |
7 | so dass auch Geräte, die kein RGB annehmen können (vor allem Videorecorder), problemlos arbeiten können. |
Hier ist eine etwas andere Schaltung, bei der auch PIN20 als SYNC eingang genutzt wird. Beitrag "einfache Grafikkarte mit 256x252 und 256 Farben für AVR" In dieser Schaltung wird jedoch nicht das komplette FBAS- Signal erzeugt sondern nur ein Composite-SYNC (HSYNC+YSYNC). Meine aktuelle Vermutung liegt darin, das der Philips evtl. nicht richtig synchronisiert, weil er im RGB- Modus entwerder den Sync auf dem Grünen Kanal erwartet und FBAS gar nicht auswertet. Oder er verlangt im RGB- Modus nach einem composite- Sync Signal auf dem FBAS- Eingang und nicht das vollständige Signal. Mangels detailieter technischer Anleitungen zu dem Fernseher konnte ich diese vermutungen jedoch noch nicht bestätigen. RGB an sich solte der Fernseher können, den mein DVB-T Receiver läuft derzeit auf dem Fernseher im RGB- Modus. Und wenn ich den auf RGB umstelle merkt man auch deutlich ne Bildverbesserung. Da sollte alos nix defekt sein denke ich. Ich deneke auch nicht, das es am Kabel liegt. Das hat alle 21 Pole beschaltet und ist nicht übermäßg lang. Grüße Frank
Hallo. Detlev's anmerkung war doch nicht so falsch, wie ich angenommen habe. Ich habe sebst beim recherchieren gerade rasu bekommen, das ich wohl evtl. einem kleinen Fehler zum opfer gefallen bin. Die Beschreibungen auf Joergs Homepage gehen davon aus, das man sich ein SCART- Kabel basteln möchte. Ich habe jedoch eine Scart- Buchse angeschlossen und ein handelsübliches Scart Kabel daran angeschlossen. Was ich bis eben nicht wusste ist, das bei diesen Kabeln üblicherweise intern die Pins 19 und 20 über Kreuz verbunden sind. Daher kommen meine SYNC- Signale wohl beim Fernseher am falschen PIN an. Werde das heute abend mal Prüfen, aber ich denke das wird bei meinem Aufbau das Problem gewesen sein. Freundliche Grüße und Danke für den Tip Frank
Frank Zoll schrieb: > Hallo. > > Detlev's anmerkung war doch nicht so falsch, wie ich angenommen habe. > Ich habe sebst beim recherchieren gerade rasu bekommen, das ich wohl > evtl. einem kleinen Fehler zum opfer gefallen bin. Halloe. Es war genau so wie gedacht. Wenn man nicht, wie von Jörg beschrieben, ein Scart- Kabel machen möchte, sondern eine Scart Buchse, muss man das BAS- Signal der Schaltung nicht auf PIN 20 sondern auf PIN 19 aufbringen ! Nach einer kleinen Änderung an meiner Testplatine habe ich nun ein einwandfreies Bild. Freundliche Grüße Frank
Angehängte Dateien:
-
avr_basic_platine.jpg
88 KB
Er läuft. Nachdem ich nun nicht nur die Videoleitungen auf die richtigen Pins der SCART- Buchse gebracht habe, sondern auch noch die Audio Leitungen auf die richtigen Pins umgelegt habe, läuft alles wie es sollte. Anbei mal ein Foto meiner Version der Platine. Wie man sieht, habe ich nicht nur die Scart und Chinch Buchsen für Video und Audio gleich mit drauf gebracht, sondern das ganze auch noch ein klein wenig erweitert. Zusätzlich zu finden sind. - Ein kleines "Netzteil" für die 5 Volt Spannungsversorgung. - Eine Echtzeituhr auf dem I2C Buss ( Chip ist der DS1307 ) - Ein einfacher Mono- NF- Verstärker für einen Kopfhöreranschluss. Im momment schreibe ich herade ein kleines Demoprogramm für die Echtzeituhr. Dabei hab ich jedoch noch ein Problem. Der Befehl ASK V,n tut irgendwie nicht so, wie er sollte. Den Parameter n scheint er völlig zu ignorieren. Egal was ich für n angebe er fängt immer an Arraypostion 0 an. Und nach der Anzeige der Abfragebox kommt bei mir immer ein Syntaxfehler. Was ich auch sehh merkwürdig finde ist das Verhalten bei Berechnungen. B = B& $03 Funktioniert wie erwartet. B = B & $03 Meldet einen Syntaxfehler. B = B * 10 ebenso einen Syntaxfehler. Ist das so normal für den Interpreter ? Bei der von mir verwendeten Firmware handelt es sich um die Version 1.30 hier aus dem Forum. Die älteren Versionen hab ich noch nicth getestet, wollte gleich mit der aktullen anfangen. Freundliche Grüße Frank
Hallo Frank, mit der aktuellen Version (Hexfile im Anhang) sollten die Probleme behoben sein. Das Ganze ist wohl bei der letzten "Code-Spar-Aktion" passiert. Eine neue Version ist eigentlich fertig, allerdings müssen noch ein paar Dinge im Dateisystem an das Nachfolge-System angepasst werden. Wenn ich nächste Woche aus dem Urlaub zurück bin gibt es auch das vollständige Release mit Source. Jörg
Ich habe die neue Version mal kurz angetestet. Der ASK- Befehl tut nun wieder was er sollte, ohne Syntaxfehler. Auch einfache Rechenoperationen laufen wieder. A = A * 10 geht nun wieder. Es scheinen aber leider neue Folgefehler aufgetaucht zu sein. Das Programm Racer bricht in Zeile 12 mit der Fehlermeldung "WRONG EXPRESSION" ab. 12 Q=Q+1:IF Q=3 D=1-RND(3):Q=0 Das Programm Pong V0.2 bricht in Zeile 9 ebenfalls mit dem Fehler "WWRONG EXPRESSION" ab. 09 IF (Y=0)#(Y=22= NO 20:F=F-F:y=Y+F Ich würd sagen, schaus Dir einfach nach deinem Urlaub mal in Ruhe an, das ganze hat ja keine Eile. Freundliche Grüße Frank
Hallo Frank, das ist leider eine logische Folge, wenn Leerzeichen in Ausdrücken erlaubt sind. Beim Pong kommt noch hinzu, dass der Fehler eigentlich in Zeile 8 steckt, aber die fehlgeschlagene IF Anweisung den Zeiger schon auf die nächste Zeile gesetzt hat. Abhilfe ist, nach dem IF folgenden Ausdruck ein THEN oder einen Doppelpunkt zu setzen. Wenn der Expressions-Parser nicht bei einem Leerzeichen abbricht, versucht er bei
1 | IF C>10 C=10 |
aus dem gesamten nachfolgenden Text einen Wert zu berechnen, was natürlich keinen Sinn ergibt. Erst ein neues Schlüsselwort, Doppelpunkt, Komma, Semikolon oder das Zeilenende signalisieren das Ende des Ausdrucks. Also einfach in Zeile 12 bzw. 8 nach dem Audruck in der IF Anweisung einen Doppelpunkt setzen und die Programme sollten wieder funktionieren. Jörg
Da die Doku noch nicht ganz fertig ist, es gibt jetzt auch eine einfache Suchfunktion im Editor, die man mit (linkes) CTRL+F aufrufen kann. Mit ENTER gelangt man zur nächsten Fundstelle, mit ESC wird die Suche abgebrochen. Für das "Nachfolgeprojekt" existiert mittlerweise schon ein Prototyp. Das Ein-Chip-Konzept habe ich dabei aufgeben müssen. Verbaut sind ein ATMega1284P mit 20MHz, ein ATMega328P mit 16MHz und ein XC9572 CPLD. Ausgabe kann wahlweise auf gängige monochrome 320x240 LCDs ohne eigenen Controller (8 Graustufen, ca. 130Hz Frame-Frequenz), VGA und TV (8/16 Farben) erfolgen. Insgesamt wird es nur 4 Videomodi geben: - 20 Zeilen a 40 Zeichen Text (Font 8x12 Pixel im RAM) - 24 Zeilen a 40 Zeichen Text (Font 8x10 Pixel im RAM) - 320x240 Grafikmodus, Vorder-/Hintergrundfarbe für jeweils 8x6 Pixel - 160x120 Grafikmodus, 16 Farben je Pixel Die rechnerisch ermittelte "effektive Taktfrequenz" liegt bei allen Modi über 5 MHz, Sound und zusätzliche I/O werden auf den zweiten Controller ausgelagert, der über I2C angeschlossen ist. Jörg
Wieso nimmst du nicht einfach einen kleinen <10€ FPGA als Grafikchip? Dann kann man DIL zwar gänzlich vergessen, dafür hat man aber nur noch einen µc und kann gänzlich auf 3.3 Volt setzen. Und das ganze könnte sogar Farbe per FBAS. ;)
Hallo Bernd, die Gründe, es nicht so zu machen: Bei den meisten Dingen wo ich das ChipBasic einsetze läuft das "Drumherum" auch mit 5V. Außerdem mache ich meine Leiterplatten selbst und da ist zweilagig einfach ein Krampf. Es gibt ja schon eine Grafikkartenlösung mit FPGA, allerdings ist da auch nichts mit "<10€". Da das Projekt Open Source ist, kann sich ja jeder das modifizieren wie er möchte. Die zuletzt von mir beschriebene Lösung habe ich zwar aufgebaut aber mittlerweise wieder verworfen und favorisiere einen anderen Weg. Dazu vielleicht später mehr. Jörg
Angehängte Dateien:
-
ch8_car.png
721 Bytes
Hallo, nach langer Zeit ist es endlich soweit, das nächste offizielle Release ist da: http://www.jcwolfram.de/projekte/avr/chipbasic2/main.php Neben Bugfixes, neuen Funktionen und Treibern habe ich die Schnittstellen für Bibliotheken und Treiber angepasst, so können jetzt zuätzliches RAM sowie eigene BASIC Befehlserweiterungen eingebunden werden. Als Binär-Programm ist u.a. auch ein Chip8-Interpreter mit dabei. # Die Shift-Befehle teilweise durch Shift-Operatoren (<<, >>) ersetzt # XOR-Operator ^ # Unterstützung von bis zu 64 KBytes externen Speicher am Parallelport # bei den PWM-Treibern lassen sich BUSY und STROBE als I/O nutzen # neue Videotreiber # Monitor aus allen Videomodi heraus aufrufbar (eingeschränkt) # Erweiterbarkeit des BASIC um zusätzliche Befehle # erweitertes ADC-Setting über den Parameterbereich 0x100 ...0x1ff # erweitertes Bitraten-Setting für die zweite serielle Schnittstelle # Korrekturen und Erweiterungen in der Dokumentation # Beispiel-Programme überarbeitet # erweitertes API Bei den UI-Befehlen (ALERT,ASK) hat sich die Syntax etwas geändert, die Beispielprogramme sind entsprechend angepasst. Jörg
Leider sind mir im Build-Script für die Dokumentation und im Upload-Script je ein Fehler unterlaufen. Zum Ersten war beim Punkt "Library" die Fixlib zweimal hintereinander vertreten und zum Zweiten wurden die Bilder auf der Webseite nicht aktualisiert. Da ich aus Lizenzgründen keine Chip8-Programme mit in die Packages aufnehmen kann, hier schon mal das CAR-Programm zum Screenshot aus dem vorigen Post. Benötigt werden: - Das aktuelle System v1.36 - Der Chip8-Interpreter auf Programmplatz 2 - ein IRAM2-Treiber auf Programmplatz 8 Gesteuert wird mit den Cursor-Tasten. Jörg
Gibt es eigentlich auch Pläne normale LCD-Displays und SD-Karten zu verwenden?
@sepp Was sind für Dich "normale" LCD Displays? Für Text- und einfache Grafikdisplays (128x64 und 320x240) gibt es ja bereits Treiber. Wenn Du Laptop-Displays meinst, da ist der AVR einfach überfordert. Der "Nachfolger" (so er denn noch veröffentlicht wird) kann auch VGA und besteht aus einem kleinen Daughterboard mit ATMega1284P und einem CPLD und wird einfach in den Sockel des ChipBasic Computers gesteckt. Das Thema SD-Karte ist zwar interessant, aber ich sehe keinen besonderen Vorteil darin. Vom Preis her ist ein Dataflash Baustein doch ein Stück günstiger. Außerdem könnte man die Karte nur schwerlich zum Datenaustausch mit dem PC nutzen, denn für ein FAT Dateisystem sind die inneren Strukturen des ChipBasic Computers nicht ausgelegt. Über eine BASIC-Erweiterung in einer Bibliothek könnte man aber das zumindest für Userdaten nachrüsten, sofern knapp 3K ausreichen und jemand sich findet, der das macht. Jörg
Joerg Wolfram schrieb: > Was sind für Dich "normale" LCD Displays? Für Text- und einfache > Grafikdisplays (128x64 und 320x240) gibt es ja bereits Treiber. Ja, ich meinte die 0815 Billig-GLCD. Dass es dafür Treiber gibt hatte ich überlesen. Joerg Wolfram schrieb: > Das Thema SD-Karte ist zwar interessant, aber ich sehe keinen besonderen > Vorteil darin. Vom Preis her ist ein Dataflash Baustein doch ein Stück > günstiger. Wenn man Euro pro Byte vergleicht, sind normalerweise die SD-Karten günstiger und vor allem leichter zu bekommen. Man kann aber auch mit einem AVR einen kleinen SD-UART, SD-I2C oder SD-SPI Adapter bauen. Was mich interesiert ist, inwieweit die Programme/ Software vom AVR-ChipBasic2 und AVR-Handheld kompatibel sind.
Die Treiber überarbeite ich gerade, damit man noch zusätzlich Tasten anschließen kann, ohne die restlichen 4 Portpins benutzen zu müssen. Aus diesem Grund wird es auch einen neuen (zusätzlichen) Treiber für die 128x64 GLCD geben, der auch nur die oberen 4 Pins von Port A benutzt. Mit den Euro pro Byte ist die SD-Karte auf jeden Fall günstiger, da Massenprodukt. Allerdings könnte mein Dateisystem nur einen Bruchteil der verfügbaren Kapazität nutzen. Aber als Option werde ich es für einen eventuellen Nachfolger in Betracht ziehen, wobei ich am Dateisystem selbst nichts ändern werde sondern nur das physische Medium wählbar. Für einen Umbau der internen Strukturen auf MINIX/EXT/FAT/sonstnochwas sehe ich derzeit keinen Grund, der den Aufwand rechtfertigen würde. Un nun zum Handheld. Das Teil ist weder zum aktuellen BASIC kompatibel noch wird es weiterentwickelt. Damit ist das Thema aber noch nicht erledigt. Ich habe eine Bibliothek in Arbeit, mit der man mit dem "normalen" CB2 einen in etwa vergleichbaren Handheld bauen kann. Wobei die Programme auch auf dem ChipBasic2 laufen können. Aber das braucht noch etwas...
Joerg Wolfram schrieb: > Die Treiber überarbeite ich gerade, damit man noch zusätzlich Tasten > anschließen kann, ohne die restlichen 4 Portpins benutzen zu müssen. Aus > diesem Grund wird es auch einen neuen (zusätzlichen) Treiber für die > 128x64 GLCD geben, der auch nur die oberen 4 Pins von Port A benutzt. Dass sind gute Informationen Joerg Wolfram schrieb: > Mit den Euro pro Byte ist die SD-Karte auf jeden Fall günstiger, da > Massenprodukt. Allerdings könnte mein Dateisystem nur einen Bruchteil > der verfügbaren Kapazität nutzen. Aber als Option werde ich es für einen > eventuellen Nachfolger in Betracht ziehen, wobei ich am Dateisystem > selbst nichts ändern werde sondern nur das physische Medium wählbar. Für > einen Umbau der internen Strukturen auf MINIX/EXT/FAT/sonstnochwas sehe > ich derzeit keinen Grund, der den Aufwand rechtfertigen würde. Wie währe es, wenn man die SD-Karte auf dem PC "formatiert"? Also Ordner / Dateien mit einer festen Größe an einer bestimmten Position im Speicher anlegt und dann mit dem AVR direkt auf die SD Karte schreibt. Somit hätte man einen Speicher für extrem umfangreiche Programme bzw. viele kleine Programme zur Verfügung ohne sich mit dem FAT-Dateisystem befassen zu müssen. Und zusätzlich kann man die Karte direkt am PC verwenden. Oder müsste man für soetwas zu viel am System ändern? Joerg Wolfram schrieb: > Un nun zum Handheld. Das Teil ist weder zum aktuellen BASIC kompatibel > noch wird es weiterentwickelt. Damit ist das Thema aber noch nicht > erledigt. Ich habe eine Bibliothek in Arbeit, mit der man mit dem > "normalen" CB2 einen in etwa vergleichbaren Handheld bauen kann. Wobei > die Programme auch auf dem ChipBasic2 laufen können. Aber das braucht > noch etwas... Genau sowas suche ich schon die ganze Zeit. Denn ich brauche einen kleinen Handheld um unterwegs die verschiedensten Bussysteme / Schnittstellen überprüfen und ansprechen zu können.
Möglich wäre das schon, allerdings sehr aufwändig. Dazu könnte man 256 Dateien mit der maximalen Dateigröße von 128 +1 Pages anlegen, wobei man von den 512 Bytes einer SD-Page nur 256 nutzen kann. Einfach deswegen weil die interne Pagegröße auf 256 Bytes festgelegt ist und auch FREAD und FWRITE damit arbeiten. Lesen ginge ja noch, aber zum Schreiben müsste man zumindest eine Hälfte der zu schreibenden 512-Bytes Page irgendwo zwischenspeichern. Da aber keine 256 Bytes mehr frei sind, müsste man z.B. temporär Teile des Bildschirmspeichers nutzen. Oder man nimmt halt eine Fragmentierung auf der SD-Karte in Kauf. Ein weiteres Beispiel wäre z.B. das Inhaltsverzeichnis. So etwas gibt es beim ChipBasic Dateisystem überhaupt nicht. Der Dateiname mit 12 Zeichen steht am Anfang der Datei. Alles in Allem ein großer Aufwand mit fraglichem Nutzen (zumindest für mich). Für USER-Dateien steht, wie oben schon angedeutet, die Möglichkeit einer Realisierung über eine Binärbibliothek offen. Jörg
In der nächsten Version werden die grundlegenden Funktionen des Dateisystems (Page lesen/schreiben...) auch in Bibliotheken auslagerbar sein. An der Struktur des Dateisystems selbst wird es allerdings keine Änderungen geben, unter anderem wegen der Kompatibilität zu den bestehenden Systemen, die teilweise den DataFlash aufgelötet haben. Dann könnte man das Dateisystem z.B. in eine große Datei auf einer wie auch immer formatierten SD-Karte packen. Bei 256 Dateien a max. 32KBytes und nur halber Ausnutzung der SD-Pages käme man dann auf 32MByte/Datei. Über eine Art "Dateimanager", der die Pages wieder richtig zusammensetzt könnte man dann auch auf dem PC recht bequem mit den Daten arbeiten. Bei dem momentan recht niedigem Interesse an dem Projekt halte ich es aber eher für unwahrscheinlich, dass jemand eine ChipBasic Bibliothek und ein passendes Programm für Windows schreibt. Damit man nicht immer umstecken muss und auch noch andere SPI-Gerätschaften anschliessen kann, wird es einen "SPI-Extender" mit maximal 8 Select-Leitungen geben, den man auch aus dem BASIC heraus ansprechen kann. Damit wären dann auch z.B. CAN oder Ethernet möglich. Dafür wird aber der Bootloader rausfliegen, aber eventuell bekomme ich den noch in das Loader-Programm wieder mit hinein. Mit abgeschaltetem Video-Interrupt sollten dann auch höhere Bitraten für das System-Update möglich sein. Jörg
Dass ist wirklich interessant. Wird sich etwas an der maximalen UART-Geschwindigkeit ändern? Denn die meißten Module, die ich mit dem AVR-ChipBasic2 auswerten würde, haben eine fixe Bitrate von 9600bps
Bei "System-UART" lässt sich die Geschwindigkeit nicht erhöhen, da als Zeitbasis die Zeilenfrequenz dient. Allerdings kann man den UART1 des Mega644P verwenden (EBAUD,ESPUT,ESGET). Dafür muss aber der RX-Pin der System-Schnittstelle anstelle ursprünglich PD3 auf PD1 gelegt werden (sowohl physisch als auch in der Config-Page). Jörg
Hallo, nach längerer Ruhepause gibt es mal wieder ein neues Update. Den angekündigten "SPI-Extender" habe ich letztendlich nicht mehr realisiert, die Schnittstelle für andere Dateisysteme ist vorhanden aber nur im Sourcecode dokumentiert. Neben Aufräumarbeiten bei den Treibern gibt es eine neue Bibliothek, mit der auf recht einfache Weise z.B. ein R-D-C-L Meter aufgebaut werden kann. Ein 8080 Emulator ist auch dabei, allerdings noch nicht vollständig getestet. Da Berlios am Ende des Jahres schließt, wird es in Zukunft nur noch Downloads über meine Homepage geben. http://www.jcwolfram.de/projekte/avr/chipbasic2/main.php Viel Spaß damit, Jörg
Hallo Jörg, Ich habe Deinen AVR-Basic_Computer nachgebaut. Das ist ein tolles Projekt. Danke. Es läuft nur die serielle Schnittstelle nicht. Es kommen Zeichen an, aber nicht lesbar. Einstellung: 2400 8N2. Ist auch eine SD-Karte als Datenspeicher vorgesehen ? Gruß Manfred
Hallo Manfred, schau mal, ob bei den Einstellungen (Config-Menü) die Serielle Schnittstelle auf "simple" steht wenn Du die angegebene Schaltung benutzt. Die Einstellung "standard" ist für den Anschluß vom MAX232 oder USB-TTL Wandlern gedacht. SD-Karte ist nicht vorgesehen, allerdings gibt es intern Schnittstellen um eigene (ladbare) Dateisystemtreiber zu einzubinden. Ob sich da aber jemals jemand die Mühe macht, wage ich zu bezweifeln. Gruß Jörg
Hallo Jörg, Die Schnittstelle steht auf simple, ich werde nochmal testen. Wie kann ich auf die EEPROMS zugreifen? Gruß Manfred
Im Config-Menü muss die I2C Adresse des EEPROMS eingestellt werden, im BASIC geht es dann mit XPOKE / XPEEK() für externe und EPOKE / EPEEK() für das interne EEPROM Gruß Jörg
Angehängte Dateien:
-
Comm.JPG
150 KB
Hallo Jörg, Ich habe die Comm-Schnittstelle noch einmal auf verschiedenen PC getestet. Com mit USB-Seriall_Adapter und richtige Com. Auch mal andere Einstellungen getestet. Es kommt immer beim Starten des Serial-Loaders der selbe String. siehe Bild. Ich denke mit den Zeiten stimm etwas nicht. Kannst Du bitte noch mal schauen. Oder hast Du ein Testprogramm ? Gruß Manfred
Probier mal ein anderes Terminalprogramm.... So schön HTerm auch ist, ich hatte in dieser Richtung damit schon Probleme. Viele Grüße, egberto
Da sich wahrscheinlich niemand daran gemacht hat oder machen wird, ein Dateisystem für SD-Karten für den BASIC-Computer zu entwickeln (ich sowieso nicht), werde ich in der nächsten Version die Schnittstelle aus Platzgründen wieder entfernen. Dafür wird es dann einen SCOMM (analog zu ICOMM) Befehl geben. Gruß Jörg
Hallo, welche Schnittstelle meinst du jetzt ? Frage: Kann man die ASM nicht so umgestalten , das sie auch mit dem avrasm32.exe funktionieren ? Wäre eine gross Hilfe. Die ZX81-ASM funktionieren nach Umgestaltung mit dem avrasm32.exe, dank der Hilfereichen arbeit. Danke. gruss
Die Schnittstelle ist nur im Code (spärlich) dokumentiert, in der Datei libdef.asm sind die Eintrittspunkte im Treiber definiert, die Aufrufe finden in der Datei filesys.asm statt. Damit könnte man einen ladbaren Dateisystemtreiber realisieren, den internen Dataflash Treiber zu ersetzen ist nicht vorgesehen. Eine Umgestaltung der Sourcen kommt für mich nicht in Frage, durch Verzicht auf die ganzen Makro- und anderen Fähigkeiten von Avra würde ich mir damit ja selbst ins Bein schießen. Beim AX81 musste ich schon eine ganze Menge umschreiben, damit der veröffentlichte Code auch auf einem ungepatchten AVRA läuft da ich für mich den Code u.a. insoweit modifiziert habe, dass Labels in Makros auch ausserhalb sichtbar sind. Ich kann aber am WE eine RAWSOURCE Datei erstellen, allerdings hat sich dort inzwischen das Format der Kommentare ein bisschen geändert. Gruß Jörg
Hier ist die ASM-Datei von der Version 0.39 Gruß Jörg
Hallo, habe heute das Projekt gesehen, echt interessantes "Teil", gibt es vieleicht eine zusammengeschriebene Teileliste, oder gar die Reichelt Bestellnummern dazu? Gruß Andreas
Von meiner Seite her gibt es so etwas nicht, denn die müsste ich von Hand schreiben. Das liegt auch an meinem "Workflow", der sich von dem Anderer wahrscheinlich stark unterscheinden wird: - Idee, theoretische Vorüberlegungen - Software-Grobentwurf - Pinbelegung vom Controller ausdrucken und Funtionen skizzieren - Leiterplattenlayout mit GEDA-PCB "malen" oder vorhandene BG nutzen - Baugruppe au- bzw. umfbauen, ggf. Layout korrigieren - Software fertigstellen - Stromlaufplan mittels XFig zeichnen Aber dafür diese oder nächste Woche ein Bugfix-Update. Gruß Jörg
So, die aktuelle Version (1.42) steht zum Download auf meiner Seite bereit. Wichtig ist bei Binärprogrammen, dass sie gegen das aktuelle API "gelinkt" sein müssen, andernfalls kann es Abstürzen kommen. Das betrifft insbesondre Treiber und Bibliotheken, da sich die Header-Flags geändert haben. Gruß Jörg
Es gibt wieder einmal ein neues Release, da sich in die letzte Version ein Bug eingeschlichen hat. http://www.jcwolfram.de/projekte/avr/chipbasic2/main.php Und zwar funktionierte der DIR Befehl nicht mehr und hat mit einem Syntax Error abgebrochen. Ursache war die fehlerhafte Abfrage, ob der Port durch einen Treiber belegt ist. In der Abfrageroutinen wurde der Programmpointer (Z-Register) benutzt und am Ende nicht wiederhergestellt. Außerdem wird der I/O bzw. Druckerport bei einem Neustart jetzt auf INPUT mit PullUp zurückgestellt. Jörg
Hallo Jörg, ich plane gerade ein kleines Redesign meiner letzten Version deines super Projektes. Nun würde ich gern die 64K Ram Erwieterung gleich mit auf meine neue Paltine bauen. Ich konnte aber leider am Schema der Erweiterung nicht erkennen, welche PIN's des CPLD's mit welchen Busleitungen zu versehen sind. Auch würde ich gern den Ramtyp ändern. Ich habe hier noch eine ganze Menge an alten Cache- Bausteinen mit 10-15ns und >64KB pro Stück liegen, da würde ich gern einen von nehmen statt wie in deinem Vorschlag 2 kleine zu verbauen. Könntest Du hier die Xilinx- Sourcefiles und eine Liste der Pinbelegungen zur Verfügung stellen, so das ich mir daraus eine neue RAM- Erweiterung zusammen stellen kann ? Ich stelle mein neues Board mit KiCad zusammen und lasse das dann günstig in China fertigen. Bei interesse würde ich die KiCad Sources hier zur auch wieder zur Verfügung stellen. Freundliche Grüße Frank
Hallo Frank, in der aktuellen Version 1.43 sind die Sourcen leider nicht mit dabei, da ich sie im Gegensatz zu den AVR-Sourcen "von Hand" mit in die Archive packen muss (und das bei der 1.43er wohl vergessen habe). Aber in der 1.42 sind sie mit drin und haben sich auch seitdem nicht geändert. Gruß Jörg
Ah, vielen Dank. Ich habe die Sourcen für den CPLD gestern gleich gefunden und mein Layout entsprechend anpassen können. Im moment denke ich gerade darüber nach, wie man den Dataflash, einen SD-Card-Port und ggf. auch noch einen Ethernetport mit an den SPI- Port anschließen könnte, ohne die Kompatibilität zu deinem Layout, den bestehenden Programmen und den ISP- Anschluss zu verlieren. Eine Idee wäres es die verbleibenden Anschlüsse des CPLD's evtl. als "Chipselekt"- Signale zu missbrauchen und den CPLD- Source entsprechend anzupassen. Beim ersten Signal an den CPLD wo nur Read/Write umgeschaltet wird, könnte man die noch ungenutzten Bit's evtl. für die Umschaltung der Pheripherie hernehmen. Aber so ganz zu frieden mit dem ganzen bin ich noch nicht, mal sehn ob mir noch was besseres einfällt. Die Platine die ich hier gerad bastle hat ca. 20*20cm. Da möchte ich möglichst viel an Extras und kleinen Gimmicks gleich mit drauf packen. An sich verschwende ich derzeit schon eine Menge an platz, weil ich alles sehr Übersichtlich in "Funktionsblöcken" anordne und auf der Paltine auch gleich schön mit gedruckten Rahmen und kurzen Infotexten versehe. Das ist aber auch absicht, weil die Platinen die ich mache als Experiementier und Lehrnplatform für ein paar Kinder gedacht sind. Denn ich finde dieses einfache Design einfach ideal geeignet, um das Programmieren und das Experiementieren mit Elektronik zu vermitteln. Hier braucht man nicht erst hunderte Zeilen von C oder Java- Code zu schreiben nur um ein leeres Fenster zu öffnen. Ein paar einfache Basic- Kommandos reichen und man hat sehr schnell ein sichtbares "Erfolgserlebniss". Grüße Frank
Ich hatte in einer Testversion einen SPI-Selektor drin, aber dann aus Platzgründen wieder entfernt. Konkret war das ein Schieberegister, welches bei /CS=1 (SPI unselektiert) die Daten von MOSI seriell empfängt und dann mittels /CS am /OE und Pull-Ups einen von 8 SPI-Slaves adressiert. Dadurch war die Lösung auch zur bestehenden Hardware kompatibel. Wenn Bedarf besteht, könnte ich versuchen, das wieder (etwas platzsparender) zu implementieren. Jörg
Eine genrelle Lösung, für einen SPI- Select welcher auch ohne die Ram- Erweiterung funktioniert währe natürlich genial. Wenn das noch in den 644er zu quetschen ist ohne das dafür wichtige andere Dinge rausfliegen würden, dann währe das zu bevorzugen. Ich habe auch schon darüber nachgegrübelt, selber den Versuch zu starten deine Sourcecodes an den Atmega1284 anzupassen. Selbiger ist ja mitlerweile sehr einfach und günstig zu beziehen. Das würde die Enge beim Hauptspeicher und beim Flashspeicher deutlich reduzieren. Dann hätten ggf. auch die Routinen für SD_Card und Ethernet-Port direkt als Basic-Erweiterung im Kerninterpreter platz und belegen dann keinen der 8 wertvollen Programmspeicherblöcke. Auch die 512 Byte Pufferblöcke für den Dateizugriff auf FAT- Formatierte SD-Cards währen dann besser machbar. Grüße Frank
Ich hatte auch schon einmal mit einem "Nachfolgeprojekt" mit dem Mega1284P angefangen, es gibt sogar einen Prototypen. Und zwar in Form eines DIL-Zwischenadapters mit einem XC9536. Damit gingen dann 40x24 Zeichen / 320x240 und 160x120 sowohl bei TV ais auch VGA ohne die (ChipBasic-) Hardware zu ändern. Das habe ich aber erstmal eingemottet, da ich keinen großen Bedarf für eine derartige Lösung sehe. Eine Bibliothek für den ENC (ARP, ICMP und UDP) hatte ich auch schon einmal angefangen, aber in ASM ist das nicht unbedingt eine sehr erquickliche Aufgabe. Gleiches gilt für SD-Karten, wenn FAT mit ins Spiel kommt... da ist mir meine Zeit momentan zu schade dafür. Jörg
Vom Code her habe ich die Multiselect-Erweiterung wieder eingebaut, wenn ich dazukomme mache ich am WE einen Probeaufbau um die Funktion zu testen. Insgesamt kann man dann 8 SPI-Geräte anschließen wobei eines für den Dataflash reserviert sein wird. Ohne Erweiterung wird immer das angeschlossene Gerät selektiert, dadurch sollte es keine Kompatibilitätsprobleme geben. Der SPISEL Befehl bekommt aber eine etwas andere Funktion, was den Parameter anbetrifft. Jörg
Hallo Jörg ,ich hätte da noch ma eine Frage,welche Bezeichnung die beiden Sram Bausteine genau haben. ansonsten echt tolles Projekt! Gruss Patrick
Patrick M. schrieb: > Hallo Jörg ,ich hätte da noch ma eine Frage,welche Bezeichnung die > beiden Sram Bausteine genau haben. ansonsten echt tolles Projekt! > > Gruss Patrick Hm, da müssten wenn ich mich nicht irre all die alten Cache Bausteine aus der 386er/486er Area laufen. Alles was in der Richtung 32KB mit 8 Datenleitungen und ca. 10-15ns geht müsste laufen. Beispiele aus meiner "Sammlung alter Cache Chips mit 32KB*8" wären: UM61256AK-15 MS62256H-15NC EM51256-15PL W24257AK-15 AS7C256-15PC von Alliance Ich selbst würde es als erstes mit dem UM61256AK-15 probieren. Den hab ich schon erfolgreich eingesetzt :-) Grüße Frank
Angehängte Dateien:
Ich habe in den letzten Tagen weiter an meiner "großen" Experimentiert und Lehrnversion der Platine gearbeitet. Das ganze sieht noch recht Unfertig aus. Ist es auch :-) Im moment fehlt mir noch der Part mit dem SPI- Selektor. Auch will ich den Dataflash mit auf die Platine bringen und wenn ichs noch drauf kriege kommt auch noch ein einfacher Ethernet-Port mit drauf. Was bisher schon drauf ist: - Alles was Joergs Grundplatine auch drauf hat :-) - Ein 5 Volt und ein 3,3 Volt Low-Drop Linearregler mit genügend Power für kleine Addons. - Die 64KB Ram Erweiterung - Scart Buchse und Chinc- Buchsen für Video und Audio - Ein einfacher NF- Verstärker für Kopfhörer. - 2 Seriele Ports über MAX232 Treiberchip. - Wahlweise kann der 2. serielle Port welcher vom 644P in Hardware unterstützt wird auf einen FT232RL- USB Anschluss umgejumpert werden. - Ein SD- Kartensockel am SPI-Bus ( Chipselekt fehlt noch ) - Ein 8 BIT IO Chip (PCF8574) am I2C Bus. - Eine Bateriegepufferte Echtzeituhr am I2C Bus. (DS1307). Ich hab einfach mal ein kleines Bild angehängt, das das ungefähre Layout wiedergibt. Das ganze wird ca. 20*20cm groß werden. Wenn ich das Board fertig Aufgeräumt und Layoutet habe, werde ich es wohl bei ITEAD-Studio in Auftrag geben. In der Größe bekommt man dort 5 Stück für knapp 38 Dollar. ( Zuzüglich Versand und Zollgebüren! ). Freundliche Grüße Frank
Hallo Jörg wollte noch ein Bug melden,und zwar hängt CBTerm mini (V0.10 ),(Chipbasic version 1.43) sich manchmal auf,besonders im dialog-modus wenn man den Text mit CLEAR löscht sind keine Eingaben mehr möglich,so das das System komplett neu gestartet werden muss. Gruss Patrick
@Frank Hast du die SD Anbindung Softwaremäßig schon geregelt?
Ich habe jetzt die Version 1.44 released, die das SPI Multiselect unterstützt. Ausserdem habe ich bei der 1.43er Version die fehlenden Sourcen hinzugefügt. http://www.jcwolfram.de/downloads/main.php#chipbasic2 Im Moment bin ich mir nicht sicher, ob ich die "nächste Generation" noch in Angriff nehme. Das Daughterboard mit Mega1284P und XC9536 habe ich bereits gebaut und getestet, es routet auch gleich die serielle Schnittstelle des Chipbasic Boards auf den UART1, damit sind höhere Baudraten möglich und es werden Takte gespart. Bis auf die 16-Farb Erweiterung und die Nutzung des 2.UART ist es mit allen anderen Hardware-Erweiterungen kompatibel, die Software müsste aber in großen Teilen neu geschrieben werden. Jörg
cooooool Jörg! Danke!! Kannst du das mit dem Multiselect noch dokumentieren? das wäre super! Ne andere Frage: Warum kann man Programme nicht direkt vom Dataflash laden? Müssen diese technisch erst in den Controller geladen werden? Gruß Dominik
Toll, hab mir grad den 2. Computer aufgebaut auf Lochraster! Komischerweise ist die Farbe Cyan nun Lila, Grün ist Rot, etc.! Habe auch keinen Sound!! Woran kann das liegen? Scart wurde genauso angeschlossen wie beim ersten Computer! Und da hat alles funktioniert! :(
Da ist bei Dir sicher rot mit grün vertauscht: CYAN = blau + grün MAGENTA = blau + rot Beim Sound müsste man einfach mal an PD7 messen, ob das PWM Signal anliegt. Mit einem Multiimeter sollten am Pin ca. 2,5V anliegen (50% PWM). Wenn das OK ist, würde ich weiter die Verdrahtung überprüfen. Jörg
Hi Jörg, ok... da muss ich mal schauen! habe die Leitungen alle überprüft bis zum Scart... eventuell hab ich nen Fehler bei den Widerständen gemacht! Werde das mal prüfen! Joar mit dem Sound ist schon kurios! Werde das auch mal prüfen!
Oh man! Wenn man dank 4 Kinder beim löten keine Ruhe hat! die Verbindung der Soundleitung war nicht geschlossen! Sound müsste demnach jetzt funktionieren! Zu den farben: Habe wohl den 6K8 Widerstand von E nach A der farberweiterung vergessen... kann es auch daran liegen??? gruß Dominik
Ich wieder... also, Jörg du hattest Recht.. rot und grün war vertauscht! Komisch, ich war der meinung alles wäre richtig angeklemmt. So, nächste Problem: Der DataFlash! Gestern habe ich alle meine Spiele auf den Flash gesichert. Eben guck ich nach, alles ok... das nächste spiel abgespeichert und die Meldung kommnt: "Data flash not formated" ???? Ich kann nicht mehr zugreifen!! Er erkennt ihn zwar aber meint er wäre nicht formatiert. Ok, formatiere ich dann aber.... das problem bleibt!!!!!! Er wird erkannt, aber ich kann nicht mehr drauf zugreifen! Was ist das?? HILFE... alle spiele weg :(((
Hallo KILO hast du bei deinem Dataflash die Stromversorgung stabil, und welche version hast du drauf? ,hatte anfangs änliche Probleme,da ich den Abblockkondensator vergessen hatte. Gruss Patrick
Hab gerade mein chipbasic2 auf die version 1.44 geupdatet! Hab Das selbe Problem wie Kilo, das das dateisystem auf dem Dataflash beim speichern Zerstört wird. da hat die 1.44 er wohl noch einen schweren Bug drin. Patrick
Wenn Programme verloren gegangen sind, tut es mir leid aber so etwas kann schon mal passieren. Auf meinem 1.44er Testsystem funktioniert es, wenn ich aber das Release draufspiele, habe ich das gleiche Problem. Also muss ich mal schauen, bis zu welcher Version es ging und mir dann die Änderungen auflisten. Die 1.44 ist ja nur die "Major-Number", danach geht es intern mit Buchstaben weiter. Zwischen Programm Schreiben und Testen liegen schonmal ein paar Tage, da die meiste "Entwicklung" inzwischen morgens und abends in der S-Bahn stattfindet. Und dann dauert es wieder, bis die Doku überarbeitet und das Release zusammengestellt wird. Inzwischen muss man halt mit der Version 1.43 vorlieb nehmen, denn ab dem nächsten Release will ich auch die Unterversionen mit anzeigen lassen um so schneller Fehler zu finden. Und das kann halt etwas dauern... Jörg
Kein problem Jörg , finde es super das das projekt weiter geht! Vielen dank gruss patrick
Thread beobachten
Seitenaufteilung abschalten
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.