I have been sitting on my new shiny FEZ Lynx since Thursday and tonight I decided to give it a spin. I created a small VC++ project and linked in the GHI Libraries and since I like visual solutions I decided that my first attempt would be to use the Display N18 module.
I was pleasantly surprised that it worked the first time. I did not even bother to read any documentation just looked at the source code from GHI and it was reasonably intuitive from the code what needed to be done.
I did find that there are a few potential memory management issues with the libraries, I will try take a in depth look over the weekend. Anyway, I thought I would share the code, not because there is anything noteworthy, but rather because it shows how simple it is to work with the libraries GHI have provided.
Amazing how simple the example code looks. Some questions thoughā¦ the file that you shared on code source has a *.cs extension. Shouldnāt it be a *.cpp extension?
The other thing I would have like to see with you example is a screenshot or description of your solution explorer. Iām still not sure what other decencies I need to include to get it to compile.
I included all the files I thought was necessary and it is āalmostā building successfully. But during the link process I get :
error C1083: Cannot open include file: āavr/pgmspace.hā: No such file or directory
It is amazing how simple it looks! Iām still trying to understand exactly what the hardware does. Would it be accurate to say that the module drivers, together with the Lynx board, emulate an SPI, I2C, and/or GPIO interface by sending ācommandsā to the Lynx board through the USB serial interface?
If this is correct, then I assume that the performance of the āmain boardā (host plus Lynx) is dependent on the speed of the host, the speed of the USB interface, and the speed of the FT4232H chip?
If so, what sort of performance can we expect from the board?
@ KiwiSaner - You are correct, it is a cpp file. I did not actually upload a file, it is just a code snippet so the code share download feature is just assuming it is C#.
As for getting the code compiled, GHI has created the library to support both the FEZ Medusa and FEZ Lynx, any differences in the code are handled by conditional compilation. You will notice that the code that is failing is in a #ifndef LYNX block, this indicates that you need to have a define for LYNX so that the code in the #else compiles. You can add the define at the project level by going to
Project>Properties, then Configuration Properties>C/C++>Preprocessor and add LYNX to the Preprocessor Definitions.
Once it compiles then you are going to get some linker errors, you need to add two lib to the project. Again in the Project>Properties dialog, Configuration Properties>Linker>Input you can add FTD2XX.lib and libMPSSE.lib to the Additional Dependencies. You will also need to add the path to search for the lib files. You do that under Configuration Properties>Linker>General and add the path to the libs in the Additional Library Directories field.
NOTE: The configuration settings should be set to āAll configurationsā in the drop down located at the top left of the Property Pages dialog.
@ jasdev - Well, that is a good question. The speed is definitely dependent on the USB FTDI interface speed and the capabilities of MPSSE which is FTDI support for interfacing with SPI, I2C devices. Drawing to the Display N18 is quite slow, but I have not tried pumping blocks of data through so it might be better when doing bit blitting vs the current code which is drawing and filling a circle pixel by pixel.
I will definitely be playing with this more to get a better understanding my self.
@ jasdev - Your assumption is correct. As far as performance concerned, I havenāt measured it, but it also depends on how emulation is implemented. You can do bit banging, or use MPSSE.
Things are moving very fast on this. Since you almost always have pull in all the low-level framework, one solution we use to make this less tedious is to run the following batch files in Gadgeteer and FEZLynxS4 (respectively). Then just add the two *_all.cpp files to your project:
echo off
setlocal ENABLEEXTENSIONS
del /q g_all.cpp g_all.tmp
for %%i in (*.cpp) do (
echo #include "%%i" >>g_all.tmp
)
move g_all.tmp g_all.cpp
echo off
setlocal ENABLEEXTENSIONS
del /q s_all.cpp s_all.tmp
for %%i in (*.cpp) do (
echo #include "%%i" >>s_all.tmp
)
move s_all.tmp s_all.cpp
In last post, forgot to mention this as well (probably you already figured this out)ā¦
for framework foundation just #include FEZLynxS4, it pulls in the world.
@ Architect - Itās for both. All system/platform specific code is pretty much isolated in the board directory. Weāre trying hard to keep it that way.
@ Jeff - it might be worth creating a VS template, if this is not something GHI wants to do as I can understand your desire to be cross platform, I will give it a shot over the weekend. The easier it is for others to get started the better the adoption would be.
@ taylorza - Itās on the table. It will help make the product āFEZā (Freaking EaZy). We all want a VS template !! If you get around to it before we do, that would be wonderful!
@ taylorza - as to ācross plaformā yes!! But that doesnāt mean we donāt want to properly support the dominant development environment on the systems: VS on windows, proper GNU makefile templates, and support for Eclipse and/or command line Java tools for Android.
Yes you are absolutely correct at this. The reason for the current code is compatibility for Medusa and the issues of lower amounts of resources available to the framework. You can test this by reverting STEP_X and STEP_Y definitions under #ifdef LYNX in the DisplayN18.h file to what would be running on Medusa. Fill rect with original steps you can watch the data draw to the screen in segments, but cant see anything with the data being drawn at once.
It would be best, to hold a local bitmap for Lynx and do the drawing on the object and flush it to the screen to make it fast. This is also on my plate, but most likely will not hit the first beta release since you are nearly guaranteed that you are looking at a screen in which you can display information on until we, or someone in the community can take the time to implement the changes.
You will most likely beat us to the puch. We are currently working on a new structure and distribution of usable segments that will link to a singular library for the beta 1 release. This will cut down on compile times as well as it will remove the need for you to compile the files from source and make it easier for template creation.
This is what I meant with ābit blittingā, this is a 2d graphics term used to refer to a bit level block transfer. I am glad to hear that that will be faster, I will definitely give that a try over the weekend.
Thanks TaylorZa and Jeff for your advise. Iām tried your suggestions but unfortunately Iām still having some linker problems. But no worriesā¦ I decided that maybe I should rather just wait a while until GHI officially release Lynx and Medusa. I do not even have any Medusa or Lynx boards yet. Just trying this out of interest for now.
ā¦