Andre,
Firstly, I dont think quoting snippets of emails out of context is helpful in solving your problem, the purpose of the forum is to post your problem to try to get help in resolving it - not personal vendettas!
I have responded to your query many times, you just dont like or understand the answer - however I will repeat it now.
I will address your two main points.
1) ...when the application is running display works as expected.. during bootup of the mainboard the display text for firmware version, mac address etc is unreadable......
During the point where the mainboard ( irrespective of manufacturer) is booting up, it is running some type of bootloader code, normally Tiny Booter, then Tiny CLR is kicked off, then your application. During the time the bootloader code is running, the OS has not started - any text output to the display is from the bootloader.
The settings for the hardware display controller need to be loaded. Micro Framework is an 'embedded' OS and expects the hardware for the port to stay constant, the ability to change the LCD settings, from an application is an addition not natively supported in Micro Framework - In the early days GHI produced a Micro Framework port with additional non standard features, one of these was the ability to change the LCD configuration settings from an application level. Our early approach was to change LCD settings using an extension to MFDeploy, allowing you to edit the LCD configuration settings. Gadgeteer, took the feature of being able to change the LCD settings from an application level and incorperated the feature into Gadgeteer. We added the ability to edit the LCD config, at an application level into the port of the Nano board, to support this.
However, your problem is during boot up, and is totally dependant on how the manufacturer implemented their MF port. It looks like the settings being used during boot up are the wrong settings for the display. However once the Tiny CLR and application are running, the settings used are the new ones for the display.
THERE IS NOTHING THE APPLICATION CODE CAN DO TO CHANGE THE BOOTLOADER CODE, IT IS NOT RUNNING AT THIS POINT.
There is another possibility, that maybe the settings, set during the application are not being persisted to flash, you can tell this by how the application starts up, does it doe a reboot. But I doubt this is the problem.
No other user of the 4.3 display and GHI boards has complained about this problem - either it is unique to your board, or they dont see it as significant.
The Gadgeteer LCD Driver is a 'passive' component in this process. It just contains the configuration with the settings required. It is the Gadgeteer main board code, that looks at the display type, stored in an extended weak reference, and compares it with the display type in the flash config. and then decides whether to call the update method of the main board to change the settings. The only thing the LCD Driver is responsible for, in this situtation, is supplying the settings - which as you have pointed out, when your app runs the display is correct, therefore the config settings in the display driver are correct.
Your issue is why are they not used during boot up - is it a porting firmware implentation issue, or is there some fault with the settings being persisted... there is nothing the lcd driver can do in this respect.
Finally - thank you James for your comments - hopefully the same answer from an independent source will finally put this issue to rest.
2) Gadgeteer Compatible..
The LCD is Mechanically compliant with the Gadgteer Module builders guide, in connector layout, color, dimensions silk screen ine thickness and so on.
As for the firmware, it inherits from the gadgeteer base display class, implements required methods and the dll is in the format required by Gadgeteer - as is the install msi. You have not stated one point that makes it not gadgeteer compatable - unless I have missed something?
SImon Taylor
Sytech Designs Ltd