Ich habe, wenn ich mich recht entsinne, noch ein paar Boards von Glyn im Keller. Ich könnte da Montag mal schauen, was noch da ist und was ich evtl. abgeben könnte.
73 de Tom-- DL7BJ * DL-QRP-AG #1186 * AGCW-DL #2737 * DARC OV I19 * http://www.dl7bj.de
Ganz sicher nicht, das wäre völliger Overkill:)
ich hab inzwischen Kontakt aufgenommen und bissl was erfahren. Das Beste dabei: Der Kerl wohnt in der Nachbarstadt, also 30km nördlich von mir:)
Nunja, bei dem Ding gehn die Pinabstände ja noch. Ich hab schon Chips im Atari TT damals getauscht, die mehr Beine hatten (und dabei geflucht).
Ach daher kommt das. Mein Yongnuo TTL-Blitz zeigt nämlich die Bereitschaft in der falschen Farbe an, da is sicher so ein Dingen drin.
Kommunikation macht hier komplett einer der Macs.
Nunja, wie sagt man so schön: Keine Arme, keine Kekse.
Wenn ich mir anschaue, was für eine Bandbreite an MCUs in MIDI-Geräten so steckt, geht das offenbar bei vielen. Gut, manche setzen gleich auf den 6850 oder das Zilog-Gegenstück.
So einer steckt in meinem großen GEM-Keyboard drin, dessen OS ja erweiterbar sein sollte, aber nie genutzt wurde. Könnte man was mit machen, nur ist mir der Aufwand zu hoch.
Allerdings. Das erwähnte Gerät ist auch sehr komfortabel geraten und kann Multitasking. für Anfang der 90er nicht selbstverständlich.
Gut so. Die Parallelen sind aber deutlich vorhanden und gefallen mir recht gut.
Muß mal schaun, obs die Dinger auch ne Nummer kleiner gibt, für weniger fette Sachen.
-- Bye, Dietmar
Ich nicht. So schnell und so billig wie mit DIL-µC und Streifen/Lochraster-Platine hast du mit Sicherheit keine Anwendung fertig.
Wenn man eine richtige Platine macht, braucht man selbst für DIL nicht unbedingt bohren. Die Pins kann man nämlich auch einfach abwinkeln und das Teil flach auf die Leiterseite auflöten. Die Möglichkeit, dann noch ohne größere Probleme wenigstens vier Leiterzüge zwischen zwei Pins durchrouten zu können, macht die Platine zumindest theoretisch oft sogar kleiner als die echte SMD-Version...
Aber es ist natürlich nicht wirklich nötig, denn es gibt die Atmels auch in SMD-Gehäusen, wenn man denn diese bevorzugt...
Alles außer dem *next. Ich würde das in Asm (mit meinen eigenen Macros zur Deklaration von Strukturen) einfach mit:
S_PTR next "übersetzen". Das enthält alle TATSÄCHLICHEN VORHANDENEN Informationen der C-Deklaration. Nämlich: Es handelt sich um einen Zeiger ohne weitere Informationen darüber, worauf er zeigt und er befindet sich auf dem Strukturoffset mit dem symbolischen Index next.
Das "volatile void" der C-Deklaration hingegen ist hyperfluid. Es sagt absolut nix und macht absolut nix. Reiner Source-Bloat. Viel schlimmer noch: der krass unfähige Compiler benötigt sogar das absolut nichtssagende "volatile", um effizienteren Code generieren zu können. Ja was ist denn das für ein Compiler? Wenn ich ihm auch noch sagen muß, wie er halbwegs effizienten Code hinbekommt, dann schreibe ich doch lieber gleich selber wirklich bedingungslos effizienten Code.
ASM RULES!
das wäre eine interessante weitere Option, auf die ich bei Bedarf gerne zurückkomme.
-- Bye, Dietmar
Das Display ist ehr speziell - dient ja als Demo für die Displaytreibereigenschaften des Controllers. Würde da doch ehr zu einem handelsüblichen LCD-Modul zurückgreifen wenn Du Dich nicht ausdrücklich an diese Hardware binden willst.
Gerald
"Wolfgang Allinger" schrieb im Newsbeitrag news: snipped-for-privacy@allinger-307049.user.uni-berlin...
Warum was Halbes und nichts Ganzes ?
-- Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net homepage:
Jein, bei Forth erledigt das der Kernel für Dich, d.h. wenn das System startbar ist, ist CELL CELL+ ... bereits definiert. Solange Du nicht ganz tief im Schlamm wühlst, brauchst Dich nicht zu kümmern und Du nicht gerade auf einem Marc4 bist, ist es i.a. völlig unerheblich, wieviel bits die HW breit ist. Eine CELL hat mindestens 16bit (Ausnahme Marc4 :)
Wenn es in DPANS Forth geschrieben ist, sollte es eigentlich laufen. Das war das Ziel. Je HW spezifischer Du was programmierst, umso eher geht es latürnich nicht :] Sachen wie ALIGNED... machen das aber auch transparent und braucht man erst, wenn man das letzte an Geschwindigkeit oder Platz rausquetschen muss.
Ich hab auch schon Forth gesehen, wo der IR per HLL definitionen gemacht werden konnte und erst wenn das mal zu langsam sein sollte, dann muss man CODE benutzen. Sehr praktisch bei User Interfaces, der normale Tipper schafft nicht 10 IR/sec, da reicht das völlig und ist dann sehr elegant.
Ich schreibe fast immer erst alles in HLL und teste es interaktiv aus. Wenn das zu langsam ist, programmiere ich die Bremser dann in CODE um, das ist sehr einfach, denn die Struktur hat die HLL definition schon erledigt, muss man dann nur noch abkupfern. Beide def parallel testen/ aufrufen, ggf. in Schleife automatisch, wenns übereinstimmt. bissu feddich. Weiter mit der nächsten Aufgabe.
Mir gefällt auch, dass man bei Forth i.a. Top-Down designed und Bottom- Up programmiert. Da hat man die übelsten Kracher schon sehr früh im Projekt erschlagen und tappt nicht in die Falle: es geht ja schon alles, die ganze GUI blinkt und glänzt und 1 Tag vor Inbetriebnahme fällt auf, das sich die Daten garnicht mit der geforderten Geschwindigkeit einlesen lassen...
Saludos Wolfgang
-- Meine 7 Sinne: Unsinn, Schwachsinn, Blödsinn, Wahnsinn, Stumpfsinn, Irrsinn, Lötzinn. Wolfgang Allinger Paraguay reply Adresse gesetzt ! ca. 15h00..21h00 MEZ SKYPE:wolfgang.allinger
Man kann mit Forth wie in einer Hochsprache programmieren. Es ist mit CREATE/DOES> und IMMIDIATE sogar noch mächtiger als C, denn man könnte damit theoretisch ein Wort definieren, innerhalb dessen man dann ein C Programm schreiben kann, was dann zur Compilierzeit in Forth umgewandelt wird. Ich denke das wird noch viel zu wenig ausgenutzt, da kann man bestimmt noch einiges erforschen, was damit möglich ist. Ich kenne sonst nur Lisp, was in dieser Hinsicht so flexibel erweiterbar ist. C++ ginge auch noch mit Template Metaprogramming, aber die Syntax kann man damit nicht ändern und ist auch nichts für schwache Nerven :-)
Brainfuck dagegen fühlt sich noch viel schlimmer als Assembler an, wenn man darin programmiert und hat mit Forth nichts zu tun. Ich habe das mal in "COW" probiert, was "Ook!" mit anderer Syntax ist, was wiederum Brainfuck mit anderer Syntax ist:
Die 8 Befehle von Brainfuck sind allerdings schon recht redundant. Kann man scheinbar auf 3 Befehle reduzieren:
-- Frank Buss, http://www.frank-buss.de piano and more: http://www.youtube.com/user/frankbuss
Eigentlich nicht. Displays hab ich hier noch 2 Stücke rumliegen, sind so
44780 Dinger, iirc von Pollin, mit Doku/Treiber noch auf Diskette, 2x40 Zeichen. Sind schon was älter, sollten aber denk ich gehen.Sieht aber derzeit eher so aus, als würde mein Weg zu M16C gehen statt zu AVR, von daher muß ich mal diese Displays ausgraben:)
-- Bye, Dietmar
Geil. Esoterisches Fotozubehör kenn ich, aber daß es auch solche Programmiersprachen gibt war mir neu:)
-- Bye, Dietmar
Viele Teile der Deklarationen sind auch notwendig für die Typprüfung. Sowas gibt es in ASM gar nicht. Offensichtlich hat sich aber herausgestellt, dass dies sinnvoll sein kann, da Programmierer auch schonmal Fehler machen.
Dirk
Beim AVR tut RISC doch nun wirklich nicht weh. Man muss zwar ein paar Beschraenkungen in Kauf nehmen, z.B. dass die Register r0-r15 nicht universell verwendbar sind oder der I/O-Adressraum sehr klein ist, aber das musste man halt so machen, sonst waere diese Performance und Codedichte nicht moeglich gewesen.
Wenn die Geschwindigkeit sekundaer ist macht man halt I/O grundsaetzlich memory-mapped und benutzt die Register r0-r15 nicht. Die verbleibenden
16 Register sind immer noch mehr als manch andere CPU zu bieten hat. Bis auf die Pointerregister X/Y/Z und meinetwegen LPM gibt es dann kaum noch Spezialitaeten ueber die man stolpern koennte.Dafuer bekommt man Luxus wie z.B. das Mnemonic CLR um ein Register zu loeschen, dann kann man:
CLR r16
statt
EOR r16, r16
schreiben. Dass die CPU gar keinen CLR Befehl implementiert hat muss man nicht wissen. Die Mnemonics haben eigentlich alle "schoene" Namen damit man keine Knoten im Hirn bekommt:
bla: [Code] CP r16, r17 BRNE bla
Diese Schleife laeuft bis r16 und r17 gleich sind. "CP = Compare" und "BRNE = Branch if Not Equal" sind leicht zu merken und ich muss weder ans Subtrahieren noch ans Carry-Bit denken.
Auch eine 32Bit Addition sieht sehr uebersichtlich aus:
ADD r16, r20 ADC r17, r21 ADC r18, r22 ADC r19, r23
wenn man das mit z.B. PIC16 vergleicht.
Es gibt direkte und indirekte Adressierung, bei Bedarf auch mit Pre/Post Increment/Decrement oder Displacement. Im Gegensatz zu PIC16 sind die Port-Latches auslesbar und damit Read-Modify-Write ohne Backbuffer moeglich.
AVR ist IMHO ein gelungener Kompromiss aus Performance und uebersichtlicher Assembler-Programmierbarkeit. Schoen billig und an jeder Ecke zu bekommen (wenn man will auch im DIP-Gehaeuse) sind die Dinger auch noch. Was will man von einer 8Bit CPU denn viel mehr erwarten?
Micha
-- http://micha.freeshell.org/
Ich verwende ganz gerne das Modul ALPS LSU7S1011A von Pollin fuer
2.95Euro. Haben sie schon einige Jahre im Programm. Mussen sie wohl eine grosse Kiste von haben. :-)Das ist ein Grafik-LCD mit seriellen SPI-Bus. Die haben den Nachteil das man den Displayinhalt nicht auslesen kann. Man benoetigt also
384Byte als Ram im Controller und 1-2k im Flash fuer den Zeichensatz. Aber wenn der Controller viele Kbyte hat ist das natuerlich kein Problem.Selbst wenn man garkeine Grafik ausgeben will ist das schoener weil Text auf diesen LCDs einfach huebscher aussieht als auf dem Standard Hitachi Zeugs mit deren festgelegten Pixelabstaenden wo man immer den Kontrastunterschied zwischen Zeichenhintergrund und inaktive Flaeche sieht.
Olaf
Midi ist doch nichts anderes wie RS232 mit einer etwas ungewoehnlichen Baudrate. Mit dem passenden Quarz geht das mit jedem Controller. Allerdings haben moderne Controller den Vorteil das man dort die Baudrate unabhaengiger einstellen kann.
Hier gibt es uebrigens das Datenblatt zu dem Prozessor in 30km Entfernung:
Wie du siehst hat er drei UARTs im Sinne von RS232 die vollkommen unabhaengig unterschiedliche Baudraten fahren koennen. Und zwar ohne das du einen der elf vorhandenen 16Bit Timer dafuer verwenden muesstest. :-)
Interessant ist vielleicht auch das der COntroller zwei DA Ausgaenge hat. Sowas findet man bei Microcontrollern ja eher selten.
Vor allem das Konzept der kleinen MiniCPU fuer SPI und aehnliches finde ich beim 68332 sehr brilliant.
R8C13 ist wegen dem Elektor Artikel wohl gut zu bekommen. Ich verwende ganz gerne den moderneren R8C29. Letzerer hat den Vorteil das er neben RS232 noch ein neues Debug-Interface ueber die Resetleitung hat. Das spart Pinne wenn man den in der Platine brennen will. Braucht dann aber einen E8. Ausserdem liefert Renesas im Prozessor ein Kalibrierbyte fuer den internen Oszillator mit. Zumindest bei Raumtemperatur kann man damit sogar RS232 ganz gut nutzen und sich so den externen Quarz sparen.
Olaf
Kommt auf Anwendung drauf an. Wenn du nur ein paar Textzeilen ausgeben willst, dann brauchst du kein RAM. Und auch bei Grafik nicht immer.
-- Frank Buss, http://www.frank-buss.de piano and more: http://www.youtube.com/user/frankbuss
1MHz/32=31250Baud.
Gruß Henning
-- henning paul home: http://home.arcor.de/henning.paul PM: henningpaul@gmx.de , ICQ: 111044613
Da gibt es noch andere "nette" Sachen:
Micha
-- http://micha.freeshell.org/
Das hab ich auch gerade gesehen und mich gefragt ob das taugt:)
Wenns meine beiden Displays hier nicht tun, werde ich auf dieses Ding zurückgreifen denk ich.
Danke für den Tip.
-- Bye, Dietmar
Es ist eine Serielle mit 31,25Kbaud und TTL-Pegeln per Optokoppler.
Danke, gespeichert. 3 UARTs sind ja schon Luxus pur.
Ich glaube die H8-Modelle haben sowas.
Stimmt, den hab ich auch gefunden.
Für die Entwicklungsumgebung muß man sich bei denen registrieren - das nervt. Nja, solange man danach nicht wieder mit 1000 Mails zugeschüttet wird solls mir recht sein.
-- Bye, Dietmar
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.