Posts by fs-support_HF

It will be of great help to other Linux users, when you can post the steps needed to get AT91 RTC running in our Linux forum
http://www.fs-net.de/phpBB3/viewforum.php?f=23

Thanks

You can get the default settings by setting registry value Debug to value 4.
After saving registry and reboot you get the values over serial debug line COM1:.

Wie Sie schon richtig anmerken, können auf der PicoMOD nur Programme zur Ausführung kommen, welche für ARMV4I kompiliert sind. D.h. alle Programme (Viren) für X86 (PCs) funktionieren nicht. Infolge dessen können sich diese auch nicht ausbreiten.
Um sicher zu gehen, können Sie natürlich nicht genutzte Interfaces wie z.B. Ethernet abschalten. Dazu müssen Sie einfach das Laden des Treibers mit dem Registry-Wert Flasg = 4 verhindern.

F&S Support Team

Most of the pin's should be configured as input during power up.
When WinCE starts loading drivers, it configures the pins so dedicated function will work.
So if you want to use a pin you should check shich driver normally uses this pins.
After that you can disable this driver from loading with registry value Flags set to 4.

F&S Support Team

Currently there is no possibility to change between MIC and LINE by software.
We will change the driver so you can do this in the same way as with NetDCU10.
Please wait for the next image V1.16.

F&S Support Team

Bei der Verwendung von 2 Byte Zeichensätzen gibt es einiges zu beachten.
Wie Sie schon richtig gesehen haben, kann in der Struktur CONFIG der Mode ausgewählt werden.

Im einfachsetn Fall wird dieser fest auf den gewünschten Wert gesetzt.
Wobei folgenden Werte zulässig sind:

Für den Parameter ComDataMode kann auch eine Variable verwendet werden. Dadurch kann der Modus auch im laufenden Betrieb durch Verändern der Variable umgeschaltet werden. Der Modus wird dabei unmittelbar nach Erkennung des Datenwertes umgeschaltet, also i.a. nach dem Komma hinter dem Parameter.

Beispiel:
Wenn die Variable Nummer 300 die ComDataMode-Variable ist, und das Format soll auf UTF16BE umgeschaltet werden, so geht das mit dem Befehl

V300,1,<LF>

Dabei wird der Datenmodus schon nach dem Komma hinter der 2 umgeschaltet, d.h.
das <LF> muss schon im neuen Modus gesendet werden!

Und hier vermute ich auch das Problem. Es ist also wichtig, dass Sie das abschließende <LF> bereits als 2 Byte senden. Erfolgt dies nicht, funktioniert auch die Umschaltung nicht.
Am Besten, Sie machen die ersten Versuche ohne Umschaltung. D.h. Sie stellen in CONFIG: fix auf UTF16BE und prüfen ob z.B. die Copyrightabfrage funktioniert. Dies ist dann unabhängig vom geladenen Zeichensatz.

F&S Support Team

Hello,

Display driver of NetDCU9 supports two different modes to control two monitors:

A.) Same content on LCD and CRT
In this case both displays should have the same resolution.
In your configuration your LCD is WVGA (800x480) and your CRT is SVGA (800x600).
Different display resolutions are not supported at the moment (we have to extend the driver).

B.) Different content on LCD and CRT
In this case you have the possibility to drive two monitors with different physical resolution.
So your configuration WVGA and SVGA works without problems.
The only problem comes in from the touch screen.
We have checked this and seen that this is a problem.
You will find a new image for NetDCU9 for download where the touch is fixed to the primary display.
Take a look to the following commands for configuration:

Hope this helps.
F&S Support Team.

Hello!
We have now tested the display TX18D16VM1 with NetDCU9.
We are very sorry, but there is an error in the display driver for NetDCU9:

We have already updated the online version of the driver.

F&S Support Team

Hello,
The demo version of the DCU compiler doesn't generate a DEF file. So all what you can do with this, is testing the sysntax of your Scrit files.

Regards
F&S Support Team.

The DCUL7 is capable of showing 256 colors at the same time, selectable from a larger range of 4096 colors. The set of 256 shown colors is called a color table, or palette. The palette can be set in the CONFIG: element, where you also define the display resolution and some other parameters. Here in entry "ColorTable:", you can give a file name with the color palette to use (extension .PAL).

