ARM Hardware und Programmierung

[mschnell]

./.

[Marcovaldo]

]Meinst Du mit "recht einfach" den DIL-Formfaktor mit 2,54mm Pin-Abstand ? ...

Genau. Die SSV-Module kommen im 2.54 Raster, der wie Du richtig sagst zB auch per Wire-Wrap (Hmm, habe auch noch ne CSW-Pistole rumsegeln...)
oder auf Lochraster gesetzt werden kann. (Standard 64-Pin Sockel, bzw beim ADNP9200 gibts noch zwei extra Reihen aussen dran)...

Ich habe (bisher) als Kleinstfirma die Hände von SMD, BGA etc gelassen, sondern SC12 von Beck(X86 Mini-PC im DIL-32 Modul) verwendet(unter BP7).
Diese Dinger sind ausgelaufen, und für die Nachfolger gibts keine Pascalcompiler.....

Ebenso kenne ich Firmen, die Module von zB Kontron mit SIMM Stecker verwenden(verwendeten). Da gibts 2 Probleme:
- Fürs Gegenstück gibts nur SMD-Buchsen
- Diese Steckverbindungen sind eben nur für (schmale) Memory-Module gedacht. Bei (etwa Scheckkartenformat oder größer) CPU-Modulen gibts mitunter
Probleme mit Vibration etc(Hebelarm der schwingenden Platine), dadurch mechanische Befestigung am gegenüberliegenden Ende dringend anzuraten...

Für viele höherintegrierte Module gilt leider ähnliches(die Board to Board Stechverbinder sind SMD Finepitch und hobbymäßig nicht nett zu löten...)

Für die DIL-Module ließen sich auch mit einfachen Mitteln (zB Eagle, PCB-Pool) applikationsspezifische Trägerplatinen erzeugen. Falls eine Ethernetbuchse
mit integriertem Trafo verwendet wird, sogar komplett in Through-hole. Also zB wäre eine art BDE Terminal (mit Anschluss für LCD-Display), ein paar Tasten,
USB, Seriell etc leicht möglich.

Andi: Von SSV (ich bin bei denen nur Kunde für bisher zwei Demokits!**) gibts auch kompatible Protokollkonvertermodule
http://www.ssv-comm.de/de/produkte/igw800.php" onclick="window.open(this.href);return false;


LG,

Christian

**) Einer der Punkte, die für mich wichtig sind(nach der Erfahrung mit auslaufenden Plattformen), daß die Software in Zukunft auch leicht auf
andere ARM-Plattformen portiert werden kann.

PS: Der Minimal-Code(hello) auf dem Visionsystem Alekto(derzeit noch Etch, werde ich heute auf Lenny bringen) mittels FPC kompiliert läuft auf dem
DNP9200.Melde mich in Kürze wieder zurück ;-O

[Marcovaldo]

Ich suche für ein selbst zu bauendes einfaches Meßgerät so etwas. Auf der einen Seite benötige ich dann eine RS485 (RS232) Schnittstelle und die Möglichkeit über das Display Werte auszugeben, weiter Schnittstellen (Ethernet etc. sind nur 'nice to have' aber kein 'must'). Auch was so ein Einstieg kostet würde mich interessieren.

Hallo Andi,

Das ADNP EVA-Kit, das ich habe(und Dir borgen kann), hat ein 128x64 Grafikdisplay (POWERTIP PG-12864F) on Board (Basisplatine des EvaKits nennt sich
EVA11) Auf dem Displaymodul sitzt der verbreitete T6963 von Toshiba (C-Sourcen vorhanden, Pascal muss ich nachsehen, ist aber sicher was was ich erstellen könnte; Kompatible Module(andere Größe) müsste ich auch rumsegeln haben(bin ja ein Segler...))
http://www.powertipusa.com/pdf/pg12864f.pdf" onclick="window.open(this.href);return false;

Hardware-Referenz des EVA11
http://www.dilnetpc.com/DNPEVA11-HWR.pdf" onclick="window.open(this.href);return false;


LG,

Marcovaldo

[Marcovaldo]

Hallo,

Noch ein paar Infos:
Auf der Suche nach Pascal-Sourcen fürs Grafikdisplay bin ich auf einen Touchscreen der dafür passen könnte gestoßen
http://www.tigal.com/1345" onclick="window.open(this.href);return false;
http://www.circuit-ed.com/128x64-BLWH-T ... 146C8.aspx" onclick="window.open(this.href);return false;
Die haben sonst auch noch einiges ....

LG,

Marcovaldo

[hotzenplotz]

Das Thema interessiert mich auch. Vor allem die Atmel AVR-RISC Familie im speziellen im moment der ATmega88. Die Bascom Programmierung ist kein Problem. Aber das ganze mit Lazarus wär schon verdamt geil! Auch wenn das nix mit nem Grafik Display speziell zu tun hat.

[mschnell]

