What is the useful minimum recommended spec for the pic to be used with this app?
I'm using a 18F4550 and even before the demo limit is reached the processor has run out of ROM space.
Processor spec
- tihomir.losic
- mikroElektronika team
- Posts: 2138
- Joined: 02 Dec 2009 14:16
- Location: Serbia
- Contact:
Re: Processor spec
Hello,
my suggestion to you is to use PIC18F8520 and BIGPIC6 development system.
BIGPIC6 is a development system that supports a wide range of 64- and 80-pin PIC MCUs, and it can be used with Visual TFT.
Best regards,
Losic Tihomir
my suggestion to you is to use PIC18F8520 and BIGPIC6 development system.
BIGPIC6 is a development system that supports a wide range of 64- and 80-pin PIC MCUs, and it can be used with Visual TFT.
Best regards,
Losic Tihomir
mikroElektronika [Support team]
Re: Processor spec
Hi,
It there any way that I can use visual TFT and get the LCD images/touchscreen data stored on an external MMC card instead of in the ROM space. I know it will be slower to load the data from the card to the lcd but it would free alot of ROM especially for smaller pic with more limited resources.
Or is this a bad idea?
It there any way that I can use visual TFT and get the LCD images/touchscreen data stored on an external MMC card instead of in the ROM space. I know it will be slower to load the data from the card to the lcd but it would free alot of ROM especially for smaller pic with more limited resources.
Or is this a bad idea?
Re: Processor spec
jumper wrote:Hi,
It there any way that I can use visual TFT and get the LCD images/touchscreen data stored on an external MMC card instead of in the ROM space. I know it will be slower to load the data from the card to the lcd but it would free alot of ROM especially for smaller pic with more limited resources.
Or is this a bad idea?
This is along the lines of what I've just been considering, I've only really just scratched the surface of the TFT library so I'm just discovering what is possible though the image functions do all refer to images in code memory.
It does seem quite limiting if the only way to display an image is from ROM but then that's pretty much how the older LCD libraries worked.
Getting the image from any other source will slow down the display update but I've yet to try it so I dont know how slow it will be. I imagine I'll have to write my own display driver function to draw an image on the display from RAM data obtained from whatever source. The problem I have is that ME must surely have done something like this already as they are selling the mmb display that has an sd card for data so they must have created functions to take nonROM data and put it on the display.
I also find it a little annoying that ME show images of these displays showing high quality images of butterflies etc and do not highlight the limitations of the system in terms of speed and memory usage.
Re: Processor spec
I hope and expect that in the future examples with the contact and transfer are provided by SD MMC for the display TFT.
But not in 6 month, i hope.
Best regards
But not in 6 month, i hope.
Best regards
Re: Processor spec
Helmut wrote:I hope and expect that in the future examples with the contact and transfer are provided by SD MMC for the display TFT.
But not in 6 month, i hope.
Best regards
It seems to me that ME do good hardware and get the first run at the software to drive the hardware and then they stop and the user has to optimise the system and get things working as they want. This sometimes does leave one thinking that ME haven't finished the job but that's the way they work, they don't waste time on the last 10% of the job that we all know takes 90% of the development time.
I have just tried a test using the TFT_Dot function in a loop just to see how fast the display update would be and a complete screen updates in about 3.5secs so assuming that getting the dot data takes a similar time then a screen update of about 7secs is likely. It may well be possible to speed up the update by eliminating the TFT_Dot function and recreating that functionality by referencing the driver chip datasheet.
- tihomir.losic
- mikroElektronika team
- Posts: 2138
- Joined: 02 Dec 2009 14:16
- Location: Serbia
- Contact:
Re: Processor spec
Hello Helmut,Helmut wrote:I hope and expect that in the future examples with the contact and transfer are provided by SD MMC for the display TFT.
But not in 6 month, i hope.
examples for MMC are written for mikroMMB boards. We implemented TFT, MP3 and MMC
(ME_player: http://www.youtube.com/watch?v=c6AcOWKNnuY)
Please, watch this video.
As for our products and pace of development of both software and hardware,
please, follow this link:
http://www.mikroe.com/eng/news/index/
From November 16th until today (three months):
more than 10 NEW hardware products, Visual TFT, new releases for PIC and dsPIC,
and of course, PIC32 compiler is rising, we expect Beta for about 5-6 weeks.
Thank you for using our products.
Best regards,
Losic Tihomir
mikroElektronika [Support team]
Re: Processor spec
Thank you Losic Tihomir
Now, I am impressed by the Mikroe produkten already very much.
And, nevertheless, I wish that it is sometimes more complete.
Examples for board that SD Card, audio codex and serial EERom has.
Then also examples of all possibilities.
I will be one of the first it will buy the PIC32 BASIC compiler, I wait on it.
I have already bought myself MMB32 from Mikroe and then will get cracking immediately, I hope Mikroe then has also examples of this Board with SD-Card et cetera.
Greeting Helmut
Now, I am impressed by the Mikroe produkten already very much.
And, nevertheless, I wish that it is sometimes more complete.
Examples for board that SD Card, audio codex and serial EERom has.
Then also examples of all possibilities.
I will be one of the first it will buy the PIC32 BASIC compiler, I wait on it.
I have already bought myself MMB32 from Mikroe and then will get cracking immediately, I hope Mikroe then has also examples of this Board with SD-Card et cetera.
Greeting Helmut