Leider ist meine freie Zeit für Hobbies eh schon begrenzt und ich arbeite kaum mehr mit dem, was ich schon an 8051, AVR und R8C im Schrank liegen habe. Ansonsten würde ich mit so einem Käfer mal gerne loslegen. Natürlich ohne einen BASIC Compiler, sondern mit einem GCC.
Zum Ausgleich habe ich den Mikrocontrollerspaß ja im Job. Für mein aktuelles Softwareprojekt bekomme ich hoffentlich auch bald die AVR basierte Hardware auf den Tisch.
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
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.
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.
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
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!
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.
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.
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.
For quite awhile I wondered why SDCC (the free Small Devices C Compiler – http://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!
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.
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.
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.
