Noob-ish question, porting c++ or just write a new lib?

RinksCustoms

Trying to figure out how to use an LCD module on prop quickstart. Its a touchscreen 3.2" originally made for the arduino mega 2560 board, but it has a 3v3 mode via a switch for the voltage translation. The LCD controller is an SSD1289. The board also features an SD slot. Why do all this work? Arduino is nice to play around with, and analog in is also nice to have natively, BUT, it is slower than molasses in february getting pictures & "icons" off the SD and onto the screen! First problem of the MEGA is that the clock is set at 16MHz, IIRC, thats less than a prop running on _RCFAST! JEEZ!! I know its an AVR underneath but i'm sure i cant OC or it will probably fry the PLL or cause weird effects with programs.. I know the Prop inside and out, even how to OC it to 120MHz. I know the Prop can draw that screen orders of magnitude faster than a 16MHz AVR. So that's the why part.

Question is, is there a way or program that can convert a library written in C++ down to C99? Or might this be a "from scratch" endeavor?

I did try to just include a path to the library's .h file but Simple IDE just barfed out error after error about "unknown type name class" - I'll take it at face value that Classes are not part of the C99 world. Sorry again if this sounds like a lain man. But I am a hobbyist with this sort of thing and just learning C++ and C, but no stranger to SPIN, BASIC and am familiar with PASM. Thanks for any pointers.

Mike

Heater.

There is no need to convert that C++ code to C. propgcc can handle C++ perfectly well.
You should be able to use a lot of the code as is (The files should be named *.cpp and *.h)

Not sure but those errors you describe sound like you included a C++ header file into a C file with (*.c exention). That is a no no. Better to have all your code as *.cpp even if he content is basic C code.

Of course I'm sure there are a lot of other changes required to get the thing to compile and work.

If you can post the code perhaps someone can advise about that.

RinksCustoms

Thank you for the quick reply Heater. Yes, now that you mention it, I did. Tried to #include "UTFT.h" (a C++ .h) in my Boost gauge.c main program file. Will implement your suggestion. Was looking at the datasheet for my LCD display, and although the controller chip has many features and multiple mcu interfaces, it seems that only one interface is available on this LCD shield for display data(16bit parallel). getting it to compile shouldn't be too hard now that I know what i'm doing wrong. Re-assigning pins should be a doddle. Best bit would how to connect it, the shield would use 29 pins unless i implement a shift register or some kind of scheme to share the data bus with external goodies like an ADC.
One step at a a time i suppose.

Heater.

29 pins, ouch!

If you need pins you are going to need hardware assistance. A shift register might get you back to that slow as "molasses in february" situation.

Perhaps you need to dedicate a Prop to it and drive it over a fast serial connection.

average joe

I've worked with the ssd1289s and FWIW, getting files of of SD is slow even on the prop. We used SRAM chips to dump data to the display as fast as possible but it still took some time to get off of SD. That was the real weak link on the design we made. I have some boards left and would send you one if you're interested. I've been busy with other projects lately but hopefully I'll have some time to get back to it

http://forums.parallax.com/showthread.php/137266-Propeller-GUI-touchscreen-and-full-color-display?p=1114041&viewfull=1#post1114041

http://forums.parallax.com/showthread.php/137266-Propeller-GUI-touchscreen-and-full-color-display?p=1117341&viewfull=1#post1117341

RinksCustoms

Please excuse things I miss or leave out, thinking aloud..
@average joe - ..interesting thread indeed, breezed over both threads you gave. I would not have a problem dedicating a whole prop to the LCD, although the fact that there is a CS line on the data bus of the LCD says that maybe there is hope of freeing up some of the IO's to do other things while the LCD isn't selected since the LCD "should" ignore data on at least the 16bit bus while the screen isn't being updated.
@Heater - Shift registers are an option, since in my particular application though frame rate might be an annoyance if it's slow enough, since i'm trying to update screen data from a MAP/OIL TEMP/OIL PRESSURE sensor hopefully every 0.5sec or so. I'm assuming that a write clock cycle is the same terminology as writing a pixel data, datasheet says max buss freq = 100nS for a write cycle (10MHz) -certanly possible with a Prop-, so writing a frame of 262K color pixels(2 WR cycles/1px) @ bus f_max would take about 15.4mS (~65FPS?!)

As you stated before though, the issue is with buffering from an SD card which isn't the fastest serial device in the world. I tested three SD cards on my windows 7pro 64bit PC and a china card reader on USB 2.0, oddly enough i was getting higher read speeds with an older 2GB card than 2 newer SD's (4G@ class 4 ~18MB/s, and an 8G@class4 ~18MB/s and my SD from my Droid RAZR MAXX - 32GB/class10 ~18MB/s). Of course the results could be skewed by a number of factors like the SD card readers speed, cache size, ect. A frame of 240X320 pixels @ 16bit if loaded from SD card @ 18MB/s throughput to the screen, a frame would take 8.5mS (~58FPS?!) Of course my math here assumes stable streaming from SD to LCD and that the devices can actually operate at those speeds. What kind of throughput were you able to achieve without SRAM from the SD cards you used? How fast could you do a write cycle to the LCD screen per pixel? I realize that the actual frame rates depend on how fast data comes from the SD, gets translated by the Prop into the weird pixel format the screen uses for 262K color, and spit out to the LCD. Wouldn't introducing SRAM(s) into the equation create delays(at least a few nS per I/O op)?


I was looking closer at the lib's that Henning Karlsen (http://electronics.henningkarlsen.com) Even though the screen is connected as 16bit bus, and digging through the various folders that the UTFT.h and .cpp files reference, it seems that the more i dig through the libraries reading where the path goes from the program through the libraries and out to the pins, it's a bit confusing to a novice, but is also apparent that these libraries are infact not usable with the prop unless i figure out a way to make a "translate.c" that can translate from the "wiring" arduino uses to it's pins to something propeller.c and simple IDE can understand. Probably over thinking this, also, I noticed that the lib files are just a collection of draw functions so even if i made a translate file, it would likely run slower with bloated program size with all the linking to multiple libraries just to make someone else's lib's work on the prop when they were originally written for an AVR underneath an Arduino vernier.


on a side note - just googled the part # on the ribbon under the screen, company in japan is selling these @qty of minimum 10 for 40.00 yen ea! Thats $4.10 for 10 of these screens with touch! unless of course google scroogled the translation from simplified chinese. http://detail.1688.com/offer/1198597429.html

This is something i'm interested in tackling. I know it's a bit OT, but i want to program the prop with Simple IDE since its C code and a bit more universal than SPIN.

EDIT - Just got done reviewing Dr. Acula's .zip files. Interesting though, some of the spin files will be useful in getting my display to work with a Prop.

jazzed

Martin_H created a Propeller Arduino library for use with SimpleIDE. You should be able to use that without translating.

Propeller SD card speeds won't ever get close to 18MB/sec .... There is no SERDES for accelerating data input.

That's a great LCD link. My own experience with LCDs is that availability for any one type is fleeting at best. A break-out board helps to isolate the problem of constant change on the products.