Again wishes for the Glcd..

[Benj]

Hello Mikat,

SPI is quite simple to bit bang if you have 4 spare I/O pins you could dedicate to this on your smaller device. There is an example of bit banged SPI as part of the FAT component C code. Scroll down to the SPI_BYTE function and you will see an implementation of SPI for bit banged and using the hardware. The data direction and pin setup is controlled by code in the "InitialisationCode" section of the C file.

[Mikat]

I rather use hardware, because it won't take time for MCU so much.. And I don't need to play with timings. And I probably move to 64 pin devices anyway, the Itead Studio makes pcb so cheap, that there is no reason to do it yourself.. And when I have 2 layer board, the tqfp 64 is not so bad...
But maybe in test I use bitbang Spi..
On the other hand, I have 18F85j15 at the table, all I need is tin the wires...

Mika

[Mikat]

Good morning.

At weekend I play little bit of the fonts, but actually no progress..
Ben is there any "smart" solution the problem I bumped at fonts? The boostc won't allow bigger ASCII table than 256 bit..
And if I use like 24x21 pix font, that means that each table can have 4 characters, so I need to do 25 ASCII table, and 25x if/else decision in the component code...
Is there any else way to do it, like that each character is in own array, and it can be pointed directly at ASCII numeric value?
The bigger font is problem with the code size too (the 24x21 takes 6Kbyte), but the 240x320 glcd "requires" at least 18F series pic, so the code space is quite large...
The 7x5 font just look quite "robust" when it is like 10x size....
The 16x10 looks almost that bad too

[Mikat]

Can anybody help me?
I am looking solution like if the acsii character is number 4 (acsii 52) I could directly point "acsii array" 52, without need to go if/else decision... Is that someway possible?


Mika

[Benj]

Hello Mika,

Could you do something like this.

var = var + '0'

which is basically the same as

var = var + 48

Here when var is a number from 0 to 9 this is then added to the ASCII character 0 which allows for a valid ASCII number.

[Mikat]

