I took on these Road Tests to help get me out of a terrible habit – soaking up a large quantity of information, applying it, and not documenting or sharing it back to the community. I’ve heard the Dead Sea is considered dead because it is insular and only has inlet streams with no outlets, so maybe writing helps me to be more alive. Anyway, these Road Tests gives me an interested audience and some interesting material to write about.
First of all I would like to thank everyone who expressed their interest in the CleO and NerO as a result of my unboxing post. This is a good product and the ease of programming the graphics is a big strong point. I am glad I was able to get that point across.
I would also like to thank Bridgetek, Element 14 and Randall Scasny for choosing me to Road Test this product. I was also selected to Road Test the 1-Wire
Grid-EYE Sensor so I would also like to thank Randall and Element 14 for passing my application on to Panasonic and Maxim Integrated and thank them for selecting me. What is cool about doing both of these tests concurrently is I can hopefully use the CleO screen to display the IR output from the Grid-EYE Sensor on screen while I test the device response through different panes of glass.
I switched to FOSS (Free Open Source Software) full time about 5 years ago. About the only thing I felt that I had lost in the switch was Visual Studio as a Rapid Applications Environment (RAD). Mono was a decent port, but I didn’t think it measured up to even Visual Basic 4. Fast forward to now and I have found a proper RAD in GAMBAS.
Gambas is a recursive acronym for “Gambas Almost Means BASIC”. It measures up to at least Visual Basic 5 and is under constant development. I started playing around with it about 6 months ago. So, I’ve been hacking away all week to see how well it solves a real world problem that I have – no linux application to design CleO screens.
The developers at CleO have done an awesome job with their API. It is nice and clean and fairly well documented. Understanding the CleO side has been the easy part. I have already written all of the code and inputs to collect parameters and write source code.
Unfortunately, GAMBAS is not quite as well documented yet. And adding to the confusion their were some major improvements bringing some key language changes between Gambas 2 and Gambas 3 -- much of the older documentation does not apply. But, since I am an experienced VB developer and GAMBAS is so similar it hasn’t been a major problem. I had some questions and got a response from the Gambas Users mailing lists from Hans Lehmann who has written a fully encompassing tutorial for Gambas 3. The down side is that it is written in German and I only understand English, so thank God for google translate. http://gambas-buch.de/dw/doku.php (use google translate) If Hans hadn’t been kind enough to point his wiki out I might never have found it with a simple google search.
In the first iteration of this application I am only going to:
- Collect the parameters for the extended primitives commands by text input,
- Display the parameters in a grid
- Display a graphical representation of the screen
- Write either a parameter file (*.par) or a source code fragment (*.ino)
Here is the file format for the parameter file I am going to write on my desktop, copy to the SD card, and read from the NerO to display primitives on the CleO:
This should be a good test of the CleO’s file capabilities. In the introduction section on CleOstuff.com it says “The file system supports up to 8 simultaneous file operations.” So I am looking forward to see how it performs this task. The API is so clean I have designed my desktop app to write the code for primitives also. I will use this for my baseline for file I/O benchmarking.
Before I add this to my github repos I want to fulfill some initial requirements. My initial concept requirements are:
The desktop application must:
- accept manual parameter input.
- display the *.par output in a grid.
- display a graphical representation of the screen.
- generate the *.par output file.
- generate a code fragement using the CleO API.
The Arduino library must:
Read a *.par file and display the primitive on the CleO screen.
When I have that done, I will pull it into github along with some future TODO's. If anyone is using the CleO from linux, I hope this will help them and they can join in the development of this because I will definitely be using this product in the foreseeable future.
There are a few of the EXT functions that aren't explicitly documented. For one, the Transform parameter of the BitmapExt call. There is a BitmapTransform function that takes a Scale, Rotation, and Translation parameter and returns a uint16_t, but I don’t have the prototype of the BitmapExt function, so this will take some experimenting and possibly a question to Bridgetek, but this isn't critical right now.
Anyway, none of this coding has gotten me off schedule. The circuit I will be working with is simply a few resistors and a relay. Adding the code for the CleO display should be the least of my worries.
I would also like to thank Keysight Technologies for Scope Month because I won a 1000 X-Series oscilloscope this year (finally). Therefore, I will do my signal analysis last. Depending on when I get my scope I will use the Keysight or my Hantek LA5034 to show the signals in some of the use cases.
I had better get back to coding, so happy hacking everyone…...
-
jlangbridge
-
Cancel
-
Vote Up
0
Vote Down
-
-
Sign in to reply
-
More
-
Cancel
Comment-
jlangbridge
-
Cancel
-
Vote Up
0
Vote Down
-
-
Sign in to reply
-
More
-
Cancel
Children