Mit Lazarus für AVR sieht es wohl schlecht aus. Da musst Du erst 'mal den FPC-Compiler portieren. Möglich, aber bestimmt viel sehr "interessante" Arbeit.

Warum findest Du denn AVR besonders interessant ? Ist doch auch nur eine RISC-Architektur von vielen. Und da ist ARM halt die (bei weitem) am weitesten verbreitete - und es gibt FPC dafür.

-Michael

[mschnell]

Pascal muss ich nachsehen...

Wenn das EVA einen vernünftiges BSP hat, hast Du mit "Pascal für das Display" keine Sorgen. Dann sollte das Display einen Kernel-Treiber haben, der für die Userland-Software eine Hardware-unabhängigen Schnittstelle (Device-File oder vielleicht sogar X) zur Verfügung stellt.

-Michael

[Marcovaldo]

Wenn das EVA einen vernünftiges BSP hat, hast Du mit "Pascal für das Display" keine Sorgen. Dann sollte das Display einen Kernel-Treiber haben, der für die Userland-Software eine Hardware-unabhängigen Schnittstelle (Device-File oder vielleicht sogar X) zur Verfügung stellt.
-Michael

Soviel ich sehe hat es das nicht. Das Ding ist mM auch für X zu klein. Es existiert lediglich eine C-Beeispielanwendung, die Zeichen ins Display schreibt...

-Marcovaldo

[mschnell]

Es existiert lediglich eine C-Beeispielanwendung, die Zeichen ins Display schreibt...

Wenn kein entsprechender KernelTreiber (in C) existiert, geht das mit Lazarus, das ein Userland Programm erzeugt, gar nicht. Du musst also zuerst den Kernel-Treiber basteln.

-Michael

[Marcovaldo]

Wenn kein entsprechender KernelTreiber (in C) existiert, geht das mit Lazarus, das ein Userland Programm erzeugt, gar nicht. Du musst also zuerst den Kernel-Treiber basteln.
-Michael

Kann es sein, dass man auch an dem OS vorbeiprogrammieren kann? Ein Kernel-Treiber ist sicher die sauberste Lösung aber bis ich sowas zusammenbringe,
vergeht noch einige Zeit...(ich kann mich noch daran erinnen, unter DOS seinerzeit den TP Textfiletreiber auf LCDs am Druckerport umgebogen zu haben...)
Anbei ist der Beispielcode in C. Soviel ich verstehe, verbiegen die das Memorymapping durch direkten CPU-Register Zugriff, um den Adressbereich des Displays
einzublenden(CPU-Register, Direkt-Memory-Zugriff; sicher ist sowas eher am OS vorbeigemogelt... aber bei embedded Systemen gelten auch eventuell andere
Kriterien)

-Marcovaldo

[Marcovaldo]

hier ist der code

lcdtxt_at91.txt

Beispielsource(C) Grafik-LCD an ADNP9200

(18.89 KiB) 80-mal heruntergeladen

[mschnell]

Der Beispiel-Code wird nicht funktionieren. Er schreibt direkt auf eine I/O-port. das geht im user-Mode nicht.

"Am Betriebssystem vorbei" ist möglich, wenn Du z.B. "uio" verwendest (das ist ein "allgemeiner" Treiber, der bestimmte Ausgaben im User-Mode ermöglicht). Habe ich aber noch nicht ausprobiert. ( z.B.: http://docs.blackfin.uclinux.org/kernel ... index.html" onclick="window.open(this.href);return false;, http://www.mjmwired.net/kernel/Document ... howto.tmpl" onclick="window.open(this.href);return false; )

Eine andere variante ist ioperm ( http://www.linuxinfor.com/german/man2/ioperm.html" onclick="window.open(this.href);return false; ).

-Michael

[Marcovaldo]

Der Beispiel-Code wird nicht funktionieren....
-Michael

Tut er aber
Muss ich mir noch etwas genauer ansehen, warum hier funktioniert was nicht funktionieren kann (und darf? - oder umgekehrt)
Beim Kleineren Modell, das ein Hitachi_controller kompatibles Zeichen-LCD besitzt, läuft der Beispielcode nämlich. Ebenso gibt es Beispiele um
zB Schalter einzulesen..

-Marcovaldo

PS:
Vorerst muss ich aber noch den FPC auf dem Alekto unter Lenny zum Laufen bringen(Unter Etch lief FPC 2.2.2 nämlich)

[af0815]

Es hängt davon ab, in welcher Umgebung der Code für direkten I/O läuft. Ist es ein multitasking fähiges System, so dürfen die Resourcen ja ohne Managment nicht einfach verteilt/genommen werden (bsp. Linux).
Nur der FPC alleine ist kein Kriterium dafür, der kann mit (fast) jeder Umgebung arbeiten.

Ich habe übrigends ein ARM-Device (GTA02) bei mir (wieder) gefunden. Mal sehen ob ich diesmal das Cross-Compiling hinbekomme.

[mschnell]

Tut er aber

In einem mit Lazarus erstellten Programm das auf Linux läuft ?
-Michael