Posts by andyinfsnet

    Hello,


    1. so you mean the calibration algorythm will not handle calibration together with this serial debug output, due to timing problems ?
    2. You don´t think that one of the four wires was bad connected before shorten the flat ribbon(I mean the numbers make no sense to me, compared to the "good cal." numbers)?


    I will try to increase the MaxCalError when I will have problems next time.

    Just a question, I had small trouble while calibrating a TX14D14 touch. The calibration gives me following values, but it never stopped:


    TCHPDD: DOWN: TSP_GetXY(1019, 513)
    TCHPDD: Move: TSP_GetXY(1020, 511)
    TCHPDD: Move: TSP_GetXY(1021, 510)
    TCHPDD: Move: TSP_GetXY(1020, 514)
    TCHPDD: Move: TSP_GetXY(1020, 514)
    TCHPDD: Move: TSP_GetXY(1019, 515)
    TCHPDD: Move: TSP_GetXY(1020, 510)
    TCHPDD: Move: TSP_GetXY(1021, 514)
    TCHPDD: Move: TSP_GetXY(1021, 516)
    TCHPDD: Move: TSP_GetXY(1021, 508)
    TCHPDD: Move: TSP_GetXY(1020, 516)
    TCHPDD: UP: TSP_GetXY(1020, 516)
    TCHPDD: DOWN: TSP_GetXY(1021, 856)
    TCHPDD: Move: TSP_GetXY(1020, 857)
    TCHPDD: UP: TSP_GetXY(1020, 857)
    TCHPDD: DOWN: TSP_GetXY(1019, 855)
    TCHPDD: Move: TSP_GetXY(1021, 857)
    TCHPDD: Move: TSP_GetXY(1021, 856)
    TCHPDD: Move: TSP_GetXY(1021, 856)
    TCHPDD: Move: TSP_GetXY(1021, 852)
    TCHPDD: Move: TSP_GetXY(1020, 850)
    TCHPDD: Move: TSP_GetXY(1019, 854)
    TCHPDD: Move: TSP_GetXY(1019, 857)
    TCHPDD: Move: TSP_GetXY(1020, 853)
    TCHPDD: Move: TSP_GetXY(1020, 858)
    TCHPDD: Move: TSP_GetXY(624, 78)
    TCHPDD: UP: TSP_GetXY(624, 78)
    TCHPDD: DOWN: TSP_GetXY(1020, 850)
    TCHPDD: Move: TSP_GetXY(1021, 858)
    TCHPDD: Move: TSP_GetXY(1020, 856)
    TCHPDD: Move: TSP_GetXY(1021, 858)
    TCHPDD: Move: TSP_GetXY(1020, 858)
    TCHPDD: Move: TSP_GetXY(1020, 862)
    TCHPDD: Move: TSP_GetXY(1021, 857)
    TCHPDD: Move: TSP_GetXY(1022, 855)
    TCHPDD: Move: TSP_GetXY(1021, 850)
    TCHPDD: Move: TSP_GetXY(1018, 858)
    TCHPDD: Move: TSP_GetXY(1019, 854)
    TCHPDD: Move: TSP_GetXY(1021, 851)
    TCHPDD: Move: TSP_GetXY(1018, 855)
    TCHPDD: UP: TSP_GetXY(1018, 855)
    TCHPDD: DOWN: TSP_GetXY(1021, 165)
    TCHPDD: Move: TSP_GetXY(1021, 164)
    TCHPDD: Move: TSP_GetXY(1020, 165)
    TCHPDD: Move: TSP_GetXY(1017, 162)
    TCHPDD: Move: TSP_GetXY(1020, 164)
    TCHPDD: Move: TSP_GetXY(1020, 160)
    TCHPDD: Move: TSP_GetXY(1020, 164)
    TCHPDD: Move: TSP_GetXY(1021, 160)
    TCHPDD: Move: TSP_GetXY(1020, 163)
    TCHPDD: Move: TSP_GetXY(1021, 169)
    TCHPDD: Move: TSP_GetXY(1020, 163)
    TCHPDD: Move: TSP_GetXY(1021, 160)
    TCHPDD: UP: TSP_GetXY(1021, 160)
    TCHPDD: DOWN: TSP_GetXY(1022, 171)
    TCHPDD: Move: TSP_GetXY(1020, 164)
    TCHPDD: Move: TSP_GetXY(1019, 172)
    TCHPDD: Move: TSP_GetXY(1019, 171)
    TCHPDD: Move: TSP_GetXY(1020, 168)
    TCHPDD: Move: TSP_GetXY(1021, 170)
    TCHPDD: Move: TSP_GetXY(1017, 165)
    TCHPDD: Move: TSP_GetXY(1020, 167)
    TCHPDD: UP: TSP_GetXY(1020, 167)
    TCHPDD: DOWN: TSP_GetXY(1019, 169)
    TCHPDD: Move: TSP_GetXY(1021, 162)
    TCHPDD: Move: TSP_GetXY(1021, 164)
    TCHPDD: Move: TSP_GetXY(1017, 168)
    TCHPDD: Move: TSP_GetXY(1021, 165)
    TCHPDD: Move: TSP_GetXY(1019, 169)
    TCHPDD: Move: TSP_GetXY(1022, 165)
    TCHPDD: Move: TSP_GetXY(1021, 168)
    TCHPDD: Move: TSP_GetXY(1021, 167)
    TCHPDD: Move: TSP_GetXY(1021, 165)
    TCHPDD: Move: TSP_GetXY(1021, 165)
    TCHPDD: UP: TSP_GetXY(1021, 165)


    After shortening the 4 wires to minimum(lets say it are now 5cm instead 10cm) the calibration worked, giving me following values:


    TCHPDD: DOWN: TSP_GetXY(504, 507)
    TCHPDD: Move: TSP_GetXY(506, 508)
    TCHPDD: Move: TSP_GetXY(505, 506)
    TCHPDD: Move: TSP_GetXY(504, 506)
    TCHPDD: Move: TSP_GetXY(506, 508)
    TCHPDD: Move: TSP_GetXY(504, 512)
    TCHPDD: Move: TSP_GetXY(504, 514)
    TCHPDD: Move: TSP_GetXY(504, 513)
    TCHPDD: Move: TSP_GetXY(506, 514)
    TCHPDD: Move: TSP_GetXY(506, 508)
    TCHPDD: Move: TSP_GetXY(503, 509)
    TCHPDD: UP: TSP_GetXY(503, 509)
    TCHPDD: DOWN: TSP_GetXY(164, 850)
    TCHPDD: Move: TSP_GetXY(163, 854)
    TCHPDD: Move: TSP_GetXY(163, 859)
    TCHPDD: Move: TSP_GetXY(163, 856)
    TCHPDD: Move: TSP_GetXY(163, 858)
    TCHPDD: Move: TSP_GetXY(165, 854)
    TCHPDD: Move: TSP_GetXY(165, 858)
    TCHPDD: UP: TSP_GetXY(165, 858)
    TCHPDD: DOWN: TSP_GetXY(168, 853)
    TCHPDD: Move: TSP_GetXY(167, 853)
    TCHPDD: Move: TSP_GetXY(166, 855)
    TCHPDD: Move: TSP_GetXY(166, 856)
    TCHPDD: Move: TSP_GetXY(167, 857)
    TCHPDD: Move: TSP_GetXY(166, 856)
    TCHPDD: Move: TSP_GetXY(165, 856)
    TCHPDD: Move: TSP_GetXY(166, 855)
    TCHPDD: Move: TSP_GetXY(167, 850)
    TCHPDD: Move: TSP_GetXY(167, 856)
    TCHPDD: Move: TSP_GetXY(165, 855)
    TCHPDD: Move: TSP_GetXY(165, 852)
    TCHPDD: Move: TSP_GetXY(165, 848)
    TCHPDD: Move: TSP_GetXY(167, 851)
    TCHPDD: Move: TSP_GetXY(168, 852)
    TCHPDD: Move: TSP_GetXY(166, 850)
    TCHPDD: UP: TSP_GetXY(166, 850)
    TCHPDD: DOWN: TSP_GetXY(833, 852)
    TCHPDD: Move: TSP_GetXY(835, 857)
    TCHPDD: Move: TSP_GetXY(835, 857)
    TCHPDD: Move: TSP_GetXY(834, 860)
    TCHPDD: Move: TSP_GetXY(834, 858)
    TCHPDD: Move: TSP_GetXY(834, 864)
    TCHPDD: Move: TSP_GetXY(836, 862)
    TCHPDD: Move: TSP_GetXY(835, 860)
    TCHPDD: Move: TSP_GetXY(836, 860)
    TCHPDD: Move: TSP_GetXY(838, 859)
    TCHPDD: Move: TSP_GetXY(839, 859)
    TCHPDD: Move: TSP_GetXY(840, 858)
    TCHPDD: Move: TSP_GetXY(842, 854)
    TCHPDD: Move: TSP_GetXY(843, 857)
    TCHPDD: Move: TSP_GetXY(840, 854)
    TCHPDD: UP: TSP_GetXY(840, 854)
    TCHPDD: DOWN: TSP_GetXY(845, 177)
    TCHPDD: Move: TSP_GetXY(843, 169)
    TCHPDD: Move: TSP_GetXY(842, 170)
    TCHPDD: Move: TSP_GetXY(842, 170)
    TCHPDD: Move: TSP_GetXY(843, 168)
    TCHPDD: Move: TSP_GetXY(846, 168)
    TCHPDD: Move: TSP_GetXY(848, 163)
    TCHPDD: UP: TSP_GetXY(848, 163)
    TCHPDD: DOWN: TSP_GetXY(847, 171)
    TCHPDD: Move: TSP_GetXY(844, 167)
    TCHPDD: Move: TSP_GetXY(843, 164)
    TCHPDD: Move: TSP_GetXY(844, 163)
    TCHPDD: Move: TSP_GetXY(845, 164)
    TCHPDD: Move: TSP_GetXY(847, 163)
    TCHPDD: Move: TSP_GetXY(848, 164)
    TCHPDD: Move: TSP_GetXY(849, 164)
    TCHPDD: UP: TSP_GetXY(849, 164)
    TCHPDD: DOWN: TSP_GetXY(854, 161)
    TCHPDD: Move: TSP_GetXY(855, 164)
    TCHPDD: Move: TSP_GetXY(854, 162)
    TCHPDD: Move: TSP_GetXY(853, 163)
    TCHPDD: Move: TSP_GetXY(852, 160)
    TCHPDD: Move: TSP_GetXY(852, 161)
    TCHPDD: Move: TSP_GetXY(851, 162)
    TCHPDD: Move: TSP_GetXY(851, 163)
    TCHPDD: Move: TSP_GetXY(851, 163)
    TCHPDD: Move: TSP_GetXY(852, 160)
    TCHPDD: Move: TSP_GetXY(852, 161)
    TCHPDD: Move: TSP_GetXY(853, 161)
    TCHPDD: Move: TSP_GetXY(853, 165)
    TCHPDD: Move: TSP_GetXY(852, 166)
    TCHPDD: UP: TSP_GetXY(852, 166)
    TCHPDD: DOWN: TSP_GetXY(162, 168)
    TCHPDD: Move: TSP_GetXY(161, 168)
    TCHPDD: Move: TSP_GetXY(160, 164)
    TCHPDD: Move: TSP_GetXY(160, 165)
    TCHPDD: Move: TSP_GetXY(162, 163)
    TCHPDD: Move: TSP_GetXY(163, 166)
    TCHPDD: Move: TSP_GetXY(163, 163)
    TCHPDD: Move: TSP_GetXY(163, 168)
    TCHPDD: Move: TSP_GetXY(165, 167)
    TCHPDD: Move: TSP_GetXY(167, 164)
    TCHPDD: Move: TSP_GetXY(166, 170)
    TCHPDD: Move: TSP_GetXY(169, 170)
    TCHPDD: Move: TSP_GetXY(168, 176)
    TCHPDD: Move: TSP_GetXY(167, 169)
    TCHPDD: UP: TSP_GetXY(167, 169)
    TCHPDD: DOWN: TSP_GetXY(500, 518)
    TCHPDD: Move: TSP_GetXY(508, 516)
    TCHPDD: UP: TSP_GetXY(508, 516)
    so the reason can be to long cable or bad contacted pins on the flat ribbon 10 pin connector.
    What do you think when you read these numbers?

    I found now the reason for unexpected closing. With a remote tool (NetCFLogging.exe, from the powertoys set) I could log that it(probably Windows itself) is out of memory. Windows CE seems to be allowed to close application in this case without explicit warning.
    (Although I have already seen such OOM warnings on the screen in other cases, when I had bad software design and the volatile memory was insufficient). Ok I do not know the reason why this is not displayed in ths certain case but anyhow, the more strange thing is that my application runs without any problem and with some MB reserve in memory, as long as I do not press any button in the Windows task bar, let´s say the "Start" button. Then the appplication stops(or let´s say disappears) with a logged string "OutOfMemory".


    Has anyone an comment how this can be? I always thought that Windows is protected against any "bad" application, but never knew that I need to protect my app against windows. Do you have another idea?

    This info seems to have helped me(where can I get such map files?). I did some change in LocalFree(), what seems corresponding to your mentioned RHeapFree (is this true?) and the messages disappeared. Unfortunately the problem that the application stops is not gone.
    But what I have seen, when disabling one debug message in my code (Debug.WriteLine("yxz...")) the problem now arrives more often, and additionally, what was not before, there are new system messages, when deploying and starting the application:
    ETH: TX UNDERRUN
    ETH: Error Overrun
    ETH: TX UNDERRUN
    After program start(and do not hit a button) these messages do not arrive anymore.
    By the way I use now a Picocom2(herefore I have a user kernel) and nomore a Picocom4.


    Any help appreciated.

    I do not use random numbers.


    Can you not say anything about this? ->>


    Exception 'Data Abort' (4): Thread-Id=05e6009e(pth=83dfc6c0), Proc-Id=050f007e(pprc=831b673c) 'Application.exe', VM-active=050f007e(pprc=831b673c) 'Application.exe' PC=400302c0(coredll.dll+0x000202c0) RA=00040000(???+0x00040000) SP=0071fc2c, BVA=00b40018


    Is there no way to use this information to start a basic narrowing? If I use iterative narrowing, don´t know how long this would take.

    I have a problem and have no further ideas what to do. May be you can give some remarks. The application I am talking about is in written in C# and is using p/invokes a lot. It is talking with another application via UDP over the ethernet. It is running on a PICOCOM4 WCE6.0R3 with Kernel NKPC4_PRO_CF35_111123


    Application runs as it should, as long as I want without problems, but when I am using the windows taskbar, let´s say to switch from application to a control panel, or whatever, then it happens from time to time, let´s say every 50th button pressing, that the application stops without any exeption or any warning, like if I would really close the program. I checked sources already if it would be a unwanted program stop, but there is nothing like that(actually the program never needs to stop)


    Beside this behaviour there is, from time to time and with no relation to any interaction, some output on the debug interface:


    +OALIoCtlHalGetHWEntropy
    +OALIoCtlHalGetHWEntropy


    Exception 'Data Abort' (4): Thread-Id=05e6009e(pth=83dfc6c0), Proc-Id=050f007e(pprc=831b673c) 'Application.exe', VM-active=050f007e(pprc=831b673c) 'Application.exe' PC=400302c0(coredll.dll+0x000202c0) RA=00040000(???+0x00040000) SP=0071fc2c, BVA=00b40018


    No idea what that means but feeling says this is related to my attached problem. When I debug with Visual studio via Ethernet connection, and the application is stopping, there comes the messages that the connection to the device is broken, as if one unplugs the Ethernet connection. When I run the application (started from device), and the application is stopping, it just stops and the window disappears. I already activated all exceptions in Visual studio, but nothing happens. Is there anything I can do to find this ?

    Quote from "andyinfsnet"


    Yes I use a second ethernet adapter, this one is via USB. I will check if the error occurs only in the case when this interface / driver is used.
    I wonder why this dll has access to all other proces, may be bad driver implementation.


    Just the promised info: I tested overnight without this second ethernet adapter and no such exceptions happened. So I know the guilty part but have no solution.

    Another issue happend this overnight test. There has been a DM9CE: DriverReset
    Can you tell me what you know about this DM9CE DriverReset? In which condition does this happen?
    Can this have relation to the usbd.dll. exceptions? And furthermore, is there a way to debug this usbd.dll?
    May be I can find more information why this exception happens.


    Yes it should have been clear, sorry. Because I am not so perfectly sure in synchronising, could you please check if following sync is enough, when calling this method (CCAN::Write) from different threads (and having declared the cs_CanBusWriting globally):


    Is it possible to use the new driver 2.x on NETDCU8? Seems I have 1.02 only(readout from IOCTL_CAN_READ_PROPERTIES).
    Over the time the synchronisation made from you would be probably safer than from our Application.
    CAN is builtin driver so new kernel would be necessary, I guess. We already have a user kernel.

    Hello just a question, on a NETDCU8 is this
    <!-- m --><a class="postlink" href="http://www.fs-net.de/download/docu/netdcu/english/WINCE_CAN_INTF_eng.pdf">http://www.fs-net.de/download/docu/netd ... TF_eng.pdf</a><!-- m -->
    or this
    <!-- m --><a class="postlink" href="http://www.fs-net.de/download/docu/picocom/english/WINCE_CanInterface_eng.pdf">http://www.fs-net.de/download/docu/pico ... ce_eng.pdf</a><!-- m -->
    the relevant driver information ? I am a bit confused what to use because WINCE_CanInterface_eng.pdf is for PICOCOM usually, biut the name of the driver
    Candrv.dll is mentioned in my NETDCU8 registry under hklm/drivers/builtin/CAN1


    thanks

    Interesting, the driver for my CAN is CANDRV.dll , I guess.


    Do you think, as a workaround, I may increase the priority of the receiving Thread of the driver with Priority256=dword:80 or lower, as described in another thread here?
    And does it make sense to decrease serialoutput priority, cause I do only use it for debugging.


    bye

    Yes I use a second ethernet adapter, this one is via USB. I will check if the error occurs only in the case when this interface / driver is used.
    I wonder why this dll has access to all other proces, may be bad driver implementation.


    bye

    Hello


    At my NETDCU8 System I have from time to time the following on the serial debug interface:


    Code
    1. Data Abort: Thread=83e26000 Proc=80fee860 'device.exe'
    2. AKY=ffffffff PC=03844664(usbd.dll+0x00004664) RA=03842d78(usbd.dll+0x00002d78) BVA=06000f00 FSR=00000007
    3. Data Abort: Thread=83e26000 Proc=80fee860 'device.exe'
    4. AKY=ffffffff PC=03844664(usbd.dll+0x00004664) RA=03842ea0(usbd.dll+0x00002ea0) BVA=06000f00 FSR=00000007
    5. Data Abort: Thread=83e26000 Proc=80fee860 'device.exe'
    6. AKY=ffffffff PC=03844664(usbd.dll+0x00004664) RA=038437b0(usbd.dll+0x000037b0) BVA=06000f00 FSR=00000007
    7. CANBUS_EVENT_OVERRUN


    This means to me I miss a message from Can bus because Application could not take the message from the can driver fast enough.
    But I think the CANBUS_EVENT_OVERRUN is just a following error due to the data abort, but may be I am wrong.
    When I try analyse the Data Abort(look in remote processviewer ) I cannot find Thread=83e26000 and Proc=80fee860
    And what means AKY=ffffffff , usually here should be a Acces key number whit what I could look in remote processviewer.


    May be interesting, it does not seem to that anything is not working after this Data Abort, I can soft reset my machine, and everything works again.
    Could s.b. help my in the right way where I can start searching for the reason of this data abort? This Data Abort is an exception on driver level, correct?

    Hello


    I have a Netdcu8 and a Picocom2 device and they commiunicate to each other via tcp/ip over ethernet well.
    Now I want wireless communication between them. I tried successfully a WLAN based system with usb/wifi adapters on both devices.
    But making the settings for the device ip´s and the SSID´s seem to be a bit confusing and not really an end user friendly aproach, at least for our applications.


    So I think bluetooth could help me out of this. I never worked with it, but what I read from www there is a way of directly setting up pairs of
    communicatin partners(means easily connect 2 device when they are within 10m range).
    And also if I understood correctly, there is a way to work with sockets like if I would have my usual ethernet interface.


    So there are some questiions:
    1. Is this all true what I wrote above about bluetooth? Is it really easier to setup instead of WLAN/Wifi
    2. Can I use my existing tcp/ip communication.
    3. Is there a usb/bluetooth adapter on the market that works with netdcu8 and picocom2 ? What is the name ?
    4. Is it possible to receive a test kernel for netdcu8 and picocom2 with the usb/bluetooth drivers, or are there dll/drivers supported for the usb dongles?



    thanks for any help
    bye

    Ok, I found a way to let Windows do the stuff of connecting automatically(instead of programatically), via the checkboxes in the WZC dialog (this seems to be the name of the pop up window, WindowsZeroConfiguration). I only need to add programatically once the SSID on one wifi side to the preferred list and that´s it. A bit away from what I expected, but ok.
    Then there is the question remaining to me, how to do this setting via registry instead of checkboxes, I didn´t find the keys for it(yes I am a bit lazy), and how can I disable the WZC pop up.
    So where are the reg key for WZC? Any help welcome.


    Another thing, does anybody know where I can buy the platformbuilder 120 day trial CD.
    I read that there should be the source code for the WZC stuff.
    Downloading the trial isn´t possible for me, it is sticking in the middle of downloading files.

    Just some questions. I installed on each device, a netdcu8 and a picocom2, a WLAN USB Adapter with RaLink chipset. I configured the registry to detect the stick properly and also I configured the registry so that on both devices ad-hoc mode is possible. When booting both devices, a screen pop´s up, showing me the acces points that are detected.
    I can configure with this tool an adhoc connection easily and it works stable like any other network adapter.


    Now I wanted to do this programmaticaly, without this tool. I was´nt able to do this. I tried to use SDF2.3 with it´s wrappers classes. There are the approbiate methods and I did it like this:


    and so on. I never get an error and ConnectToPreferredNetwork() gives me back a "true", telling me that it worked. So what´s wrong? I never get a connection between my 2 devices.
    To make it a bit more clear to me, I have the questions:


    1. Do I make a basic error the way I try to connect programmatically? Is there a better way.
    2. The windows tool that pop´s up, is this the wzctool? Can I disable this in registry?
    3. What is the windows zero configuration? Is this just a service that I need and is already in the kernel?
    4. Is there a Windows api available, offering some more functions to do connection.


    thanks

    There is a phenomen occuring in Picocom2 when I want to connect from my Desktop computer to the device with telnet service via an IP let´s say 10.120.20.2 to the integrated PicoCom2 ethernet adpater. This is working only when I have NOT connected the WLAN adapter(giving me a second ethernet adpater interface).
    When the WLAN stick is plugged there is coming telnet error message that no connection is possible on port 23
    Ping also not working.
    When I now unplug the WLAN stick the telnet/ping is possible again.


    When I do such stuff with a Netdcu8, this works with or without WLAN stick.
    Any idea?