Posts by al12559

Quote

Have you already tried to use one of our sample programs to scan the I2C bus? F&S I2C Bus Scan Utility

Can I operate this utility "blind", that is, using a keyboard shortcut? As my display has a size of 320*240 pixels only, the application window is only partially displayed, and I cannot see other buttons than "Open" and "Close". Perhaps you could offer a utility version with a smaller window dimension?
I ran the utility on PicoCOM2, where my I2C device operates normally in my application.
After I select the only option "I2C1:" for port and press "Open", nothing happens or is displayed in the "Devices" list. "Close" does not produce any output as well.
When I run the utility on PicoCOM4, a device "Device 0x21" is found after selecting "Open". The control below the "Devices" list cannot be seen, it is hidden by the task bar. Though obviously recognised on the bus, my I2C device still cannot be operated due to TimeOut failures.

Quote

Please try to decrease this value in registry to get a lower resulting frequency (e.g. 80000).

I tested various frequencies, down to 10000 Hz. There was no successful write or read in any case, always "Timeout".

Could you please verify that this is not a driver issue?

Which are the differences between the I2C driver versions between PicoCOM2 and PicoCOM4?

Is it required to use the PicoCOM4 framework instead of the PicoCOM2 framework despite the fact that both modules are supposed to be essentially compatible?

i would appreciate an answer in due time.

Quote

Do you have the possiblity to trace the bus with an oscilloscope?

Unfortunately not.

Quote

Additionally please try to disable DIO driver for testing.

The timeout error occurs with and without enabling DIO.

Quote

The mentioned timeout message in most cases relates to a blocked bus.

I cannot see how the I2C bus can be blocked when all hardware except the PicoCOM module remains the same?

Something else raises a question:
When I query

I get in case of PicoCOM4

while in case of PicoCOM2

which appears to be more reasonably because the registry setting is in both cases

When I query

I get in case of PicoCOM4

while in case of PicoCOM2 I get

Perhaps there is a driver issue?

Hello,

I want to use a PicoCOM4 module on the same custom-made mainboard where PicoCOM2 runs successfully.
All the used function areas (USB Active Sync, SD memory card, Digital IO) run well, but I2C communication fails due to TimeOut.
The driver is running (as seen from HKLM\...\Drivers\Active).
"CreateFile(TEXT("I2C1:"), ..." returns a valid handle.
DeviceIoControl() returns reasonable information.
But reading and writing registers fails (other than with PicoCOM2 on the same mainboard). Carrying out

is responded by Serial debug output

Calling

immediately returns in "msg_read"

What do I have to change compared to PicoCOM2 to communicate via I2C?

Thank you in advance

André Lehmann

Quote

Does following message occur?

This is part of my serial debug output

There is no line like

Addition:
After switching to the kernel NKPC4_CORE_CF35_110722.bin the SD card is recognised and works properly.

Despite of this setting the SD card is still not detected.
If I insert a PicoCOM2 module on the same evaluation board, it is detected.

Quote

Could you please post the display settings you are setting?

Quote

You have posted in another thread that you also get some exceptions with PicoCOM2. If this still is the case please eleminate any hardware related reasons first (power supply).

The exceptions with PicoCOM2 appear different from the ones discussed here and occur on both the starter kit evaluation board and the custom-made mainboard.
The power supply has been checked.

Quote

Do you have another skit to verify if the baseboard is damaged?

Unfortunately not.

With the current kernel my SD card is still not detected.(PicoCOM4 on PicoCOM2 evaluation mainboard - should work if pin-compatible?)
This is the debug output while booting

How can I enable the SD card?

Using a PicoCOM4 module with the PicoCOM2 starter kit mainboard, I observe exceptions while booting after I changed the display type.
This is the debug output after installing the kernel (NKPC4_CORE_CF2_110722.bin)

This is the debug output after I changed the display type to the one that I use. (Some drivers have been deactivated; I sent the same configuration file to the module as I do with PicoCOM2)

After booting the display works normally.

Can you give any hint to avoid these exceptions?

Quote

We have detected that SDMemory driver is missing in CF2 and CF2_RTC kernel images. We will fix this in the next kernel release.

When will this kernel be released? The date is rather important for me.
I have to decide whether to purchase five PicoCOM4 or five PicoCOM2 modules for a series of sample instruments.
If the kernel with SDMemory driver will be released within, say, 2-3 weeks I may set up a series of sample instruments based on PicoCOM4. if it will take longer I have to resort to PicoCOM2 modules though these are so limited in speed and memory size and will not be on the final parts list.

