Posts by fs-support_HK

    Quote from "Ralf"

    Es könnte eventuell am Format NTFS liegen, das für das System zu grosse Zuordnungseinheiten hat.


    Für NTFS ist in WinCE kein Treiber dabei. Das geht also definitiv nicht.


    Quote

    Habe versucht die Festplatte mit FAT zu formatieren. Geht aber nicht bei dieser Grösse.


    Geht schon, nur verweigert WinXP dies (aus mir mal wieder nicht ersichtlichen Gründen) bei so großen Platten/Partitionen. Man wäre also auf ein externes Formatiertool angewiesen, welches das trotzdem macht. Mit meinem alten WINME war es problemlos möglich, auch größere Platten mit FAT32 zu formatieren. Theoretisch können mit FAT32 Platten bis zu 2TB formatiert werden.


    Wie zum Beispiel hier zu lesen ist, unterstützt Windows CE 5.0 maximal Partitionen mit 32GB und das gesamte Medium darf maximal 2TB haben. Bei WinCE 6.0 geht sogar noch mehr.


    Dabei ist die maximale Dateigröße auf jeden Fall aber auf 4GB beschränkt.


    Mit freundlichen Grüßen,


    H. Keller

    Pin 1 auf J5 war traditionell immer ein IRQ-Eingang. Entsprechend wurde er vom GPIO-Treiber nicht direkt verwaltet. Selbst wenn auf den neueren Boards dieser zwar technisch gesehen vielleicht auch als normaler I/O verwendet werden könnte, unterstützt dies der Treiber einfach nicht.


    Mit freundlichen Grüßen,


    H. Keller

    When memory was shown as low, then maybe your application has a memory leak, i.e. it continuously allocates memory but misses to free it again. Included with EVC++ or VS2005, there is the so called "Remote Heap Walker". This tool allows a check of the heap of any process. Probably by looking at the heap of your program at different stages, you can find some data there that should already have been freed again.


    Best regards,


    H. Keller

    So kurios es klingt, ich glaube das hat noch nie jemand ausprobiert. Wobei ich eigentlich keinen Grund sehe, warum es nicht funktionieren sollte. Ein USB-Stick ist genauso ein Mass Storage Device wie eine Festplatte. Auch beim Memory-Stick werden im USB-Protokoll die Befehle einer Festplatte simuliert.


    Es käme also mal auf einen Versuch an. Möglichst mit einer Platte ohne mehrere Partitionen probieren, denn das könnte evtl. noch ein Problem sein.


    Gruß,


    H. Keller

    The following example shows how to create a button with user defined content (style: Owner draw).


    The example creates a dialog with just one button. But instead of the normal way of showing the text content in black, it shows a red text. Any other content is also possible, just define something else in the DrawItem() method.


    The example was done with EVC++ 4.0 and uses MFC with the MFC wizard to create the dialog and button. Therefore the button is defined as a C++ class CMyButton.


    The basic steps to create this application are:


    • In Resource Editor, create dialog with button, in this case IDC_MYBUTTON and style "Owner draw"
    • With MFC Class Wizard, create a new class "CMyButton" with base class CButton.
    • With MFC Class Wizard for Class CMyButton, for Message "DrawItem" (not WM_DRAWITEM!) add a function that actually draws the contents of your button. In this case it draws the text in red.
    • With MFC Class Editor, Tab Member Variables, in the dialog class, add variable "m_MyButton" for IDC_MYBUTTON with the above type CMyButton.
    • Add OnButton() function to dialog as required to react to a button press.


    Regards,


    H. Keller

    Wir haben ja in der Zwischenzeit auch telefoniert. Wenn ActiveSync das Board nicht einfach durch Einstecken erkennt, obwohl die NetDCU per DIP-Switch korrekt auf USB-Device konfiguriert ist, dann könnte das Löschen der Registry vielleicht helfen.


    Schritt 1: NetDCU mit seriellem Kabel an PC verbinden (Debug-Schnittstelle)


    Schritt 2: DCUTermi auf dem PC starten. Wenn das Board nun gestartet wird, müssen diverse Meldungen zu sehen sein, z.B. die Version des Bootloaders, die Version von Windows, diverse Treiber, die ihre Meldungen ausgeben, usw. Achtung! Wenn Sie stattdessen das NDCUCFG-Tool sehen, ist es die falsche Schnittstelle. Dann die Schnittstelle gegenüber benutzen.


    Schritt 3: Am PC im DCUTermi die Taste 'S' drücken (großes S, nicht kleines s!!) und gedrückt halten, so dass sich das 'S' sich wiederholt. Gleichzeitig parallel das Board neu starten.


    Schritt 4: Nun sollte das Board nicht ins Windows booten, sondern im Bootloader stehen bleiben. Hier nun den Befehl 'R' eingeben. Die Frage, ob die Registry gelöscht werden soll mit 'y' bestätigen. Dadurch werden wieder alle Standard-Einstellungen aktiviert.


    Schritt 5: Das Board neu starten. Es müsste nun wieder das Windows hochfahren.


    Schritt 6: Nochmal probieren, ob ActiveSync nun das Board erkennt. Falls nicht, auch mal probieren, das USB-Kabel auf NetDCU-Seite nochmal aus- und nach ein paar Sekunden wieder einzustecken.


    Wenn alles nichts hilft, ist vermutlich die USB-Device-Schnittstelle defekt. Dann müssen Sie das Board wohl oder übel einschicken.


    Mit freundlichen Grüßen,


    H. Keller

    Quote from "Kaiser"

    1) Wo sind die restlichen 13MB RAM Memory, wenn unter "System Properties/General" 21MB verfügbar sind?


    Ein Teil des Speichers wird für das OS benötigt. Darin werden die Datenstrukturen und Variablen des Kernels wie z.B. die Pagetables für das virtuelle Speichersystem verwaltet. Auch der Kernel selbst kann nicht aus dem Flash heraus laufen, sondern wird ins RAM geladen, inklusive aller Treiber für die Hardware. Das sind die "fehlenden" MB.


    Quote

    2) Was genau ist "Storage Memory" und was "Program Memory"?


    Der restliche Speicher, der nicht direkt vom OS gebraucht wird, steht einerseits für Programme und deren Heaps und Stacks zur Verfügung (Program Memory) und andererseits für das virtuelle Filesystem. Wenn Sie z.B. in das Wurzelverzeichnis oder in das Windows-Unterverzeichnis Dateien abspeichern, dann liegen diese Daten nur im RAM in einer Art RAM-Disk. Das ist dann das Storage Memory.


    Da ein WinCE-System keine Auslagerungsdatei besitzt, muss der maximal für Programme zu nutzende Speicher konkret angegeben werden. Wenn Sie nur wenige bis gar keine Dateien ins RAM-Filesystem abspeichern wollen, dann können Sie den Bereich für das Program Memory entsprechend groß und für Storage Memory sehr klein machen. Standardmäßig ist der freie Speicher jedoch 50:50 aufgeteilt.


    Quote

    3) Wie kann der Wert für "allocated memory" für storage oder program per registry oder per ndcucfg verändert und gespeichert werden? Oder ist dies nur über diesen Schiebebalken möglich? Ändere ich den Wert per Schiebebalken, dann ist er nach dem Neustart wieder wie bisher. In der Registry finde ich auch keinen Eintrag mit "memory".


    Einen Registry-Eintrag hierzu gibt es leider nicht, auch kann die Einstellung nicht dauerhaft gemacht werden. Wie die Aufteilung aber per Software beim Systemstart einzustellen geht, darüber gibt es schon einen ausführlichen eigenen Beitrag (klick mich).


    Mit freundlichen Grüßen,


    H. Keller

    Das Display selbst oder der Inverter des Backlights erzeugen häufig recht starkes Rauschen auf den Touch-Leitungen. Dann wird der Messfehler bei der Kalibrierung zu groß und die Kalibrierung muss wiederholt werden. Hier hilft es oft, wenn das Touch und die Leitungen so weit vom Display/Inverter weg kommen wie möglich.


    Die Kalibrierung selbst muss schon sehr präzise durchgeführt werden. Auch wenn später die Bedienung problemlos mit dem Finger geht, kann es sein, dass die Kalibrierung mit einem Stift o.ä. durchgeführt werden muss.


    Wenn alles nichts hilft, kann der Registry-Wert


    HKLM\HARDWARE\DEVICEMAP\TOUCH\MaxCalError


    erhöht werden. Dieser Wert gibt an, welcher maximale Fehler bei der Kalibrierung noch akzeptiert wird.


    Weitere Infos auch in diesem Thread.


    Mit freundlichen Grüßen,


    H. Keller

    The newly designed web site is now up and running. It allows for easier navigation, has a fresher look-and-feel and you'll find other improvements in many places. Please enjoy the new F&S web site experience.


    Comments are always welcome.


    Best regards,


    Your F&S-Team

    The NetDCU boards can drive nearly any kind of display, from monochrome STN displays up to TFT color displays. We don't know what kind of display the end user will use and therefore we (F&S) don't supply the display at all. Because of this we also can not provide any information about "the" display of the starter kit on our web site, because there is no such display. But we have general information about all displays we have ever connected to the appropriate NetDCU, for example here is the List of known displays for NetDCU8.


    If you have received a display together with the starter kit, then it is a special package from your distributor. Therefore if there is anything missing from the display (cable, adapter, documentation), then you have to contact your distributor. We are sorry if this happens because we want to make your first experience with the NetDCU as easy and successful as possible.


    Regards,


    H. Keller

    Quote from "Kaiser"

    Are there some useful and no expensive tools to detect some memory leaks?
    Or maybe some memory monitor tools which could help to detect such memory leaks?


    If you are working with EVC++, there is the Remote Heap Walker that can help. When debugging, for example in a regularly encountered breakpoint, you can update the heap view and there you can see what is stored in the heap. Then you can recognize when the heap grows and grows or contains elements that you don't expect to be there anymore.


    Regards,


    H. Keller

    'S' steps into EBoot, 's' steps into NBoot. As most people update their software via USB or Ethernet, the serial update is not very often used, especially as the kernel can not be updated in this way and therefore one of the other update procedures must be used anyway.


    By the way, the 'Flash Erase', 'Flash Write' and 'All' functions have no meaning with the NetDCU series. The DCUTermi program is also used together with our DCU series of boards and these functions do some basic work there.


    Best regards,


    H. Keller

    Bei dem hier vorliegenden Treiber gibt es nicht in dem Sinne einen Empfangspuffer, sondern nur einen Event-Puffer. Empfangene Nachrichten sind somit nur *eine* Art von verschiedenen möglichen Events. Entsprechend erzeugt z.B. auch jede gesendete Nachricht einen Event, der im Eingangspuffer aufläuft. Zwar werden nur die Receive-Events als lost gezählt, aber alle anderen Events belegen trotzdem Platz. Und wenn der ganze restliche Eingangspuffer mit solchen Events gefüllt ist, passiert es schon mal schnell, dass eine regulär empfangene Nachricht keinen Platz mehr hat.


    Ich denke auch in Ihrem Beispiel ist der Sleep(0) ein gewisses Problem. Es scheint, dass in Ihrem CAN-System viele Nachrichten unterwegs sind. Wenn Sie da nach jedem empfangenen Event den Prozessor an andere Threads/Prozesse abgeben, die im Worst-Case ihre volle Zeitscheibe aufbrauchen, also immerhin 100ms mal Anzahl rechenbereiter Threads, dann kann es sehr schnell sein, dass der Event-Puffer vollläuft und Sie mit lesen nicht mehr hinterher kommen.


    Noch eine letzte Möglichkeit, die hier eine Optimierung bringen könnte: ein AcceptanceFilter. Durch Vorgabe einer solchen Maske werden nur noch die Nachrichten von der NetDCU empfangen, die auf dem CAN-Bus direkt an sie adressiert sind. Das kann ggf. die Menge der Nachrichten auch nochmal drastisch verringern.


    Mit freundlichen Grüßen,


    H. Keller

    Vielleicht fangen wir nochmal ganz von vorne an. Es wird langsam etwas konfus, alles noch nachzuvollziehen, was nun schon von Ihnen gemacht wurde und was nicht.


    Vielleicht zuerst noch ein paar Sätze zum Konzept der NetDCU. Die NetDCU stellt eine Windows-CE-Plattform zur Verfügung. Windows CE ist Industriestandard, das heißt es ist für sich schon umfassend bei Microsoft dokumentiert. Und es macht keinen Sinn (und ist auch urheberrechtlich gar nicht möglich), diese Information bei uns noch einmal bereit zu stellen. Insofern müssen wir eine gewisse Kenntnis über die grundsätzlichen Möglichkeiten und die Nutzung von Windows CE einfach voraussetzen. Das beginnt bei den Fähigkeiten des Desktops, geht über die grundsätzliche Programmierung bis hin zur Funktion und Verwendung der Registry. Viele Dinge davon eignet man sich zwar häufig erst an, wenn man mit so einem Board arbeitet, aber die Informationsquelle dafür ist dann eben Microsoft.


    Letztendlich heißt das aber, dass wir hauptsächlich diejenigen Dinge beschreiben, die für unsere Boards speziell sind, da sie von uns entwickelt wurden und somit nicht zum Allgemeinwissen gehören können. Dies in halbwegs einfacher Form zu vermitteln ist aber nicht immer einfach, bedenkt man den unterschiedlichen Wissensstand unserer Kunden und die Komplexität solcher Boards. Die Dynamik, mit der wir kontinuierlich unsere Boards inklusive Treiber und Software weiterentwickeln, stellt eine zusätzliche Erschwernis dar.


    Letztendlich bedeutet dies für jeden, der mit unseren Boards beginnt, eine gewisse Einstiegshürde. Das wird vermutlich bei anderen Plattformen nicht anders sein. Die Erfahrung zeigt aber, wenn diese Hürde einmal überwunden ist, dann läuft eigentlich alles recht rund und unsere Kunden sind sehr zufrieden mit den Boards. Hierzu bieten wir einen Workshop an, wo dem Kunden genau diese ersten Schritte ausführlich erklärt werden. Es ist also möglich, diese Einstiegshürde innerhalb von 4 Stunden zu überwinden. Ich denke, das ist kein schlechtes Angebot und ich glaube nicht, dass dies woanders effizienter geht.


    Wenn Sie nun nicht an so einem Workshop teilnehmen wollen/können, stellt das für uns ein gewisses Problem dar. Es ist eben nicht so einfach möglich, dieses Wissen in Form von Forumsbeiträgen oder sonstigen Artikeln ähnlich kompakt und umfassend rüberzubringen, wie in einem persönlichen Dialog und im direkten Kontakt mit dem Board, bei dem man immer individuell auf die Gegebenheiten eingehen kann.


    Versuchen wir es dennoch ein wenig.



    NetDCU-Ãœberblick


    Die NetDCU-Boards stellen diverse Schnittstellen und Hardware-Fähigkeiten bereit. Je nach Board sind diese unterschiedlich. Wir, die Firma F&S, stellen für nahezu alle dieser Schnittstellen Treiber bereit, so dass die Hardware möglichst einfach über die Software angesprochen werden kann. Soweit wie möglich versuchen wir dabei, gleiche Schnittstellen, sofern jeweils verfügbar, auf den unterschiedlichen Boards auch gleich zu handhaben. Dennoch kann es sein, dass gewisse Einstellungen sich im Detail trotzdem minimal unterscheiden, es sind nun mal verschiedene Boards. Jedoch beschränkt sich das fast immer auf die Grundeinstellungen, die bei Windows CE in der sog. Registry vorgenommen werden. Ansonsten ist die reine Benutzung einer Schnittstelle später nahezu identisch.


    Aus diesem Grund kann auch die Dokumentation in großen Teilen von Board zu Board übernommen werden. So kann es sein, dass speziell in der Anfangsphase, wenn ein Board noch relativ neu auf dem Markt ist, eben noch beim einen oder anderen Treiber auf die Dokumentation anderer Boards verwiesen wird, bis eben eine entsprechende Anpassung erfolgt ist.



    Boot-Vorgang


    Wenn eine NetDCU startet, dann wird zuerst ein Bootlader aus dem Flash geladen (vergleichbar mit dem BIOS eines PCs). Dieser Lader hat die Aufgabe, die Hardware des Boards zu initialisieren und dann das Windows zu laden. Dieser Bootlader, der bei der NetDCU EBoot heißt, bietet auch eine kleine Kommandoschnittstelle, über die man gewisse einfache und sehr grundlegende Einstellungen vornehmen kann. Die möglichen Befehle lassen sich über ? abrufen. Einige der Möglichkeiten hier sind:


    - Debug-Meldungen aktivieren
    - Display aktivieren
    - Startverhalten des Boards festlegen
    - Einen neuen Windows-Kernel aufspielen


    Später im laufenden Betrieb bekommt man von diesem Bootlader eigentlich nichts mehr mit. Er lädt automatisch den Windows-Kernel und reicht dann die Kontrolle an diesen weiter.



    Windows CE


    Unsere NetDCUs sind immer schon mit einem fertigen Windows-System ausgestattet. Das heißt Bootlader und Kernel sind schon auf das Board aufgespielt und das Board kann direkt mit Strom versorgt werden und Windows läuft los. Dies ist nicht selbstverständlich. Bei anderen Firmen bekommt man eine CD mit einem BSP zum Board dazu, muss sich dazu den nicht ganz billigen Platform-Builder von Microsoft erwerben und dann kann man damit beginnen, sich erst mal einen eigenen Kernel zusammenstellen. Bis man dann da ist, wo man mit einer NetDCU gleich zu Beginn startet, vergehen oft schon Wochen.


    Insofern wollen wir es dem Nutzer schon so einfach wie möglich machen. Aber wir können nicht erahnen, welche sonstige Hardware der Kunde noch einsetzen wird. Also zum Beispiel welches Display er anschließt. Insofern läuft Windows in einer Grundkonfiguration, bei dem ein Standard-Display vorkonfiguriert ist. Hat der Kunde nicht zufällig genau dieses Display, muss er eben sein eigenes Display konfigurieren, sonst sieht er nichts von der Grafik-Oberfläche, dem Windows-Desktop.


    Der Kontakt zum Board kann über diverse Schnittstellen erfolgen. Von seriell über Ethernet, USB, oder auch durch Einstecken einer SD-Karte mit Software bei entsprechend ausgestatteten Boards. Auch hier ist zuerst mal die serielle Schnittstelle vorkonfiguriert und alles andere muss man erst selbst einstellen. Damit von den verfügbaren seriellen Schnittstellen so viele wie möglich dem Kunden zur eigenen Verfügung bleiben, beschränken wir uns mit den Debug-Meldungen und den Einstellmöglichkeiten auf einen einzigen Port. Allerdings kann dieser nur entweder die Debug-Meldungen anzeigen, oder das Konfigurationstool, das bei uns NDCUCFG heißt. Dies kann über ein Kommando im Bootlader Eboot umgeschaltet werden.



    Flash anstatt Harddisk


    Statt einer Harddisk besitzt die NetDCU Flashspeicher, der aber vergleichbar einer Harddisk nutzbar ist. Ein Teil davon wird für den Bootloader und für den Kernel selbst abgezweigt, aber der Rest steht zur freien Verfügung. Diese Unterteilung geschieht über eine Partitionierung, wie sie auch von PCs bei Harddisks bekannt ist. Je nachdem wie groß der Kernel ist, muss eben mehr oder weniger Speicher für ihn eingeteilt werden. Da man keinen Platz unnötig verschwenden will, macht man die Kernel-Partition natürlich üblicherweise nur minimal größer als benötigt. Darum kann es sein, dass bei Verwendung eines anderen Kernels eine Änderung dieser Partitionierung notwendig wird. Dies war z.B. bei Ihnen der Fall.


    Die Dateien, die zum Kernel gehören, tauchen dann auch entsprechend im Verzeichnis \Windows auf. Sie können nicht verändert werden, da sie fest im Kernel integriert sind. Der freie Speicher ist dann unter dem Verzeichnis \FFSDISK verfügbar. Dort kann gelesen und geschrieben werden. Falls benötigt, kann dieser Bereich noch in weitere Partitionen unterteilt werden.



    Registry


    In diesem FFSDISK liegt dann auch die globale Windows-Registry. Dort werden alle Einstellungen gespeichert, die dauerhaft gemerkt werden sollen. Speziell werden dort auch die konkret vom User gewünschten Treibereinstellungen vorgenommen. Das heißt man kann z.B. die IP-Adresse des Netzwerks einstellen, man kann die Geschwindigkeit von seriellen Schnittstellen oder auch von SPI oder I2C voreinstellen, man kann die I/O-Leitungen konfigurieren und man kann sagen, welche Schnittstellen überhaupt verwendet werden und welche nicht.


    Ãœblicherweise werden solche Einstellungen über das Control-Panel vorgenommen, vergleichbar der Systemsteuerung unter einem Desktop-Windows. Das sind einige Programme, die mit schönem grafischem Userinterface die Parameter anzeigen und zur Änderung bereit stellen. Es ist aber genauso gut möglich, direkt mit einem Registry-Editor diese Werte zu bearbeiten. Und auch das NDCUCFG ist ein Programm, mit dem man die Einträge der Registry setzen oder verändern kann. Entweder durch direkte Registry-Befehle, oder indirekt durch Nutzung eines Kommandos wie z.B. display. Letztendlich haben praktisch alle dauerhaft gemerkten Einstellungen irgendwelchen Einfluss auf die Registry.


    Wir geben bei all unseren Treibern an, welche Einstellmöglichkeiten es gibt und was dazu in der Registry eingetragen werden muss. Das müssen Sie dann in der Entwicklungsphase selbst vornehmen. In der Serie haben Sie dann die Wahl. Entweder Sie bekommen von uns ein Standard-Board und dann müssen Sie selbst dafür sorgen, dass die Konfiguration, Ihre Applikationssoftware und ggf. neuere Versionen von Kernel und Bootloader auf das Board kommen. Oder gegen einen geringen Aufpreis geben Sie uns diese Daten und dann können wir für Sie das Board schon fix und fertig vorbereiten.



    Verschiedene Windows-Kernel


    Da Sie als Kunde es ja so einfach wie möglich haben sollen, müssen Sie sich nur um die von Ihnen verwendeten Treiber kümmern, nicht aber um den Kernel selbst. Damit Sie dennoch einen möglichst optimalen Kernel einsetzen können, stellen wir im Verlauf der Zeit verschiedene Kernel für ein Board auf unserer Webseite zum Download zur Verfügung. Diese unterscheiden sich in den Fähigkeiten. Zum Beispiel mit verschiedenen Versionen der .NET-Umgebung (das sog. Compact Framework). Oder mit MediaPlayer. Oder mit InternetExplorer. Selbstverständlich auch hin und wieder fehlerbereinigte Versionen. Um so einen Kernel verwenden zu können, müssen Sie im Prinzip nur wissen, wie man einen solchen Kernel aufspielt. Ãœber die Kernel-Interna brauchen Sie sich keine Gedanken machen.



    Displays an der NetDCU


    Noch ein letztes Wort zu den Displays. Ein LCD-Display, das man an die NetDCU anschließen kann, ist wirklich das pure Display. Man muss also genau wissen, welche Auflösung es hat, welche Timings und welche Signalpegel. Das ist anders, als bei einem LCD-Monitor, den man an einen PC anschließt. Dort ist noch eine Elektronik vorgeschaltet, die beliebige Auflösungen auf die konkrete Display-Auflösung umskalieren kann. Sowas geht bei den Displays an der NetDCU nicht. Die muss man wirklich mit der nativen Auflösung ansteuern. Insofern bringt es nichts, wahllos irgendwelche Einstellungen auszuprobieren, sondern man muss konkret das File nehmen, das für dieses Display gedacht ist.


    Die NetDCU9 ist nun ein Spezialfall, weil sie es ermöglicht, zwei Displays anzuschließen, oder besser gesagt ein Display und einen analogen VGA-Monitor. Dazu muss dieser aber genau das gleiche Bild anzeigen, wie das Display. Also auch die gleiche Auflösung. Darum wäre es am sinnvollsten, zuerst das LCD zu konfigurieren, und dann in einem zweiten Schritt den Monitor dazuzunehmen.



    Somit kommen wir zurück zu Ihrem konkreten Fall. Hier würde ich nun ein systematisches Vorgehen vorschlagen:


    Schritt 1: Nochmal alles zurücksetzen und nochmal neu den Kernel aufspielen


    Schritt 2: Das Display konfigurieren


    Schritt 3: Das Windows so weit konfigurieren, dass über USB (Active Sync, Remote-Tools, Visual Studio) Kontakt aufgenommen werden kann.


    Schritt 4: Den zweiten Monitor konfigurieren


    Schritt 5: Ggf. das Netzwerk konfigurieren


    Wenn diese Schritte erfolgreich gemacht sind, können Sie problemlos mit dem Board arbeiten.


    Mit freundlichen Grüßen,


    H. Keller

    Quote from "RainerKa"

    sorry, hatte das Kommando makiert und kopiert, dann geht es nicht. Man muß das Kommando von Hand eingeben. :?


    Wenn Sie das DCUTermi-Programm als Terminalprogramm verwenden, geht tatsächlich kein Copy/Paste. Das Paste setzt den Text einfach nur sichtbar ins Fenster, aber die Zeichen werden nicht über die serielle Leitung und damit zur NetDCU geschickt.


    Quote

    dann gibt es ein Kommando "help <command>"


    help "display mode get" eingegeben
    anstatt das Kommando zu erklären, wird die Liste nochmal ausgegeben.


    Vermutlich müssten Sie einfach nur "help display" angeben, denn der Rest sind ja die Parameter zum "display"-Kommando.


    Sicher könnte man das eine oder andere am NDCUCFG noch schöner machen. Das ist aber gar nicht unbedingt die Zielsetzung. Denn letztendlich kann man nahezu alle diese Einstellungen später auch über die Windows-Registry sowieso in viel komfortablerer Form vornehmen. Wenn denn das Windows CE mal ordentlich läuft. Das Programm NDCUCFG ist hauptsächlich dazu da, das Henne-Ei-Problem zu lösen, also Konfigurieren zu können, wenn die eigentlich dafür gedachten komfortableren Konfigurationsmöglichkeiten (noch) nicht zur Verfügung stehen.


    Quote

    Weiterhin dachte ich, wenn auf der netDCU ein Betriebssystem läuft, müsste ich mich doch auch innerhalb des Systems bewegen können, z.B. mir vorhandene Dateien ansehen/löschen können.


    Selbstverständlich geht auch das. Das NDCUCFG ist ein Konfigurationstool von uns, F&S, nicht der Kommandozeileninterpreter von Windows CE. Wenn man dann den Kommandozeileninterpreter startet (z.B. über telnet), dann kann man wie in DOS entsprechende Befehl zum Anzeigen der Verzeichnisse, Bearbeiten der Dateien, Starten von Programmen, usw. eingeben. Zudem können Sie, wenn Sie ein Display angeschlossen haben, mit einer angeschlossenen USB-Maus die Windowsoberfläche bedienen, so ähnlich wie Sie das auch von einem Windows-Desktop gewohnt sind. Also den Arbeitsplatz öffnen und die Verzeichnisse inspizieren, Programme ausführen und mit der Taskbar arbeiten.


    Das Problem ist eher, mal bis zu diesem Punkt zu kommen, wo das alles möglich ist. Dazu muss eben das Display und das Netzwerk konfiguriert sein. Und genau dazu gibt es das NDCUCFG. Nicht übermäßig komfortabel, aber es erfüllt seinen Zweck ganz ordentlich.


    Die Doku entwickelt sich halt häufig parallel mit den Boards mit. Und wenn dann ein neues Board herauskommt, dauert es immer ein klein wenig, bis wieder alles konsistent ist, bis also wieder überall in den verschiedenen Texten der Name des neuen Boards und die damit verbundenen Änderungen eingeflossen sind.


    Mit freundlichen Grüßen,


    H. Keller

    Da das EVC++ kostenlos auf der CD beiliegt, kann man ja völlig gefahrlos damit beginnen. Sollte das später nicht ausreichen, z.B. weil .NET-Sprachen gefragt sind, kann man auch dann noch auf das kostenpflichtige VS wechseln. Die Projekte in C/C++ sollten sich relativ einfach übernehmen lassen.


    Aus Sicht von Microsoft geht der Trend komplett hin zu .NET und VS. Bei den neueren Boards mit WinCE6.0 geht es mit EVC++ schon gar nicht mehr, da ist VS Pflicht. Ist also ein Upgrade auf andere Boards in der Zukunft angedacht, wäre VS vermutlich die bessere Wahl.


    Mit freundlichen Grüßen,


    H. Keller

    Die Spannung für das Backlight muss auch über die NetDCU geführt sein, damit das funktioniert. Das heißt sie muss beim Stecker J1 auf Pin 1 eingespeist werden und dann das Backlight am Pin VCFL auf Stecker J3 angeschlossen sein (wie dies über den Adapter geschleust wird, weiß ich gerade nicht auswendig). Dann müssten auch die obigen Befehle funktionieren.


    Mit freundlichen Grüßen,


    H. Keller

    Vielen Dank für ihre weiteren Tests. Dann liegt es offensichtlich nicht an dem, was ich vermutet hatte.


    Ich gehe auch davon aus, dass Sie die aktuellste Version 1.5 des NI2C-Treibers einsetzen.


    Ich fasse mal zusammen. Aus Sicht der chFlags läuft alles komplett fehlerfrei ab. Dennoch kommen hin und wieder Daten, die falsch sind, wobei es häufig ein Versatz um ein Byte ist. Auf dem I2C-Bus sieht hingegen alles völlig korrekt aus, die übertragenen Daten sind da noch korrekt. Die Fehler hängen nicht von der Datenrate 200 kHz ab, auch bei niedrigeren Datenraten tritt er auf.


    Ich muss sagen, ich bin baff. Was mich hier besonders stutzig macht ist die Tatsache, dass die NetDCU beim vorletzten Byte laut ihren Angaben kein ACK sendet. Wie das passieren kann, ist mir schleierhaft. Das kann laut Quelltext des Treibers gar nicht sein. Da kann ein fehlendes ACK nur beim letzten Byte der Message passieren.


    Vielleicht sollten Sie doch mal die Oszilloskopbilder senden.


    Sie könnten auch mal probieren, in der Registry zum I2C-Treiber [HKLM\Drivers\Builtin\I2C1] einen DWORD-Value "Debug" mit dem Wert 8 zu setzen. Dann werden bei ein paar Sonderfällen Meldungen auf der Debug-Schnittstelle ausgegeben. Vielleicht liefert uns das einen Hinweis.


    Mit freundlichen Grüßen,


    H. Keller