uOLED-96 and Spin problem
wacko
Posts: 10
Hi everyone,
I'm new at this Propeller thing and I'm currently trying to get some basic stuff working with the uOLED-96.
So the code below is just some testing. The problem is that the second cog does the counting but not the the text output. If I call the count method directly it works. Any idea what I'm doing wrong?
ThanX
VAR
long stack[noparse][[/noparse]50],x
OBJ
OLED : "uOLED-96-Prop_V4"
DELAY : "Clock"
PUB Main
DELAY.Init(8_000_000)
OLED.InitOLED
OLED.CLS
x:=0
OLED.putText(0,0,0,255,0,80,string("starting new cog"))
DELAY.pauseSec(2)
cognew(count(@x),@stack)
DELAY.pauseMSec(5)
OLED.putChar(x,0,2,0,255,20,0)
DELAY.pauseSec(2)
PUB count (xAddr)
repeat 68
long[noparse][[/noparse]XAddr]++
OLED.putText(0,0,0,255,0,80,string("message from cog 1"))
I'm new at this Propeller thing and I'm currently trying to get some basic stuff working with the uOLED-96.
So the code below is just some testing. The problem is that the second cog does the counting but not the the text output. If I call the count method directly it works. Any idea what I'm doing wrong?
ThanX
VAR
long stack[noparse][[/noparse]50],x
OBJ
OLED : "uOLED-96-Prop_V4"
DELAY : "Clock"
PUB Main
DELAY.Init(8_000_000)
OLED.InitOLED
OLED.CLS
x:=0
OLED.putText(0,0,0,255,0,80,string("starting new cog"))
DELAY.pauseSec(2)
cognew(count(@x),@stack)
DELAY.pauseMSec(5)
OLED.putChar(x,0,2,0,255,20,0)
DELAY.pauseSec(2)
PUB count (xAddr)
repeat 68
long[noparse][[/noparse]XAddr]++
OLED.putText(0,0,0,255,0,80,string("message from cog 1"))
Comments
It is possible to write I/O drivers so more than one cog can use the device, but it requires extra care and some use of "locks" or "semaphores" as they're called to make sure that both cogs are not trying to do different things at the same time.
Another thing you could try doing is writing a graphics program and LCD driver. The graphics program uses a double screen buffering technique.· Each cog can write to the offscreen buffer and at some point the offscreen buffer is copied to the on screen buffer that the driver then clocks out to the display.· You, as the programmer, would have to make sure the two different cogs writing to the offscreen buffer aren't writing over each other.
About two weeks ago I had a 256 color driver working for the OLED screen.· I then had to shelve my work until I get more time.· The other day I powered my project back up and I think·I missed a connection somewhere because my screen colors are a bit wild now.· I need to check to ensure I haven't damage the uOLED.· It is possible my GND connection was off my one pin.· Oh I really hope I haven't damaged it.
Anyway, if I get back to my project (in a couple weeks) I can offer my code on the forum/object exchange.· I was thinking that I would try and make the LCD driver compatible with the Parallax Graphics driver or some other graphics driver from the Hydra thread.· I need to research this further.
Good luck with your project.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com
One little spark of imagination is all it takes for an idea to explode
If I get this right you could use one cog to permanently write the data on the screen from a buffer which can be written to by any other cog. Maybe there should be a way to mark only the pixels that have changed so you don't have to write the whole screen every time.
I think overwriting the data of one cog by another would be fine. You just have to have some time management to decide which data is the most actual. Than you wouldn't need to put out data to the screen that already obsolete.
I will see if I can work out something. But I'm interested in seeing your code.
If you wanted to only output updated screens, there may be a way to implement a hold function where the driver only outputs new screen data to the uOLED when it is 'kicked' and told to do so.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com
One little spark of imagination is all it takes for an idea to explode
One reason is: Power saving!
It is a different situation when time for display and data generation has be split within the same processor. But the Propeller is just made to avoid this...
Something like your driver would be very nice. Because of the slow refresh rates, I resorted to never erasing the whole screen and just using a "line refresh" function... which basically involves writing various black colored characters to the line until it was erased. Which looks fine, except that the character set, which will effectively erase one line is slightly different from the character set required to erase another line, which I don't understand at all[noparse]:)[/noparse]
Forgive my language here... but the idea is ok... I think there might be a little problem with the screen memory controller. At one point, I had patterned noise on my little 96. There was a red line right down the middle and part of whatever was on the top line also showed up as a pixel of noise on the horizontal right through the middle. I let it rest for a few days and the problem went away.
Wacko,
I am in and out of the forum, so I miss things from time to time... I am sure you are probably aware of the pll settings required by the 96.
Rich
no, actually I don't know exactly what your referring to. I'm just beginning to get into the propeller architecture. I've done some projects with Arduino before but the Propeller (especially the graphics controlling) seems a little more complex.
My first tests with the display were kind of unsatisfying regarding the slow refresh rate though everyone says it should be able to handle videos and animations.
Best regards
The 128 has a much better refresh rate. You have to remember that we are cutting the speed of the 96 in half because of the combination of crystal speed and pll settings.
There was a long and sometimes very misleading conversation about the origins of this problem. Hidden deep in another thread there was a flat out statement that the real problem was in the timing of one of the serial libraries... but it was a pretty tough problem to solve.
So... unless you are really good at massaging graphics, you won't be watch movies on your 96. I found the refresh issue to be an opportunity for creativity and found that if you write over your text ... with the same text in black... and then write your new text in white... one line at a time, you have a rock solid display.
I didn't want to waste memory on this function, so I just wrote a generic routine to black out a line at a time with a combination of characters in black. That gave me a very nice dissolve effect and what looked pretty cheap then looked pretty interesting.
I was actually delighted to find that the 128 had a uSD card. I don't know how I missed it in the details.
How are you doing?
Rich
If Parallax would include the 96 or something like it in the education set up it would be a lot more fun[noparse]:)[/noparse]
Rich
as the code to shove pixels out to the display is written in spin I thought I could get it little faster by rewriting the procedure in assembly. But didin't have the time to get into assembly yet. So far I could write a little tool to convert 24bit-jpgs to 16bit raw coded images and display them loaded from the sd card. The loading from the card seems very fast. The display speed is acceptable maybe for a slideshow but not much more. By the way, was there a solution to the problem you described. And if there should be a problem with the crystal could that be solved by connecting a faster crystal and setting pll to a smaller value? (I confess I still didn't understand why the speed of the display is halved by the pll settings) This also seems to be an issue when using the sd card which doesn't work properly at pll16x.
As was mentioned there are two or three other threads that discussed the PLL/Crystal setting.· The short of it is that there is a 8.0 MHz. crystal.· Using the Propeller's PLL in 8x mode, the Prop runs at 64 MHz which is stable and safe but not 80MHz.· The demo from 4D Systems is coded with the PLL at 16x, which is 128MHz. and the Propeller is not stable at this speed (judging by the informal poll of users on this forum).· The one uOLED-96-PROP that I have doesn't even run the 4D Systems demo at this speed.· Some uOLED do.· In order to stay within the tolerances of the Propeller, your code should operate in the 8x mode. I wouldn't blame the sd card for not working at pll16x, it is more likely the code not executing or hanging up because of the Propeller running too fast.
I haven't had time to research replacing the crystall on the device to say a 10 MHz. crystal and using 8x mode to get 80 MHz.· I really hope it is possible but it would require some delicate soldering.
Wow - you do have a utility for converting 24 bit JPGs to 16 bit raw?· Can you share it?· PLEASE, PLEASE!· Can something similar be written to get 8 bit raw?
The Spin routines provided in the demo could go faster if in ASM.· Also, the controller chip for the uOLED contains high level commands for drawing the square, pixels, lines, etc.· Going past the high level routines and simply clocking in the data to the GRAM (graphics ram) is far faster, especially with a routine in ASM which I prototyped but haven't finished.· Attached is a picture I took of the display running a little demo I put together.· It had spinning stars (like the orignal graphics demo), scrolling text and counters in the middle of the screen.· Pretty simple.· This particular routine used only 4 colors (off, red, green, blue) and used the Parallax graphics driver.· The top number in the center of the screen is the frame rate that the main routine ran at.· It was between 40 and 50 frames per second depending on if the scrolling text was on screen or not.· The bottom number was just a frame counter.· The start twirled and spun in an eliptical shape.
Above, in another post, I mentioned double buffered graphics and that in Propeller usually one COG is devoted to doing nothing but driving the LCD/VGA/TV and another is doing the graphics and perhaps another is calling the graphics routine.· This setup requires two buffers for flicker free animation.· I had alwasy thought that both buffers should be in the Propeller, but with an LCD you can use the display's memory as a buffer and save some code space and only have one buffer in the Propeller.· The LCD driver and the main routine drawing the graphics aren't exactly running in parallel any more either.· I need to think this through some more.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com
One little spark of imagination is all it takes for an idea to explode
Graphic Converter (OSX) will do this www.lemkesoft.com/
as the graphic Converter seems to cost some money and I wouldn't necessarily pay for such a rudimentary function I think a little diy solution is better. It's really nothing special just a little java prog that reads the jpeg, converts every pixel to rrrrrggggggbbbbb and writes that in a file (two bytes per pixel) I can post it as soon as I have added a bit of interface (its all harcoded now) (and maybe some extras we'll see).
[noparse][[/noparse]Regarding the crystal: if you get another crystal working why not taking an even faster one (80MHz) and run the pll at an accordingly lower value.]
Best wishes