In the default configuration, the palette is set as given in the file COLORL5L7.pal. This is the same file as COLOR256.pal, but the name shows better the fact, that this is the same color table on the DCUL7 as on our DCUL5, which had a fixed, non-modifiable set of colors. These 256 colors are built from using 8 levels of red and green and 4 levels of blue. By looking at the color number, the color intensities can directly be seen:

7 6 5 4 3 2 1 0 Bit of color number
B B G G G R R R Color

For example Color 192 (=0xC0) is full blue, Color 56 (=0x38) is full green and Color 7 (=0x07) is full red. To make life with the color numbers a little bit easier, we have provided some files defining names for the most common colors. Therefore if you add a line

#include "COLOR256.DSF"

somewhere at the beginning of your script file, then you can use the name "RED" instead of 7, "GREEN" instead of 56, "BLUE" instead of 192, and so on. So these DSF-files don't define the color palette, they are only for convenience.

However the full color capability of the DCUL7 is 16 intensity levels of each Red, Green, and Blue, building a set of 4096 colors. You can chose any subset of 256 colors you like. Suppose you want to show your company logo and the logo needs many shades of blue. Then you can create your own palette that contains more blue combinations and less other colors than in the default palette.

You have to follow these steps:

1. Create a PAL-File with your new palette. This is done by copying an existing .PAL file and then editing the entries of the new file with the BMP converter program BMPCNV.EXE/BMPCNV2.EXE.

2. Use this new file in the ColorTable: entry in CONFIG:

3. (Optional) Define the colors you need most with some #define statements near the beginning of your script. For example build your own COLORxxx.DSF file and include it.

We recommend using defined names instead of color numbers to make future changes easier. For example if you need two different background colors, one standard and one for warning purposes, you could add these two entries:

#define BGnormal 0xFF // white
#define BGalert 0xA7 // bright red

Now when you use BGnormal and BGalert in really all cases where background is involved, you can exchange the color of your whole application by simply modifying these two lines.

Some last hints for Terminalmode:

In Terminalmode, you can't use names. You have to give the color number to the commands <ESC>7 and <ESC>8. However you can modify color table entries at runtime with the command <ESC>9<n>,<r>,<g>,<b>,. For example

<ESC>97,0,255,0,

will set color number 7 to green. I.e. in the default color table, color 7 will not show red anymore, but green instead. This will have immediate impact on all currently visible pixels of color 7. For example if you had a rectangle in color 7 on your display, it will immediatley change its color from red to green after this command. This might be interesting for some color effects as the color unfortunately can not be given as a variable.

Regards
F&S Support Team

Using the touchpanel in compiler mode requires knowing how the DCU works with a matrix keyboard. So I'll explain shortly how this works and then we'll see how a touchpanel can replace a matrix keyboard.

The DCU is capable of reacting to user input from a keyboard itself, without the need of the main application (on your hardware) to do anything. For example when pressing a key, the DCU can automatically switch to a different window. Or it can move the selection in a menu. Or you can even enter values into an edit field.

You simply create a KEYBOARD element that lists all the meanings of the different keys on your keyboard. For example you can say that the key with scancode 0x12 should act as '4' when doing input into an edit field. Or when the key with scancode 0x25 is pressed, then an ANIMATION is shown. And so on. There is an example on our web site that shows this a little clearer:

<!-- m --><a class="postlink" href="http://www.fs-net.de/Home_Eng/Support_E/Samples/Counter/counter.html">http://www.fs-net.de/Home_Eng/Support_E ... unter.html</a><!-- m -->

Now sometimes the behaviour of keys should change depending on the context you are in. For example think about function keys or softkeys, that have a different meaning in every window. So a single KEYBOARD table is not enough. There are two more features that allow a more dynamic definition of the keys. First, you can define more than one KEYBOARD element and call one of them in a WINDOW. This replaces the current KEYBOARD table and from now on the new table is active. Or you can directly define some keys there, then these keys will be active together with the current keys of the KEYBOARD element but only until another window is called.

The idea is that you define all global keys, that means keys that keep their meaning in different windows, in a KEYBOARD element and all dynamic keys directly in the window itself. So for example if all keys are always the same but you want a special help key that shows help depending on the window you are in at the moment, then you can define this key in every window anew, and all other keys are in a KEYBOARD element.

