Posts by fs-support_HK

  • \FFSDISK formated after power failure ?

    Quote from "JHelas"

    What can i do, that the \FFSDISK will not be formated ?


    Create a second FFSDISK partition and store your open file and all your runtime data there. Then the "old" FFSDISK just contains read-only data and will never be corrupted. On the "second" FFSDISK, run a file system check on every new start (e.g. via ndcucfg) to get back a consistent file system after any possible corruption. Continuing to write to an inconsistent filesystem can cause severe data loss.


    Accepting the file with length 0 is not the solution. The file system can still be in an inconsistent state then, and any ongoing writes can fail or overwrite other data even during regular operation. Only running a file system check can bring such a FAT file system back to a consistent state.


    Regards,


    H. Keller

  • Handling Hardware Interrupt

    Quote from "Rad"

    I don't know what this tool is and how this tool works.


    This tool logs all context switches and synchronisation actions of the System. When you start the tool, it starts recording of all these data. After some time, you should stop the recording and then you can look at the data. Now you can see when any switch from one thread to another happened, and things like that.


    By the way, when I entered "Remote Kernel Tracker" into Google, the first two hits here and here were very detailed and helpful. And the tool itself also has a Help menu.


    If you have lots of lost events, then the transfer from the board to the PC is slower than the events arrive. In this case the tool may not help much.


    But back to your main problem: How about reducing the speed of your test for interrupts? For example if you reduce the output speed of your serial line, then less interrupts happen. If you catch all interrupts now, then it looks like you were already beyond the limit of what is possible.


    Best regards,


    H. Keller

  • wzctool

    Quote from "velimir"

    or the list of ndcucfg commands?


    How about typing "help" in ndcucfg?


    For all the other tools you'll find lots of information on the Microsoft webpage or with Google.


    Regards,


    H. Keller

  • Handling Hardware Interrupt

    Just another suggestion: you can use the "Remote Kernel Tracker" to see what happens. It shows you all the thread switches and probably you can see there, why there are some interrupts "lost". However starting this tool does create quite a lot of traffic, so maybe this will influence your test and you'll not get accurate measurements. But it is worth a try.


    By the way this is a good way of measuring your timings very accurately, as the times for all events in the log are given with a very high resolution.


    Regards,


    H. Keller

  • Question to commands

    Quote from "schliz"

    I tried a completly new board it is a NetDCU8 Rev. 1.10 2005


    If your other board was board rev. 1.00, then the COM port has changed. Just try to connect to COM1: instead of COM2: and you will see again the boot messages and you can get into the boot loader. On the port where these messages were shown on board rev. 1.00, there is now ndcucfg running by default.


    Just to make it sure:


    COM1: on J5, near the SD-Card slot
    COM2: on J2, next to the power supply


    New versions of kernel and boot loader can be downloaded at http://www.fs-net.de/download/bin/.


    Please note that there are two versions of the stepping stone nboot: the normal one for board rev. 1.10, and the "old" one with ".rev100" in the name for board rev. 1.00.


    If you have a current board, you usually don't need to update the boot loader, neither nboot nor eboot.


    Best regards,


    H. Keller

  • What kind of NetDCU is better?

    Quote from "ivanok"

    Please explain, why NetDCU8 cannot provide intensive communication via Ethernet?


    The problem is not the Ethernet itself. The microcontroller used on this board uses the same internal bus for all data traffic. Especially the (pixel) data going to the display requires a continuous stream to go from the memory to the display driver and that takes quite some amount of the bus capacity. The larger the display, the more data is flowing. All this traffic is DMA based, however some features, Ethernet being one of them, can block the bus for rather long times, inhibiting any other data transfer in the meantime. This may result in the FIFO of the display driver to run out of data.


    Therefore in very rare cases under heavy program load and heavy Ethernet traffic it *may* be that you see a few black pixels flashing on the display for one frame. That's all.


    I would suggest that you buy a starter kit of the NetDCU8 and try it yourself. You won't be disappointed.


    Some more general classifications:


    - NetDCU5.2 for displays > 800x600 or audio requirements
    - NetDCU6 for 800x600, is a little more powerful than NetDCU8, with CAN
    - NetDCU8 has a really good power/price ratio, available with or without CAN & Ethernet
    - PicoMOD1 for small board size, even better power/price ratio than NetDCU8
    - Oncoming NetDCU9 will have video capabilities, otherwise it is in the range of the NetDCU5.2


    NetDCU5.2 and NetDCU6 are currently working under WinCE4.2, NetDCU8 and PicoMOD1 under WinCE5.0. All boards are also available with Linux instead of WinCE.


    For other hardware features you can have a look on our Web Site. There you'll find very detailed hardware descriptions in the Support/Download section.


    Best regards,


    H. Keller

  • AIN in C#

    Quote from "Mike"

    Leider ist es mir noch immer nicht möglich den AIN (ohne dll import )zu realisieren!!!
    Hier liegt das Problem beim zweiten Byte!!!!
    Es ist irrgendwie nicht möglich das zweite Byte einzulesen!!!
    1.Byte müsste stimmen!!(Low-Byte)


    OK, ich habe mal einen Blick in den Treiber geworfen und das Problem entdeckt. Der C-Treiber arbeitet etwas inkonsistent zur Definition von ReadFile(). Beim AIN-Treiber wird der Count-Value in "Samples" anstatt in Bytes angegeben. Jedes Sample ist aber 2 Bytes. Das heißt wenn man zwei Bytes lesen will (für ein short), dann liefert der Treiber zurück, dass 1 Sample gelesen wurde. Der C#-Treiber interpretiert dies aber in der eigentlichen Art und Weise, dass nur 1 Byte gelesen wurde -- und fällt prompt auf die Schnauze.


    Wir sind gerade am diskutieren, wie man das im Treiber ändern kann, so dass bestehende Applikationen, die die (eigentlich falsche) Interpretation von count benutzen, trotzdem weiter funktionieren.


    Quote

    Würd mich ja mit der dll-import Methode zufrieden geben, aber diese Variante dauert komischerweise extrem lange!!!
    max.3 Messungen pro sec!!!
    Mit FileStream hingegen gehts extrem schnell!!!


    Hab alle 80ms(mittels Timer) einen Pin Hi/low schalten lassen.
    mit dll Import: Puls war ca. 500ms lang!!!
    mit FileStream: Puls war exakt 80ms lang!!!!


    Das finde ich extrem interessant, wobei ich keine so rechte Erklärung dafür habe. Höchstens, dass bei der dll-import-Methode eben die Daten vom Marshaller automatisch von der C#-Struktur im Speicher auf das C-Format umkopiert und dort fixiert werden müssen, dann kommt der Aufruf des C-Treibers und danach müssen die Ergebnisdaten wieder vom C-Format in das C#-Format zurückkopiert werden. Vielleicht ist das so zeitaufwändig. Die C#-internen Varianten (BinaryReader, etc) sind da möglicherweise effizienter.


    Das ist aber nur ein Schuss ins Blaue, keine Ahnung, ob das wirklich der Grund ist. Das müsste man erst noch genauer untersuchen.


    Mit freundlichen Grüßen,


    H. Keller

  • Touch per Software deaktivieren

    Quote from "joachimdenk"

    gibt es eine Möglichkeit bei der NetDCU8 den Touch per Software zu deaktivieren?


    Man kann den Treiber in der Registry austragen und neu starten. Dann ist das Touchpanel deaktiviert. Oder meinen Sie was anderes?


    Mit freundlichen Grüßen,


    H. Keller

  • Run your application at startup

    Quote from "schliz"

    If I reboot the board the application starts, but then I get a popup with an exclamation mark saying: 51 was not found.


    If the application really started (shows its screen), then most probably the message does come from within your application, not from the init-manager.


    Does your program work when called from the command line (and not from init)? Probably you are using a feature that the explorer provided, e.g. searching for a window that does not exist anymore without the explorer running.


    Regards,


    H. Keller

  • What kind of NetDCU is better?

    Quote from "ivanok"

    I'm going to use a NetDCU. Advise me, please, what type is better\has less bugs\ets


    This request is the same as: "I'm going to buy a car, which one is the best?"


    You see, without knowing anything about your application, we can not give any meaningful recommendations.


    Regards,


    H. Keller

  • I would like to use control panel applets!

    Quote from "schliz"

    I would like to call the Control Panel for configuring the WLAN Settings like WEP key and so on, out of my program.


    I found a list of Control Panel including there index which you need to open it.


    I assume the numbers for the controls depend on the version of the control panel. Therefore your list may not be accurate for the Control Panel of the NetDCU. For example I found this article showing that a special control must be called with completely different parameters on different WinCE versions and devices.


    Therefore I would say that your method is not portable. You can try which panels work, but you can not assume that these numbers will stay the same with any new kernel release by F&S.


    Regards,


    H. Keller

  • AIN in C#

    Bleibt dennoch die Frage, warum es mit den Bordmitteln von C# nicht funktioniert hat. Ich hätte erwartet, dass diese FileStream- und BinaryReader-Funktionen letztendlich auch auf das CreateFile(), ReadFile() und CloseHandle() zurückgreifen.


    Kann es sein, dass hier vielleicht eine Pufferung stattfindet, der FileStream gleich mal 512 Bytes am Stück einliest und dann der BinaryReader alte Werte aus dem Puffer liest?


    Das würde aber immer noch nicht den Überlauf erklären. OK, der Binary Reader liest Low-Byte-First ein, während die Daten High-Byte-First sind. Aber dennoch müsste so ein Wert am Ende in ein uint passen. Kann es sein dass da bei der Umwandlung von UInt16 nach uint (=UInt32) ein Fehler auftritt? Sie verwenden ja nicht die Funktion Convert.ToUInt32().


    Vielleicht testen Sie Ihren ursprünglichen Ansatz ja nochmal, indem Sie val als UInt16 deklarieren oder die obige Konvertierung dazwischenschieben.


    Mit freundlichen Grüßen,


    H. Keller

  • Write Digital IO

    Quote from "schliz"

    For Pin 2 that's IO-Port 7 you have to enter the value 128


    Please don't mix up port and bit. There are exactly 3 Ports: 0, 1 and 2. There is a mapping between pin numbers and ports: Pins 2 to 9 are on Port 0, Pins 10, 11, 13 and 15 are on Port 1 and pins 17 to 24 are on Port 2. Which bit of the byte is responsible for which pin is explained in the docu. So for example if you want to change Pin 11, you have to write to Bit 2 of Port 1, if you want to read Pin 23, you have to read from Bit 1 of Port 2.


    You change the port to which you are talking by calling SetFilePointer(). Entry "Port" in the registry only tells which port is used by default before you do any calls to SetFilePointer().


    This is how you *use* the ports. Now there is the topic of *configuring* the ports. This is done by three values: UseAsIO, DataDir and DataInit. All these values tell the state of all three ports in one single DWORD each. Therefore there is a mapping between ports and these DWORDs: Port 0 goes into the low byte (bit 0-7), Port 1 into the next-to-low byte (bit 8-15) and Port 2 into the next-to-high byte (bits 16-23).


    Quote

    Is there just one handle DIO1 for all the ports?


    Usually yes. If you want to access port 0, then port 1, then you first address port 0 with SetFilePointer(), then you read/write the port, and then you address port 1 with SetFilePointer() and read/write the port.


    Regards,


    H. Keller

  • How to increase the Receive Buffer in serial communication?

    Quote from "YoMas"

    The problem for me is that I have to shuffle something like 60k from an ARM7 Chip to the NETDCU. The WCE "overhead" for serial communication is slowing this extremly down when each transfere action must not exceed 2k. At the moment I have to separate my data to around 30 pieces and send them one after the other always waiting for an acknowlage that the 2k buffer is read before sending the next package. So this operation takes during the start of the program around 8 seconds.


    May there is a way to accelerate this?


    Why split the data in blocks? Just use some handshaking protocol like XON/XOFF. Then the NetDCU can take the data as fast as possible, and the sender can also send data as fast as possible. Everything else is done by the handshaking. This is faster than having to wait for the completion of each block.


    Please note that transferring 60K at 115200 bit/s takes already 5.3s pure transfer time. Assuming that only one main thread is running and takes all the data, the NetDCU should be fast enough to read the data before the 2K buffer fills up.


    Regards,


    H. Keller

  • NetDCU8 - Audio ?

    Quote from "NOEL_V"

    The reason why I ask this is that NOT ALL pins on the DIL-interface connector(s) have a description, so i might be possible the have this connected somewhere, but not described in the documentation.


    In fact all pins are described. But they may be described in different tables. For example the table in section 2.3 shows some pins of connector J2, section 2.4 shows some more pins of connector J2, and the table in section 2.5 shows the remaining pins of J2.


    This is meant with all the footnotes to "---": These pins are not unused, they carry other signals and are described somewhere else in the document.


    Regards,


    H. Keller

  • Input Panel

    Just an idea, not tested:

    • Write a small program that calls SipShowIM() to display the input panel
    • Create a batch file that calls this program first and then calls cmd.exe
    • Instead of calling cmd.exe directly, call this batch file instead


    This should work with any other application than cmd.exe, too.


    Regards,


    H. Keller

  • Access DIO from Visual Studio 2005 (VB Project)

    Quote from "Nase"

    I received a CD from F&S and a PicoMod1. The correct file name on the CD is: "NetDCU_DeviceDriver.pdf". But it is under the folder "NetDCU". and under the folder "German", there is no german description.


    Sorry, my mistake. I hadn't realized that it was for the PicoMOD1. Then the correct file is PicoMOD1_DeviceDriver_eng.pdf
    As the PicoMOD1 has more I/O pins than the standard NetDCUs, there is in fact a difference when using them. Mr. Zutter already explained that.


    Quote

    I program in VB.NET and all examples are in C++.


    Yes, this is a big problem. The .NET languages are getting more and more popular, but the drivers provide their interface in C only. However as all drivers use the file interface (CreateFile(), ReadFile(), WriteFile(), SetFilePointer(), DeviceIoControl(), CloseHandle()), using a .NET language you have two ways of accessing them:


    • Use the .NET file functions. They'll go down to the basic C interface in the end anyway.
    • Write your own wrapper functions to call the C file functions from coredll directly.


    It is very difficult to provide all documents in all languages and for all programming environments. For example if we have one document for C/C++, one for C#, one for VB, and then each of them at least in German and English, this is quite a lot to do.


    Therefore our main goal is to provide the English documentation and the C interface as a minimum. English is understood by most software people and this is also the reason why we prefer English here in the forum. And when the C interface is known, you can usually transfer the call to .NET somehow rather easily.


    Best regards,


    H. Keller