Angepinnt arm2iec [Neue Hardware]

  • arm2iec [Neue Hardware]

    Hi!

    Evtl. hat es ja jemand mitbekommen, dass ich Ende 2010 sd2iec auf eine ARM-CPU, genauergesagt auf einen LPC1768 portiert habe und die git-Version seitdem sowohl für ARM als auch AVR compilierbar ist. Dummerweise ging dabei der Plan, dass irgendjemand das interessant genug finden würde um die Hardware dafür zu entwerfen nicht auf und um das über ein Jahr lang aufgebaute Steckbrettchaos endlich mal beseitigen zu können habe ich dann doch mal selbst Hand angelegt. Das Ergebnis ist die "arm2iec"-Hardware, die jetzt nach etwas Debugging und Umschreiben der Software(1) scheint das Ding jetzt auch gut genug zu laufen um es wenigstens mal in einem etwas grösseren Kreis bekanntzumachen.

    Features der neuen Hardware:
    • NXP LPC1768/1769-CPU - Cortex M3, 100MHz (1769: 120, nicht ausgenutzt), 512KB Flash, 64KB Ram - laut Speed-Test kommt Jiffy damit jetzt auf 24,9fache Geschwindigkeit statt ca. 23fach auf AVR
    • kompakte Platine: nur 90x100mm^2 (zum Vergleich: eine 3,5"-Disk ist 90x94mm^2 gross)
    • komplett mit viel Fluchen liebevoll handgeroutet
    • passt vermutlich in kein gebräuchliches Gehäuse
    • Montagelöcher in allen vier Ecken (Prototyp-Platine: drei Ecken und zwei weitere Löcher wo gerade Platz war)
    • Hobbybastlerfreundliches Design: Nur zwei SMD-Bauteile(2), der Microcontroller selbst steckt auf einem Fertigmodul
    • vier Taster(3) zur Softwaresteuerung
    • Reset-Taster
    • vier LEDs auf der Platine, drei weitere auf der Controllerplatine(4)
    • vier DIP-Schalter zur Auswahl der Geräteadresse von 8 bis 23
    • Spannungsversorgung via USB
    • USB-Seriell-Wandlerchip (SMD, aber mit harmlosem 1,27mm-Raster) für Debugausgaben oder zur initialen Programmierung mit dem Rom-Bootloader direkt auf der Platine
    • zwei DIN-Buchsen für den seriellen Bus
    • zusätzliche Stiftleiste für den seriellen Bus falls die nicht reichen sollten
    • saubere Bustreiber (7414 und 7407)
    • Parallelport-Anschluss(3)
    • LCD-Anschluss für HD44780-kompatible Textdisplays(3)
    • Vorbereitet für Ethernet(3), braucht eine externe RJ45-Buchse und einen passenden Trafo
    • batteriegepufferte Echtzeituhr
    • 3-Pin-Jumper um den Einsprung in den Rom-Bootloader zu erzwingen
    • USB-B-Buchse zur PC-Anbindung(3) (falls jemand mal die Zoomfloppy-Sourcen portieren will?)
    • freie I/O-Pins des Microcontrollers auf einem Erweiterungsstecker verfügbar
    • nettes "Designed for sd2iec" mit Logo auf der Unterseite
    • furchtbar teuer (das Fertigmodul mit dem Microcontroller kostet einzeln schon 23,80EUR)


    Natürlich hat die ARM-Version von sd2iec alle Features der AVR-Version und natürlich wird wenn möglich ein neues Feature auf beiden CPU-Architekturen aktiviert.

    Ein paar Fotos der Prototypen-Version - die 1.1 hat ein paar kleine Änderungen:

    (das Bild der Platinenoberseite ist übrigens minimal weichgezeichnet um das 251kB-Limit ohne sichtbare Artefakte zu erreichen)

    Man beachte die elegant zur anderen USB-Buchse rübergefädelten Signalleitungen des MCP2200 nachdem die Pads der Mini-USB-Buchse sich schon beim ersten Entlötversuch von der Platine gelöst haben. ;)

    KiCAD-Daten der Beinahe-1.1-Version der Platine (die Mini-B-Buchse muss noch auf THT umgestellt werden, ich hatte aber keine Lust heute noch den Footprint zu zeichnen) finden sich hier, einige Bausätze für die Prototypen-Version gibts gleich im hiesigen Flohmarktbereich. Die dazu passende Version von sd2iec ist noch nicht im Repository, ich muss den lokalen Branch erst noch etwas aufräumen.



    Fussnoten/Kleingedrucktes:
    (1) Man sollte nachschauen auf welchen Ports Interrupts ausgelöst werden können bevor man die IEC-Pins definiert. Glücklicherweise war ein Workaround mit anderen Funktionen auf den Pins möglich.
    (2) Auf den Prototypen-Platinen ist die USB Mini-B-Buchse noch in SMD, aber die habe ich netterweise mal vorbestückt.
    (3) zur Zeit nicht sd2iec unterstützt
    (4) zur Zeit nicht so richtig sinnvoll von sd2iec unterstützt


    EDIT by FXXS: auf userwunsch hier noch der Link zur Aufbauanleitung: arm2iec 1.1 Aufbautips

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • Ja, das steckt viel Arbeit drin, ich hab's miterlebt :) Aber das Ergebnis kann sich sehen lassen. Jetzt fehlen noch tolle Features (tm), für die im alten Atmega 644 ja kein Platz mehr war.

    Aber: Was ist mit C8?
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Bau Dir ein eigenes Modul! EasyFlash
  • Eventuell reicht das Potential aber aus, umd DTV-Demos von SD2IEC statt von 1541 zu laden :)
    Gibt ja m.W. nach nur eine reine DTV-Demo, die wahlweise eigenen Speedloader oder Kernal-Loader verwendet, und bei letzterem mit Jiffy-DOS recht fix zugange ist.
    Frage mich immer, warum man Demos für ein Mobilgerät so codet, dass eine stationäre Floppy benötigt wird...jetzt mal abgesehen von den Demos, die man flashen muss, das ist bei einem Flashbaustein, wie er im DTV verwendet wird, auch ziemlich unschön.
  • CrazyIcecap schrieb:

    Eventuell reicht das Potential aber aus, umd DTV-Demos von SD2IEC statt von 1541 zu laden :)

    Das tut sich nicht viel, es gibt da die recht hohe Hürde, einen 6502 mit Peripherie in Echtzeit zu emulieren die erstmal überwunden werden muss.

    Manawyrm schrieb:

    "Da wäre ich mir nicht so sicher, skoes open1541 brauchte immerhin eine 400MHz-CPU."

    ernsthaft?

    IIRC hat skoe mal versucht eine (taktgenaue) 1541-Emulation auf einem 72MHz-ARM7 (LPC21xx) zu bauen und ist dann relativ schnell auf einen XMOS XS-1L(?) umgeschwenkt, der mit 400MHz läuft - und selbst da mussten wohl einige Teile von Hand in passendem Assembler gebaut werden damit es mit dem Timing funktioniert.

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • Unseen, das klingt nach Revolution! Über das "Hobbybastlerfreundliche Design" und "furchtbar teuer" werden sich die Rückgewandten freuen, da bin ich mir sicher. Doch wo ist der Codec, äh Steckplatz für einen SID, damit man "Floppygeräusche" machen kann? Und bist du sicher, dass eine "handgeroutete Platine" angenommen wird? Und dann noch mit potentiellem Netzwerkanschluss? Am Ende könnte man gar ein IEC auf IEEE-802.3-Gateway implementieren und Commodore Drucker über's Netz anschließen... (-;

    Spaß beiseite. Was ich wirklich sagen wollte: Hey schönes Board! Klasse! Danke, Unseen!
    Endlich traut sich mal jemand an was Moderneres ran, das als Basis für viele schöne Projekte dienen kann.
    In a moment all went screaming wild until the darkness killed the light..
  • Liege ich richtig mit der Annahme, dass dieses Board eine kluge Anschaffung wäre, wenn man Code für das ARM2IEC entwickeln möchte?


    Anscheinend braucht es kein Programmiergerät oder sowas, weil JTAG direkt am Board vorhanden ist. Kann man mit diesem Board dann auch das ARM2IEC flashen? Wenn nein, was wird empfohlen?
    Letztlich ist alles nur Illusion
    Es gibt hier nichts von Bedeutung
  • Diddl schrieb:

    Kann mir jemand sagen, wo man eine einfach zu installierende, passende Toolchain für LPC bekommen kann?

    Ich verwende zur Zeit einen Eigenbau auf Basis eines "lad mal alles runter und bau es"-Makefiles von skoe, das zumindest unter Linux hervorragend funktioniert - das Repository dazu ist hier zu finden. Wenn du eine andere Toolchain verwenden möchtest solltest du darauf achten, dass sie die CMSIS-Header inkl. der chipspezifischen Header mitbringt und dir aus meiner Toolchain noch die bits.h klauen. Evtl. compiliert es dann trotzdem nicht, da die CMSIS-Header ein paar fehlerhafte Konstrukte enthalten, die bei gcc eine Warnung produzieren und da immer noch mit -Werror compiliert wird bricht es dann ab - das Makefile aus meinem Repository patcht die deswegen bei der Installation.

    Als ich mit dem Kram angefangen habe fand ich keine ARM-Toolchain, die aktuell genug gewesen wäre um Thumb2-Code zu erzeugen und zudem in bequem unter Linux compilierbarer Form vorgelegen hätte, skoe war dann so freundlich da auszuhelfen.

    Diddl schrieb:

    Liege ich richtig mit der Annahme, dass dieses Board eine kluge Anschaffung wäre, wenn man Code für das ARM2IEC entwickeln möchte?

    Wenn du unbedingt ein zweites willst? Auf dem arm2iec steckt genau so ein Board drauf, nur ist der JTAG-Teil davon abgesägt (keine Sorge, das ist dafür vorgesehen) und liegt natürlich lose bei. Das Board gibts übrigens auch anderswo zu ungefähr dem Preis: watterott.com/de/LPC1769-LPCXpresso

    Anscheinend braucht es kein Programmiergerät oder sowas, weil JTAG direkt am Board vorhanden ist. Kann man mit diesem Board dann auch das ARM2IEC flashen? Wenn nein, was wird empfohlen?

    Ja, es ist ein JTAG-Interface direkt dran... Dessen Protokoll in Richtung PC ist nicht dokumentiert, es wird ausdrücklich nur von der CodeRed-IDE unterstützt (Registrierungscode gehört zum Xpresso, die IDE ist aber IIRC auf 128KB beschränkt) und der dafür verbaute LPC3154 wird mit einer verschlüsselten Firmware vom PC gefüttert, damit man das Ding auch auf gar keinen Fall für andere Zwecke weiterverwenden kann oder gar mit anderer Software als JTAG-Interface benutzen könnte.

    arm2iec kannst du direkt mit dem Rom-Bootloader des LPC1769 über das Onboard-USB-zu-Seriell-Interface flashen, z.B. mit yalf (für Linux empfohlen, lpc21isp (meckerte in meinen Tests wegen eines Bugs beim Verify) oder FlashMagic (für Windows empfohlen). Wenn man (wie ich) keine Lust hat ständig das minicom mit den Debug-Ausgaben zu beenden um neu zu flashen kann auch OpenOCD mit dem LPC1769 umgehen, es braucht dafür lediglich ein JTAG-Interface mit dem OpenOCD umgehen kann und welches für 3.3V-Targets geeignet ist.

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • Genial, danke für die ausführliche Antwort!


    Zoomfloppy Support klingt verlockend, insbesondere da LUFA nun auch auf ARM verfügbar sein soll ...

    Ich seh da Parallelport, ist da was vorgesehen in der ARM2IEC firmware? Oder gar schon verfügbar?
    Letztlich ist alles nur Illusion
    Es gibt hier nichts von Bedeutung
  • Diddl schrieb:

    Zoomfloppy Support klingt verlockend, insbesondere da LUFA nun auch auf ARM verfügbar sein soll ...

    "auf ARM" reicht nicht, es muss schon passend für den Chip sein. Ausserdem müsste irgendwer (möglichst nicht ich) die Zoomfloppy-Firmware portieren und dabei sinnvollerweise auch den IEEE488-Teil rauswerfen weil dafür vermutlich die Pins nicht ausreichen.

    Ich seh da Parallelport, ist da was vorgesehen in der ARM2IEC firmware? Oder gar schon verfügbar?

    Ich habe vor langer Zeit mal angefangen damit auf AVR herumzuexperimentieren, aber die Ergebnisse sind bisher nicht in sd2iec eingeflossen. Nachdem ich die dritte oder vierte Variante eines SpeedDos-Drivecodes im Log hatte war mir die Lust vergangen das genauer zu analysieren...

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • Unseen schrieb:

    Ausserdem müsste irgendwer (möglichst nicht ich) die Zoomfloppy-Firmware portieren und dabei sinnvollerweise auch den IEEE488-Teil rauswerfen weil dafür vermutlich die Pins nicht ausreichen.

    Die Zoomfloppy Firmware wäre nicht das Problem, die läuft ja schon auf 5 Boards, weil Nate das Augenmark von Anfang an auf Portabilität hin designed hat.

    Der IEEE Teil ist per #define abschaltbar, weil ja nur die wenigsten Boards dafür ausgelegt waren. Wobei die PIN Anzahl kein Thema wäre. IEEE-488 braucht nur ein PIN mehr als IEC: ATN=ATN, DATA=NRFD, CLK=NDAC, SRQ=DAV, RESET=IFC, dann fehlt nur noch EOI. Zur Not muss man halt auf IFC verzichten zugunsten des notwendigen EOI. Voruasgesetzt RESET ist bidrectional ...

    Die LUFA ist das große Problem. Vielleicht kann Nate mal gucken ob er was machen kann. Leider hat der so gut wie nie Zeit über ...


    Unseen schrieb:

    Nachdem ich die dritte oder vierte Variante eines SpeedDos-Drivecodes im Log hatte war mir die Lust vergangen das genauer zu analysieren...

    Es ist schon mal gut, dass die Hardware das unterstützt. Es gibt ja nicht soviele SpeedDOS Benutzer, aber es wäre ein nettes feature (für mich).
    Letztlich ist alles nur Illusion
    Es gibt hier nichts von Bedeutung