Or another example: you want the user to enter a number, for example a parameter that you need for your main application. You have to do the following steps:

1. Define a variable that will hold the value 2. Define a text that shows the variable 3. Define a window that shows the text; probably also set EDITMODE in the window appropriately 4. Define a KEYBOARD element that defines the keys KEYNUM0 to KEYNUM9 and KEYENTER, probably also the KEYEDIT key to start editing and KEYLEFT and KEYRIGHT for cursor movement. For example to get the key with scancode 0x12 to be mapped to KEYNUM4, add the following line to the KEYBOARD element:

KEY: 0x12 KEYNUM4

Now when this window is shown and you press the KEYEDIT key, then you can edit the value of the variable by entering the digits 0 to 9 and moving the cursor with the left and right keys. When you're done, you type KEYENTER and the new value is stored in the variable. If you defined the variable with AutoSend: confirm, then you'll automatically get a message sent to your application showing the new value.

Now the touchpanel. The idea is that you define virtual keys on the display and these keys then behave exactly like keys on a matrix keyboard. By using the FIELDTAB element, you can give rectangular regions on the screen and define which (virtual) key scancode this region should create when pressed and/or released.

So when using a touchpanel, you do as if you have a matrix keyboard, but you also have to define the FIELDTAB where your matrix keys are on the display. So let's extend the example of entering the value by using a touchpanel on a virtual keypad. In addition to the 4 steps above (which are still needed), you have to do two more steps:

5. Draw buttons 0 to 9 on the display, also an EDIT and an ENTER key and probably also a left and right arrow. How you draw the button does not matter. You can simply draw a text with a rectangle, or create bitmaps for them, as you like.
6. Define a FIELDTAB that gives every of these buttons a virtual scancode. You should of course use the scancodes of step 4 above. For example if the button '4' is drawn at coordinates 30,70 and is 40 pixels wide and 30 pixels high, and it should create scancode 0x12 when pressed, you add the following line to the FIELDTAB element:

X: 30 Y: 70 WIDTH: 40 HEIGHT: 30 ATTRIB: down KEY: 0x12

That's all.

So how does it work then? Let's do an example: you press the touchpanel on button '4'. The DCU recognizes that you've touched the touchpanel. It converts the analog touchpanel values to display coordinates (this mapping is initialized with the touchpanel calibration) and then checks the current FIELDTAB. It finds that there is a field entry defined for these coordinates and event "down" and takes the corresponding scancode 0x12 from the table entry. Now the DCU does the usual key checking. This means it looks into the current KEYBOARD definitions and finds that this scancode 0x12 is mapped to KEYNUM4. KEYNUM4 means that if the DCU is currently editing a value, it should insert the digit 4 into the value.

So to summarize, when you press somewhere inside of button '4' on the touchpanel, the DCU enters digit 4 into the currently edited value.

Now that's not too difficult, is it?

What remains to be said are two hints that are usually required to fine tune the touchpanel usage. Please make sure you have understood everything up to here before reading on.

First you usually want a visible feedback that you successfully pressed the button on the screen. This is the reason why we allow to define an action for "up" and "down" in a FIELDTAB entry. The idea is to react on "down" and draw the button somehow different like a pressed button. The final action is then executed when the button is released.

So for example when the user is a little off the button to the side, probably the neighbouring button is recognized. Then the user can move the finger while still on the touchpanel towards the correct button and when the correct button is highlighted, he can release the touchpanel and the correct key is executed.

The second hint has exactly to do with this motion while pressing the touchpanel. You should not rely on the fact that you get both, the down *and* the up event on the same field. If the user moves from one button to the next button without releasing the finger from the touchpanel, then you get first the down event for the first button, and then directly the down event for the second button, without getting an up event for the first button between these. You may get an up event for the second button if the user releases the touchpanel there.

But even more. If the user moves his finger outside of any button, you will never see any up event for any key. This makes it very difficult to draw a previously pressed button as unpressed again. And here is where the hint comes: as last entry in the FIELDTAB, define an entry that spans the whole display with event "down". When this event happens, redraw all buttons us "unpressed". Why? When the user moves his finger outside of any normal button, he automatically presses this special full screen button. So this is a good method of recognizing this.

