SDCard HxC Floppy Emulator im Atari STE

Heute mittag habe ich meinen HxC Floppy Emulator (vorläufig) fest im Atari STE eingebaut. Ich habe mehrere Probleme dabei festgestellt. Trotz verlängertem Floppykabel ist da alles wegen der Kabelknickrichtung nicht wirklich praktisch. Ausserdem ist so das Kabel zur Spannungsversorgung immer noch knapp und mit dem verlängerten Floppykabel im Weg. Der rechte Abstandshalter ist mir leider etwas abgebröselt und zu allem übel halten die Fixierungschrauben, die eigentlich von unten in die Floppy greifen, weder von oben noch von unten 100%. Die ganze Konstruktion ist wackeliger, als sie auf dem Foto aussieht. Man kann prinzipiell damit arbeiten, alles läuft, aber mechanisch ist die Konstruktion alles andere als perfekt.

SD Card HxC Floppy Emulator eingebaut im Atari STE
SD Card HxC Floppy Emulator eingebaut im Atari STE

Höchstwahrscheinlich werde ich noch eine Verlängerung für die Spannungsversorgung holen, IIRC werden nur 5V benötigt und dann den ganzen HxC Aufbau durch die Floppyöffnung samt Kabeln aus dem Gehäuse heraus führen. Das ist nicht perfekt, müsste aber ausreichen und mechanisch und elektrisch zuverlässiger sein als der aktuelle Stand.