Quote from "fs-support_MK"

Does the USB connection also not be established when connecting the cable after module has booted up competly?

(1) With PicoCOM4 on my custom-made mainboard neither using USB connection from boot time nor when connecting after boot-up has completed a connection will be established. The device does not appear among the USB devices recognised by the PC.
(2) With PicoCOM2 on the same custom-made mainboard auto-connection via USB always succeeds.
(3) With either PicoCOM2 or PicoCOM4 on a PicoCOM2 F&S starter kit mainboard auto-connection via USB always succeeds.
So the cause of malfunction seems to be located on my mainboard. But what could I check as PicoCOM2 operates normally? Are there different requirements for PicoCOM4?

Quote

Additionally I have seen in your debug output that there occures an exception during bootup. This exceptions occures in video driver (VDE).

Code

1. VDE: Version 1.0, ActiveKey = Drivers\Active\08
2. PC=c003bb54(k.coredll.dll+0x0001bb54) RA=801562c0(kernel.dll+0x000062c0) SP=d04ae1d0, BVA=ffffffff

Please verify if your power supply is stable. If you are using a laboratory power supply please increase maximum current.

The more detailed exception information is

This execption occurs when using PicoCOM4 with the starter kit mainboard as well as with my custom-made mainboard.

Quote

Please verify if your power supply is stable. If you are using a laboratory power supply please increase maximum current.

Using a laboratory power supply with the starter kit mainboard, I observe following consumption:
PicoCOM4 125mA @ 5V, 150mA @ 3,3V,
PicoCOM2 250mA @ 5V, 330mA @ 3,3V
Maximum current is never reached.
Using PicoCOM2 I always get the following message on boot-up

So far, I accepted it because the system runs normally. If you could explain a possible cause and solution to this problem, I will be very happy.

My picoCOM4 module does not auto-connect to a computer when connected via the usual cable.
"Does not connect" is to say that "WindowsMobileGerätecenter" (Windows7, 32bit) does not recognise a connection. Neither does "USB Device Viewer" (Microsoft).

On the same mainboard several PicoCOM2 modules connect automatically via USB.
The registry setting

is the same in both cases.

These are the PicoCOM4 boot messages:

How can I connect PicoCOM 4 via USB to another computer?

Just one inconvenience with TouchCalibrate():
On a 320*240 pixel screen some of the text lines are clipped (first screen, last screen)
The user can only guess what there is beyond the screen.
Is there a way to change this?

Just one inconvenience with TouchCalibrate():
On a 320*240 pixel screen some of the text lines are clipped (first screen, last screen)
The user can only guess what there is beyond the screen.
Is there a way to change this?

One question still remains: After the user decides to accept the new settings - is a call to

required to make the changes permanent?

Quote

You might find one soluation in the following thread:
Touch calibration screen

This works in my case, but one question remains: After the user decides to accept the new settings - is a call to

required to make the changes permanent?

Quote

Alternativly please try to get a window handle with FindWindow() to make sure you are sending the message to the correct window.

After TouchCalibrate() has started, in a separate thread (where I process the button events) I get the handle of the only window with class name="static" and post the WM_KEY.. messages to it, but it does not have the desired result of closing the window.

No difference with SendMessage().
I assume TouchCalibrate() is a child window of my application. In this case SendMessage(HWND_TOPMOST,,,) or PostMessage(HWND_TOPMOST,,,) would not work.
How can I obtain the window handle of the TouchCalibrate() window after it has been created as it has no window title?

Hello all,

from my application the user may call TouchCalibrate(). This window can be closed by hitting either the Escape or the Return key(after re-calibrating).
My device offers some buttons to the user, but a keyboard is usually not attached. In my application (from whereTouchCalibrate() has been started) I successfully recognise the event that the Esc or Return button has been operated. I want to send a message to the TouchCalibrate() window by

or

But both messages do not cause the TouchCalibrate() window to be closed. (I tried to send WM_KEYDOWN followed by WM_KEYUP as well). I can close the window only by hitting ESC or RETURN on a keyboard.
Can anybody advise me on how to do that by sending a message?

Thank you very much!

I know that built-in device drivers can be disabled by setting a DWORD registry value "Flags" to 4.
What are other valid values for the Flags parameter, and what are their respective meanings?
Could not find this information in the document "Device Driver Documentation" or somewhere else.
Is this a mechanism specific to PicoCOM device drivers or is it part of Windows CE in general?