Regards
F&S Support Team

Well, I don't know exactly if you already know how the touchpanel works on the DCULx. The idea is that you can use the existing elements now with the touchpanel without any further work. For example you can simply use the touchpanel to select entries of a menu. Nothing has to be done, simply touch the menu entries.

But as we don't have a special button element, it still requires a few things to built such buttons that are sensitive to touchpanel input. But by using the new FIELDTAB element you can define rectangular regions on the display, that are recognized when you touch them or release them on the touchpanel. Usually you will draw some kind of button with rectangles, texts and/or graphics in each of these regions so that the user will see these regions as buttons.

Example:

So you have to give the upper left corner of the rectangular region and the width and height. By giving the attribute you can tell if the region will be recognized if the touchpanel is pressed or if it is released within this region. If a region is recognized as activated, then it works as if you had pressed a key on a matrix keyboard, so it generates a scan code. (1 to 4 in the example). By using the common features for matrix keys, this input data can be used to switch to other windows, enter data in an edit field, and so on. So by using this FIELDTAB element, you can do everything you can do with a matrix keyboard. The example above divides a 320x240 display into four quadrants. E.g. if you press on the upper right quarter, then key code 2 is generated (on press down), if you press on the lower right quarter of the display, the key code 4 is generated (when the panel is released again).

The first FIELDTAB in the source code is automatically the global FIELDTAB. But you can also "call" a FIELDTAB as an element in a GROUP or WINDOW. Then starting from there the new FIELDTAB is active.

There are a few other commands that are important when using the touchpanel. For example at the beginning the touchpanel must be calibrated once. This draws four marks on the display that have to be touched one after the other. This is required to get a correct mapping between analog input data from the panel and the screen coordinates. Calibrating is started by the commands:

Compilermode: QX<LF>
Terminalmode: <ESC>QX

The difference is that in Terminalmode the values determined during calibration are returned via the serial line. So you can store these values and set them again on the next start without having to do calibration again. The Compilermode variant does not return the values. In the future the DCUL7 will store the calibration data itself in flash memory in this case, but this feature is not yet implemented. So for the moment I recommend the Terminalmode version and storing the data in your application.

Another command may be interesting for you to react on arbitrary touchpanel action. If you switch on the touchpanel reporting by <ESC>QT<n>, every movement on the touchpanel bigger than <n> is reported via serial line. But be aware that this may generate quite a lot of data and the serial line may be a bottleneck then. Only use this if the built-in features (FIELDTAB) don't fit your needs at all.

So here is a summary of commands for touchpanel control.

Touchpanel commands for Compilermode
------------------------------------

"QX<LF>"
Start touchpanel calibration and store values in flash memory.

Touchpanel commands for Terminalmode
------------------------------------

"<ESC>QX"
Start touchpanel calibration. When this is done, the determined parame-
ters are automatically activated and reported as
QN<aV>,<bV>,<aW>,<bW>,<aR>,<bR>,
aV, bV: analog values V' of display vector V = (xmax, 0) - R
aW, bW: analog values W' of display vector W = (0, ymax) - R
aR, bR: analog values R' of reference point R(0, 0)

"<ESC>QP<aV>,<bV>,<aW>,<bW>,<aR>,<bR>,"
Set the analog parameters of vectors V', W' and reference point R'.

"<ESC>QT<thres>,"
Set the threshold value. Only changes bigger than this will be reported
to the user. By setting this threshold to zero, the reporting of values
is completely switched off (default: 0). However when fields or menus are
active in Compilermode, the touchpanel inputs converted to keys may still
be reported, depending on the keyboard settings.

"<ESC>QM<flag>"
Set raw reporting mode:
0 : Touchpanel values are reported converted to display coordinates
-1: Touchpanel values are reported raw (0..1023)

Regards
F&S Support Team

1.) What cable do I need for connection between PC and DCULx:
There are 3 lines involved: Rx, Tx and Ground; nothing else is needed. Shouldn't be too difficult to figure out the correct connection. The pin layout of the serial line connector of the DCU can be found in part 4 (hardware) of the DCU documentation. (In case you don't have it, the documentation can be downloaded from <!-- m --><a class="postlink" href="http://www.fs-net.de">http://www.fs-net.de</a><!-- m --> (Support->Download).)