Von den vielen Montageproblemen hat leider kaum je einer in sämtlichen Foren ein Wort erwähnt. :(

Ein DB9 Joystick auf USB Adapter

In einer Ausgabe des Load Magazin auf der Xzentrix 2012 sah ich eine Werbeanzeige für diesen Joystickadapter zum selberzusammenbauen. Damit kann man wohl 2 klassische Joysticks mit DB9 Anschluss (C64, Amiga, Atari ST, etc) per USB an der PC anschliessen und verwenden: http://retro-donald.de/sinchai-shop/index.php?main_page=product_info&cPath=1&products_id=137

Die Firmware soll noch ein paar Macken haben und unter Linux oder auf dem Mac nicht 100% tun. Mal schauen, ich notiers mir mal im Hinterkopf und schau in Zukunft nochmal nach. Prinzipiell suche ich genau so ein Teil seit langer Zeit. Ausserdem hatte ich mal überlegt, selber eines mit AVR zu basteln, habe das Projekt aus Zeitmangel aber noch nicht angefangen.

Rezension Speed-Link SL-6512 Hornet Pad USB

Im vergangenen Winter habe ich 2 dieser günstigen Gamepads bei Amazon erstanden, damit Janina ab und an mit mir zusammen spielen kann. Das Speed-Link SL-6512 Hornet Pad USB ist ein Gamepad mit USB Anschluss und hat kaum 5€ pro Stück gekostet, ist also preislich ein Schnäppchen.

Speed-Link SL-6512 Hornet Pad USB
Speed-Link SL-6512 Hornet Pad USB

Für den Preis verdient das Pad pauschal 5 Sterne, wenn das kleine ABER nicht wäre….

Entsprechend dem Preis ist die Verarbeitung des Gamepads eher einfach und wackelig. Für Gelegenheitsspieler wie Janina ist das ok, professionelle Spieler lassen lieber die Finger weg. Dauerzocken führt vermutlich zu wegbrechenden Kontakten und Plastikbruch, ähnlich wie schon vor über 20 Jahren bei Billigjoysticks.

Ein Stern Abzug für die billige Fernostverarbeitung, aber bei dem Preis….

Das Pad wird ohne Treiber beim Einstecken erkannt und kann sofort benutzt werden. Unter Windows funktioniert alles wie erwartet.

Unter Linux funktioniert das Pad ebenfalls. Allerdings wird das Steuerkreuz nicht auf die üblichen Joystickachsen 0 und 1 gemapped, daher funktioniert das Pad unter Linux nicht mit jedem Programm. Wenn die Achsen konfigurierbar sind (MAME und MESS z.B.), kann das Pad gemapped und gut benutzt werden, ansonsten muss der Programmcode (sofern möglich) angepasst werden. Daher ein (subjektiver) Stern Abzug, zumindest für Hatari habe ich den Code gepatcht, aber bei VICE habe ich das noch nicht getan. Vllt kann man das Problem mit einem Joypad->Keyboard Mapping Programm (gibt es auch für X) umgehen, was aber die Idee, einen Joystick bzw ein Pad zu nutzen umgeht.

Bleiben noch 3 Sterne, die aber bei dem günstigen Preis immer noch gut sind. Wer für ab und an unter Windows ein einfaches Gamepad sucht, kann hier ohne Bedenken zugreifen, Linuxuser lassen lieber die Finger weg!

Link zu Amazon: http://www.amazon.de/gp/product/B00097CQWO

DOs and DO NOTs for developing Embedded Systems software

Zum Thema “Was sollte man tun und was nicht, wenn man Software für Embedded Systems entwirft und usitzt?”habe ich mal einen Artikel zusammegestellt. Dieser Artikel ist natürlich subjektiv, ich bin gerne bereit zu diskutieren. Die meisten Aspekte habe ich aber derweil schon aus verschiedenen Onlinequellen bestätigt bekommen.

http://www.final-memory.org/?page_id=2113

Im Prinzip habe ich dort mal zusammengefasst, was ich alles seit der Universität gelernt habe. Teile davon praktisch im Job, viele andere aber auch fortbildungsmäßig aus dem Netz. Im Vordergrund steht vorallem, fiese Fallen von faul programmierten C zu umgehen. Viele der Regeln und Vorschläge sind auch sprachunabhängig und können natürlich auch auf andere Programmiersprachen angewendet werden.

Ich selber habe viele dieser Regeln früher zum Beispiel nicht beherzigt. Wenn ich die Sourcen zu meiner Diplomarbeit ansehe, dann habe ich viele davon eklatant verletzt. Aber irgendwo will man ja auch einen Lerneffekt erkennen.

Als weitergehende Lektüre kann ich auch das “Embedded C Coding Standard” von Michael Barr empfehlen.

Irgendwann schreibe ich vielleicht auch noch einengrößeren zusammenhängenden Artikel oder auch ein kleines Buch. Die Liste kann sicherlich noch erweitert werden.

A ‘C’ Test: The 0×10 Best Questions for Would-be Embedded Programmers

A ‘C’ Test: The 0×10 Best Questions for Would-be Embedded Programmers – ich kam über einen Umweg zu diesem Artikel. Darin werden 16 Fragen gestellt, mit denen man einen Möchtegern Embedded C Programmierer (so wie mich auch) piesacken könnte.

Man kann so sicherlich die perfekten Nerds finden und ich gebe zu, ich selbst hätte vermutlich nicht alles 100% gewusst. Aber man sollte nie vergessen, jeder Kandidat sollte auch entsprechend lernwillig sein und vllt gerade so Dinge wie volatile, const und static nach und nach lernen. Beispielsweise im Rahmen von Codereviews.

Knallhart Aspiranten nach solchen Fragen auszusortieren, halte ich für falsch. Aber Potentiale oder auch Fehlerquellen erkennen, warum nicht.

Vermutlich muss sisch jeder selber ein Bild machen.

How to use the inline keyword with SDCC

Problem

For quite awhile I wondered why SDCC (the free Small Devices C Compilerhttp://sdcc.sourceforge.net/) would not compile inline C functions like the following:

volatile uint16_t adc_value;
/* public access function */
inline uint18_t GetADC()
{
return(adc_value);
}

Explanation

The answer is simple, SDCC follows the C standards and by default only ANSI C89 respectively ANSI C89 with SDCC extensions is enabled. But the keyword inline is part of the C99 standard so if C89 is allowed exclusively, the keyword is syntactically not allowed.

Solution

The solution is to enable C99 support with one of the possible command line options for SDCC:

  • –std-c99             Use C99 standard only (incomplete)
  • –std-sdcc99          Use C99 standard with SDCC extensions (incomplete)

Thanks to Jan Waclawek for making me investigate deeper!

Embedded Systems (englischsprachiges Wikibook)

Hier ist ein gutes und freies einführendes Buch bei wikibooks über Embedded Systems.

Das Buch beschreibt allgemeines über Eingebettete Systeme, ihren Entwurf undd as generell Hearngehen. Auch Betriebssysteme und diverse Mikrocontrollerarchitekturen werden darin besprochen.

Für Anfänger und generell Interessierte sicherlich nicht uninteressant, zumal man auf Basis eines solchen Buches auch einen kompletten Kurs gestalten kann.

Link: http://en.wikibooks.org/wiki/Embedded_Systems

Ich habe mir gleich eine PDF Version erzeugt und abgelegt.

Low-Cost kooperatives Multitasking mit State Machines

Im Internet findet man durchaus höchst interessante Artikel im Bereich Embedded.

Der folgende Artikel beschreibt ein simples, aber effizientes Konzept, um einfaches kooperatives Multitasking zu realisieren.

Die Grundidee besteht darin, jeden Teil der Applikation gezielt und by Design in State Machines mit vielen Unterzuständen abzubilden und somit ohne einen komplizierten Scheduler einfach im schnellen Wechsel kleine Automatenzustände im Wechsel abzuarbeiten.

In Summe erinnert dieser Entwurf für Software schon stark an Hardwaredesign, wie es im VHDL-Bereich zwingend nötig ist. Hard- und Software-Co-Design, da kommen wir hiermit hin.

Link: http://www.eetimes.com/design/embedded/4207786/Low-Cost-Cooperative-Multitasking-Part-1-Building-a-simple-FM-player-

Sehr lesenswert, wenn man sich für kleinere Embedded Systeme und den Entwurf von Mikrocontrollerfirmware interessiert!

Wie man effizienten C Code für Mikrocontroller und 8 Bit Systeme schreibt

Im Netz fand ich den folgenden Artikel, der recht schön zusammenfasst, wie man seinen ANSI C Code für 8 Bit Systeme und im besonderen Mikrocontroller, etwa AVR oder 8051, optimiert.

http://www.netrino.com/Embedded-Systems/How-To/Efficient-C-Code

Der Artikel ist zwar in Englisch, aber das sollte den Hobbyisten oder gar den professionellen Embedded Entwickler ja nicht schocken!

Eventuell schreibe ich nochmal eine deutschsprachige Zusammenfassung. Mal schauen…

Mein erstes Routerabenteuer: a-quip A/WLAN-4

Erstmalig brauche ich im Leben einen klassischen Router. In Clausthal im Studentenwohnheim war es nicht erlaubt, einen Router zur Teilung der IP zu betreiben, das UMTS, was ich bis vor 2,5 Monaten im Betrieb hatte, machte es nicht sinnvoll und davor hatte ich daheim nie Breitband.

Kabel BW macht es möglich und nun habe ich seit Mitte März qualitativ hochwertiges Breitbandinternet im Haus. Natürlich wollte ich auch meine Ataris entgültig mit der Welt vernetzen, und nicht nur lokal mit dem regulären PC. Ergo muss endlich doch eine Routerlösung daher.

Vorigen Samstag ging ich daher shoppen und kaufte einen Router, der zunächst alles zu halten schien, was er versprach. Ich hatte mir im MediaMarkt einen günstigen a-quip A/WLAN-4 Router gekauft.

Anstöpseln und grundlegend konfigurieren ging auch ganz leicht. Per Default war ein sinniges Subnetz eingestellt und er erkannte auch automatisch meine über DHCP angebundene Internetverbindung. Das Problem kam dann im 30 Minuten Takt. Bei ICQ und Skype war plötzlich die Verbindung weg und wieder da. Im IRC konnte  ich dies durch ominöse Reconnects beobachten. Was war los?

Der Router kam offenbar nicht mit den DHCP-Einstellungen des Providers zurecht. Er machte brav einen Refresh und damit praktisch einen Neustart, obwohl sich zugeteilte IP und andere Verbindungsdaten nicht geändert hatten. Gehe ich da von zuviel Intelligenz im Gerät aus?

Jedenfalls konnte ich das Problem dann sogar auch über Nacht im Routerlog beobachten, zu einem Zeitpunkt, wo keinerlei Rechner im LAN aktiv waren. Damit konnte es nur am Router liegen.

Lars riet mir zu einem Firmwareupgrade. Das hat mir aber nicht geholfen. Das Problem blieb bestehen. Da meine Supportanfragen ins Leere liefen, bin ich ehrlich enttäuscht. Das Gerät kommt wenn irgendmöglich zurück und wird gegen ein Exemplar getauscht, welches offiziell mit Kabel BW zusammenarbeiten kann.

Testverdikt für a-quip A/WLAN-4: mangelhaft