hallo forum,
möchte auf einem embedded mini - itx eine Windwows Applikation
programmieren.
Ich habe an WinCE gedacht. CPU ist zum Beispiel ein AtomZ530. Ein Board
habe ich schon gefunden. Ich bekomme es mit mit installierten WinCE und
allen Treibern.
Benötige ich für das Visual Studio (2005 / 2010) noch eín spezielles SDK
damit ich die Applikation entwickeln und debuggen kann?
Wenn ja, wo bekomm ich das her?
Ich weiss, sind Basics, habe aber nichts in Netz gefunden.
Danke für eure Hilfe.
Rick
Du auf dem Atom kannst Du auch ein normales Windows drauf tun und ganz
normal entwickeln. Das ist ja das Elegante an einer x86 Architektur.
Aber bei so grundlegenden Fragen würde ich erstmal mit Linux anfangen.
Da ist die Entwicklung deutlich weniger frustrierend.
rick new schrieb:> Benötige ich für das Visual Studio (2005 / 2010) noch eín spezielles SDK> damit ich die Applikation entwickeln und debuggen kann?
Ja, Du brauchst die Programmierunterstützung für Windows CE. Windows CE
kann keine normalen Windows-Binaries ausführen.
> Wenn ja, wo bekomm ich das her?
Von Microsoft.
Allerdings: Warum willst Du ausgerechnet auf normaler PC-Hardware
Windows CE laufen lassen? Besser geeignet (weil unkomplizierter,
vertrauter und binärkompatibel) wäre XPe.
Christian Berger schrieb:> Aber bei so grundlegenden Fragen würde ich erstmal mit Linux anfangen.> Da ist die Entwicklung deutlich weniger frustrierend.
Ohne Grafik wäre Linux okay, aber mit X und dann der msitige
US15W-Grafikchipsatz, na dann lieber ein anderes Board mit ohne Atom
Z5XX-CPU.
Hallo miteinander,
Danke für Eure Antworten.
Grund für Windows CE: ein gekaufter EtherCAT Master garantiert nur unter
WinCE Echtzeit (Windows Embedded Compact 7.0 geht auch).
Für XPembedded müsste eine Echtzeiterweiterung gekauft werden (z.B.:
INtime). Dafür musst du dann wieder extra Lizenzkosten zahlen. Darum
WinCE.
Die Applikation sollte auf einem Echtzeit Ethercatmaster aufbauen.
lg rick
Entschuldigung, aber Du willst industrielle Steuerung in Echtzeit über
Ethernet und mit Windows machen? Tut mir Leid, aber davon muss ich Dir
bei Deinem Kenntnisstand abraten. Das mag vielleicht einfach aussehen
ist aber etwas, was ich ohne jahrzehntelange wirklich tief gehende
Erfahrung nicht versuchen würde.
Also setzt Dich bitte zunächst erst mal mit folgenden Themen
auseinander:
Ethernet (dann wirst Du übrigens schon mal feststellen, dass darüber
Echtzeit eigentlich nicht geht)
Netzwerksicherheit
C/C++ Programmierung (wirklich lernen, kein "Lerne C/C++ in 2000 Tagen"
Schellkurs!)
Windows (kein billiger MSCE Kurs, sondern die ganze Geschichte mit
Systemarchitektur seit Windows 3.0 und der kompletten API)
Das ist alles hoch komplex. Alleine Windows XP hat 40 Millionen
Codezeilen. Die Embedded Versionen haben sicherlich auch nicht viel
weniger. Das zu beherrschen ist eine gigantische Aufgabe.
Was dabei herauskommt, wenn man das nicht kann, hast Du ja hoffentlich
bei Stuxnet gesehen.
Wenn der HW Lieferant ein BSP (Board Support Package) mitliefert ist es
ziemlich einfach. Früher gab es eigene Compilerversionen für CE, heute
müsste das im VS drin sein (oder über Plugin nachrüstbar). Es gibt aber
auf der MS Embedded Seite Tutorials und Videos, such erstmal danach.
@Christian: EtherCAT ist nicht Ethernet, deshalb ist hier Echtzeit
garantiert. Gruselig wird nur das Thema Safety SPS...
C# macht echt keinen Spass auf Windows CE, schon nur deshalb weil das
.NET Compact Framework teilweise an den bescheuertsten Stellen
abgespeckt ist.
>Benötige ich für das Visual Studio (2005 / 2010) noch eín spezielles SDK>damit ich die Applikation entwickeln und debuggen kann?>Wenn ja, wo bekomm ich das her?
Du brauchst Visual Studio 2005 / 2008 Professional. 2010 unterstützt
keine Smart Devices (so nennt das Microsoft halt).
Weiter müsste dir der Boardhersteller ein SDK für dein Board liefern.
Dort drin sind in erster Linie Windows CE Header die an das OS deines
Boards angepasst sind (oder es sein sollten).
Ja, ein bisschen Ressourcen braucht X halt schon...je nachdem halt
zuviel.
Wenn du ein Gerät baust, auf welchem zum Schluss nur eine einzige
Applikation fullscreen läuft dann sitz auf den Framebuffer und gut ist.
Zwie Blum schrieb:> Abgesehen davon, dass es den TE nicht interessiert, aber wo ist das> Problem bei X?Bartli schrieb:> Ja, ein bisschen Ressourcen braucht X halt schon...je nachdem halt> zuviel.
Die Ressourcen sind weniger ein Problem, wenn genug RAM da ist, kann der
Atom das schon.
An Bartli und Zwie Blum:
Das es keinen vernünftigen Treiber für X beim US15W gibt. Es gibt einen
geschlossenen, der nicht weiterentwickelt wird und nur bei Prä-KMS
Linux-Kerneln funktioniert oder EMGD, den gibt es bei Intel und der
läuft aber nur mit bestimmten Xorg- und Kernel-Versionen. Getestet wird
der nur für MeeGo und (alten) Fedora-Versionen.
Um es deutlich zu sagen, irgendwie geht es, man hat aber viele
Einschränkungen. Wenn man nicht muss, lässt man es und holt sich was
anderes mit einem anderen Grafikchipsatz.
Um ein Zeichen für Intel zu setzen, am besten keinen von Intel.
Intel hat den damals schön angepriesen und eine Ubuntu-Version
funktionierte damit auch gut. Danach ging es nur noch abwärts,
mittlerweile gibt es bei Ubuntu in PPAs ein paar Lösungsansätze, aber
als ich vor einem halben Jahr dran war, war das auch alles nichts Halbes
und nichts Ganze. Zumal ich die PPA-Software nicht als Lösung für die
Industrie ansehe.
Der 3.0er soll mit dem psb-gfx und dem fbdev halbwegs funktionieren,
habe ich aber nie getestet.
Bartli schrieb:>> Ohne Grafik wäre Linux okay, aber mit X...> Wozu X? Qt oder was auch immer auf fbdev und los geht's.
Kann der fbdev den Widescreen? Ansonsten ging der und auch Vesa, aber
halt nie mit Widescreen. War damals so ein Ding für einen Kunden, der
einen Widescreener in Hochformat wollte, okay, drehen geht nur mit fbdev
aber die Auflösung hat der nie gekonnt. Da habe ich dann eine alte
EMGD-Version mit Debian 6.0.1a eingerichtet. Wie gesagt, es geht, aber
mit, selbst für Linux, vielen Einschränkungen.
Auch mit xorg.conf habe ich es seinerzeit nicht hinbekommen, mit uvesafb
konnte ich sogar der Shell Widescreen bei bringen, aber wenn X kam,
zack, war wieder alles verzehrt.
Ich hab' hier X11 auf 64 und 32 MB laufen (ARM, aber das ist ziemich
egal), Debian ist da ein 'bischen' zäh, aber buildroot baut eine sehr
schnelle Umgebung. Deshalb meine Fragm wo das Problem bei X liegen soll.
Das mit dem Inteltreiber ist ja leider die alte Marketinggeschichte bei
Consumerprodukten, eary adopters können sich (wie immer) in den A...
beissen ;-)