2.) What parameters must bes et to get connection working (Serial Port Set-up / Configuration, baud rate, etc.)
About the connection between PC and DCU-L3: a very simple way to test this is by the use of the provided terminal program. The parameters to set are: 19200bps, 8 data bits, 1 stop bit, no parity, no flow control. So open the connection (menu Action->Connect) and then power on the DCU. You should receive the two characters "&!" which indicate a correct selftest and power on sequence on the DCU, or probably a message about a missing definition file at address 80000, which is absolutely ok when the flash memory is empty. If you can't see anything, the connection DCU->PC is not yet correct.

Now you can check the other direction of the connection by typing the character '@' on your PC keyboard. If everything works, the DCU-L3 should immediatly answer with a version string. If this fails, then your connection PC->DCU does not work.

If both tests do work, the connection cable is set up correctly and download and everything else should also work.

Regards
F&S Support Team

Hello,
To download the DEF file to DCULx, you have to use DCUTerm.exe.
You can download this program from:
<!-- m --><a class="postlink" href="http://www.fs-net.de/download/bin/">http://www.fs-net.de/download/bin/</a><!-- m -->
Section: Tools->dcuterm.zip
Beside this, DCUTermi.exe is already included in the software package you received with DAISY32. If you don't have the software, you can download it from the same place.

For the connection between PC and DCUL7 you need a serial cable RS232. Only RxD, TxD and Ground is needed.
After you have installed DCUTermi.exe you can test communication by Typing character @. You should receive a readable copyright message.

Regards
F&S Support Team

The problem with the matrix keyboard driver is solved.
Please download new image NKP3_CF35_090406 from the download area.
We have also corrected the documentation "Device Driver".
Regards

New boot loader 1.35 and WindowsCE image 1.10 is available for download.
Main feature of new EBOOT is that MAC address will not be overwritten when uploading a PSD file.
New WindowsCE kernel new implements hardware watchdog.

To get more information about changes of each released version please take a look in the history-file within the corresponding directory.

Your F&S Team

Der von Ihnen gemessene Jitter setzt sich aus vier Komponenten zusammen:
A: Verzögerung zwischen Anlegen des IRQ und Aufruf des Interrupt-Handlers
Entsteht dadurch, dass BUS belegt ist oder Interrupts gesperrt sind
B: Verzögerung innerhalb des Scedulers, d.h. Triggerung des Interrupt-Threads
Ihr Programm läuft zwar auf Prio 0 gibt jedoch die CPU durch WaitForSingleObject ab.
D.h. unter Umständen findet ein Process-Switrch statt oder ein anderer Thread führt eine Aktion
aus die nicht unterbrochen werden kann.
C: Verzögerung beim Toggeln des Pin's durch Aufruf des DIO Treibers
Bei Aufruf des DIO Treibers muss device.exe geladen werden
D: Verzögerung durch CPU bis Pin getoggelt wird (-> Pipeline)

Nach unseren Messung kommt ein Großteil der Verzögerung durch das Toggeln des DIO Ports. D.h. die Zeit vom Anlegen des IRQ bis Ihr Thread gestartet wird ist sicherlich kleiner 5 us. Der Jitter lässt sich nur reduzieren in dem weniger Threads laufen. Dies kann erreicht werden durch Abschalten aller nicht benötigter Treiber. Insbesondere USB, Audio u.s.w.. Ansonsten würde ich für eine zeitkritische Anwendung immer einen externen Controller verwenden.

Grüße
Holger Frölich

Hello,
I'm sorry, but SIP is not included in current version of image.
We will add SIP to the next release.
Regards
Holger

Hello,
Currently there is no VPN server available for WinCE.
An option for you could be the usage of SSH for WinCE.
http://www.codeplex.com/Wiki/View.aspx?ProjectName=CESSH
Regards
Holger

Hello dbu,
You are right.
In the rare case you want to use PicoMOD3 as a replacement for PicoMOD1 usage of serial lines is not compatible.
For this case we will create special pboot3 loaders to switch serial debug line to other port.
Please take a look into download section.
Regards
Holger