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.
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.
Da mein neuer ACER AS X1301-3 von Haus erstmal keine RS232 Schnittstelle mitbrachte, hatte ich schon beim Kauf darüber nachgedacht. Schließlich brauche ich einen solchen Port für meine Mikrocontrollerprojekte und -basteleien.
Da der Rechner laut Datenblatt über einen PCI Express x1 Slot verfügte, kaufte ich gleich eine passende Steckkarte mit. Heute morgen habe ich mich dann daran gemacht , die Karte einzubauen. Das Garantiesiegel am Rechner habe ich geflissentlich ignoriert und die Seitenverdeckung abgeschraubt.
ACER AS X1301-3 von innen (PCIe Slots oben rechts)
Wie man schön sieht, ist die Grafikkarte doch nicht Onboard, sondern belegt einen PCI Express x16 Slot ganz oben. Immerhin, das erlaubt später mal einen Austausch. In den x1 Slot darunter setzte ich also die RS232 Karte von Delock. Genau eine Delock 89236 mit 16C950 Uart.
Delock 89236 RS232 für PCI Express x1
Windows 7 erkannte die Karte erstmal nicht, mochte sie aber nach dem ich von der Treiber-CD einen passenden Treiber eingespielt hatte. Mit Teraterm konnte ich dann auf mein Phytec Mikrocontrollerboard über die frische RS232 zugreifen. Warum Windows die Schnittstelle allerdings als COM3 einbindet, wenn es sonst keine RS232 im System gibt, erscheint mir aber fragwürdig.
Unter Linux war es zunächst etwas wackelig. Beim ersten Booten zeigte der Kernel die Schnittstelle zwar korrekt über dmesg an, aber beim Zugriffsversuch bekam ich einen I/O Error.
[ 0.650679] Serial: 8250/16550 driver,
4 ports, IRQ sharing enabled
[ 0.650942] serial 0000:03:00.0:
PCI INT A -> Link[AE2A] -> GSI 16 (level, low) -> IRQ 16
[ 0.650950] 1 ports detected on
Oxford PCI Express device
[ 0.651010] ttyS0: detected caps 00000700
should be 00000100
[ 0.651014] 0000:03:00.0: ttyS0 at MMIO 0xfd9fd000
(irq = 16) is a 16C950/954
Nach einem Reboot funktionierte es allerdings und ich konnte das Board wie unter Windows mit gtkterm ansprechen:
GTKTerm
Ob die Schnittstellenkarte auch mit meinem AVR-Board harmoniert, muss ich noch herausfinden. Da allerdings Linuxseitig der reguläre Treiber für RS232 Schnittstellen verwendet wird, bin ich eigentlich recht zuversichtlich.
Insgesamt müsste die Delock 89236 Karte damit Linux tauglich sein!