Probably I wasn't clear enough, sorry by bad English.
What I mean is that I create arrays like
rom char* ASCII32 = {bitmap for space}; // Space
rom char* ASCII33 = {bitmap for !}; // !
rom char* ASCII3 = {bitmap for "}; // ".....

And the thing what I am looking for is that I could point directly of those arrays, not this way.

Code: Select all

if (pos_Str < 12)
	            {
					position = (pos_Str * 5) + count;
	                temp[count]=ASCII1[position];
	            }
	            else if (pos_Str < 24)
	            {
					position = ((pos_Str - 12)*5) + count;
	                temp[count]=ASCII2[position];

Because this way I need to do at least 20 if/else decision, and if the font changes, the code will need to rewritten...

I am looking a way to point directly for those arrays like I have 2 dimensional array... So what I am looking for is that character ! (acsii 33) could point directly to ACSII33[....]...
The 2 dimensional array could be the solution, like ACSII[this is the char number, like 33 at character !][and here is the bitmap data], but the boostc won't allow bigger array than 256 byte .
Was that complicate enough?

[Benj]

Hello,

Most compilers don't allow arrays over 256 bytes on standard 8-bit PICs because of the fundamental limitation in the size of a memory block on these devices.

Some compilers may support larger arrays by using bank switching trickery but this may add a lot of bloat behind the scenes which is why this is an uncommon feature.

dsPIC, AVR and ARM should all support 2D arrays no problem.

[Mikat]

Ok.
And there is no change to point variable direct to the array name?
Dspic might come to me with Flowcode 5, I just don't have money to buy both Pic and dspic version, but that under thinking...

Mika

[Mikat]

OK.

Lets update things here.
The component is quite ready at my side (except the Ilitek IL932x chip driver, I'll update it when I had time to it), the print number,string,pixel,box, line and set colors macros are working, so is the landscape and portrait orientation.. The print bigfont works, but the 24x21 pix font looks bad
The code is at the Ben, so its up to Matrix will it be supported at Flowcode 5...
If anybody would like to use and test the code, just pm me, and I will sent the component (it's a custom component, not c code, so it could be used directly at flowcode) and instructions to how to use it...
Of course the component is "beta" and there could (and will) be bugs..

Mika

[Mikat]

Hi.

There has been couple request about this component, so I'll upload it here.
If you test and like it, you can put here feedback about the component, and the wishes for "real" component at the Flowcode...
And of course report at the bugs, and questions too..
Read the readme....


Mika

[Mikat]

Ben, is it possible that you or somebody else could re-engineer that ssd 1289 custom code for PIC24/dSPIC?
I don't have time to learn new compiler first. What compiler does the dSPIC version use? And how about the usege of Microchip graphic display designer, and other Microchip tool, can they be used with Flowcode dSPIC version?

Mika

[Benj]

Hello Mika,

Most of the code should work on dsPIC without any edits.

You will have to change your Port and Tris names from lower case to uppercase.

Also you will have to take out the #ifdef boostc and hitech stuff and only provide a single font set.

Other then this you shouldn't really have any problems.

Let me know how you get on.

[Mikat]

Ok.

Just take a look the trial version of the 16 bit glcd component, and it actually looks quite same as the 8 bit..
But there is one problem, I don't have pro version of the 16 bit Flowcode, so there is no way I can test the code...
The code is wayyyy too big for trial version. I do have some 16bit PICs, so that is not problem.

Mika

[Mikat]

Well, the dSPIC version doesn't have the code size limitation, but reduced number of component. But the result are same, I can't compile the tft component code with the trial version, so the ssd1289 component for PIC24/dSPIC is something that I can't work at the moment...

Mika

[Mikat]

Hi.

I just get the feedback of the code, it woks ok with 18F4620 and 4685, but fails at the 46k20.. I tested my self, and the code runs fine at the 18F44k20, but only at max 20MHz device clock, above that the code fails...
Ben do you have any idea what could cause that, and is the problem at the code, or something else? The code runs fine at the 18F4620, even at the 100MHz device clock (yes 25 MIPS, I use my 4620 at 25MHz xtal and hspll enabled and it runs ok with that display code, and yes the hspll works)

Mika

[Benj]

Hello Mika,

It might be worth changing your port definitions to lat definitions in the custom component properties.

Anywhere you refer to a port try replacing with lat. note this will only work for outgoing ports.

looking at your code it could be the %a, %c and %e substitutions should change from portx to latx where x is the port letter.

Basically what might be happening is that you write a value to the port register to modify a output pin, the next instruction you again write to the port register to modify another pin but the port register itself may not yet have updated the change to the first pin so when the code does the read/modify/write process corruption can occur. This essentially resets the first pin without you or the hardware even knowing about it. The LAT version of the register does not have this problem and is there to allow you to have high speed output writes.

Let me know how you get on.

[Mikat]

Yes, that does the trick ...
Thank you Ben,thumbs up...
So instead to use porta,portb,portc etc. on the custom component ext properties, do use lata,latb,latc etc, this will allow the code work at hi chip clock at the k20 series chip...
By the way, the same code runs at the 4620@100MHz about 4 frames/sec, and 44k20@100MHz almost 7 frames/sec, but the speed is same at the 40MHz about 2,7 frames/sec, so probably the 44k20 does something differently, it scales nicely to the 25MIPS, but the code compiled for 44k20 fails slower clock than 4620 compiled code, both codes at the 44k20 chip....

Mika

[Benj]

Hello Mika,

So instead to use porta,portb,portc etc. on the custom component ext properties, do use lata,latb,latc etc, this will allow the code work at hi chip clock at the k20 series chip...

Yep that's it

By the way, the same code runs at the 4620@100MHz about 4 frames/sec, and 44k20@100MHz almost 7 frames/sec, but the speed is same at the 40MHz about 2,7 frames/sec

Hm that's very strange. I wonder if its something to do with time to fetch memory from certain locations? Maybe the K20 has a larger pipeline or something like this which causes a less delays at speed. Probably a tricky one to find out exactly whats going on here. If you do find anything further then let me know as would be very interested as to the cause.

Glad it fixed the problem for you though, ran into this one a few times myself and its very hard to diagnose unless you are aware of the specific issue.

[Mikat]

Maybe in the Christmas holiday I had time to check little bit of that speed difference at high clock, but I don't see it very important, because it occurs above the max speed...
Now maybe the next project is the 16bit code of the tft display, but there is couple things which makes things difficult... First that I can't test the code at the trial version, and second I take look the 16bit devices datasheets and the way the i/o ports are used makes the code quite difficult, like example 30f4013 (40pin) don't have any 8 or 16 bit wide i/o port, it has b port which is 13bit wide, and other port which are was it 1-6 bit wide, and that thing seems to vary between devices, so the code ain't easy to make work all devices... .

Mika

[Mikat]

Okay, little update again.
Worked the code with 16bit, should be ready, but no change to test it...
Ben, do you have change to test it (probably you don't have ssd1289 display..)?
The other thing is, that at the moment, code is written by dspic30f4013, or devices which has same pinout, and it works only at port b,d and f, because the quite odd port pinout of the 16bit devices...
Anybody have 30f4013 (or similar),ssd1289 display, and pro version of flowcode for dspic (I have the chip and the display, (but not the flowcode for dspic pro version), so the code could be tested?

Mika

[Mikat]

Seems that nobody can help about this...
It just would be nice to get the code working with 16 bit devices, before the Flowcode 5 launch...

Mika

[medelec35]

Hi Mika

(I have the chip and the display, (but not the flowcode for dspic pro version), so the code could be tested?

would you like to post or pm your flowchart, and I will compile to hex for you.


Martin

[Mikat]

Hi Mika

(I have the chip and the display, (but not the flowcode for dspic pro version), so the code could be tested?

would you like to post or pm your flowchart, and I will compile to hex for you.


Martin

Thanks Martin, I'll sent you the flowchart and the component file when I had time. My 3 year daughter is sick and I haven't got a time to even sleep...

Mika

[Mikat]

Hi.
There is the flowchart and the custom component..
Just change the target processor at 30f4013...
By the way, there is bug in the original ssd1289 custom component, the Set back color has the color shifting wrong, it should be like Set Fore color eg. red and green should switch place, and then the clear display macro should be removed at the Set back color macro...
I'll post the fixed version there asap...

Mika

[medelec35]

Hi Mika,
I have compiled using V4 dsPIC pro & there are errors that will require sorting,
I have attaced C and compiler messages.
I do not know dsPIC as well as PIC version, so I would struggle to help to be honnest.


Martin