PDA

View Full Version : Cpu selection help



longpole001
- 29th October 2013, 02:43
hI GUYS,

i am looking at a project where it has the following requirements , and wondered if i have got enough grunt in the current cpu selection to do the job , current cpu selected on is 16f1947( 32mhz,1k mem , 256eeprom)

graphics would require a bit of storage and memory to get them loaded and sent out the lcd, along with touch screen and keyboard scanning ,64mhz is a better option
project requires

240x 64 GLCD - option 1
320 x240GLCD , with 4 wire resistive touch screen - option 2
1 x rtc module
2 x rf modules , spi interface
Mini sd card modules - spi interface
matrix keyboard 5 x4
usb to TTL module
53 I/O with a 3 spares

thinking that the cpu best to have maybe the 18f67k22 or k90

as 16bit is not an option as as far as i can see for picbasic ??

regards

Sheldon

Art
- 29th October 2013, 03:53
It comes down to RAM for the graphics,
which would be more or less scaled to other specs of each chip I imagine,
but that's what I'd be looking at rather than program memory, speed of the chip, etc.

longpole001
- 29th October 2013, 06:36
if i want to do some playing with 16 bit cpus , its seems i must start to look at C, is that the case?

Jerson
- 29th October 2013, 06:43
@longpole

You didn't mention if you plan to use monochrome or colour graphics. Monochrome is easier to handle. Wonder if you looked at the storage requirements. A 320x240 single color bitmap needs 9600 bytes of storage. Assuming this needs to be in 16 bit color, the storage need gets up to 153600 bytes. 320x240x16/8.

A high cpu speed is definitely a must and you will need to hand-optimize the output to be able to refresh the LCD fast. Otherwise the display refresh will appear very sluggish.

A PIC with a PMP peripheral will make a good choice for such an application.(I did not check the datasheets for mentioned Ics)

If you wish to make a frame buffer, lots of RAM will be needed.

longpole001
- 29th October 2013, 07:23
maybe some sram make resolve this mem issue ,

http://www.microchip.com/microchip.webcontent.provider/Video.aspx?id=en543526

HenrikOlsson
- 29th October 2013, 07:48
For some time now I've been meaning to get a development board for the FT800 EVE Display engine (http://www.ftdichip.com/EVE.htm) from FTDI to play with but have yet to get around to it. As I don't really have an application in mind it would probably be yet another board lying on the shelf gathering dust....

Anyway, MikroE has a nice board (http://www.mikroe.com/add-on-boards/display/connecteve/) with the FT800, a 480x272 colour TFT display and resistive touch. Might be worth looking into.

Another option might be their SmartGLCD board (http://www.mikroe.com/smartglcd/). I've got one of those and did start a project coding some graphics routines for it, something I kind of sucked at...so now it too is gathering dust... :-)

/Henrik.

longpole001
- 29th October 2013, 08:15
well i am about 70% of design down the rd ,
custom matrix keypad is made
prototype pcbs for the design done,
modules purchased etc


controller with the display is started being coded and that when started to see a lack of usable mem when even assigning the pin var with only 1k of mem on the 16f1947

which come to the conclusion that i may have made a error using the 16f1947, although the looking at other 8 bit chip alternative of 18F67K22 appears to be pin to pin compatable with the the 16f1947 , but with 4k of mem . 128k of program data internal 64mhz , i am thinking i can easly add a sram using a spi ( yes hardware spi is now the option of choice.to the spi port ,if i run short of buffer space for the larger mono graphics display ???

it seems the 24F series is not supported by the picbasic form what i can see??
also the cost of the 16bit chips with larger usable mem of 8k is way more than adding some extra ram, although more speed is alway nice !!

Jerson
- 29th October 2013, 09:42
Well I guess you must already know, everything on a GLCD including the text is stored as bitmaps. All that needs space to keep, read and transfer to the screen. I would not say which language is suitable; you must know the difference between a fast car and a regular one. Some professional compilers are fast cars. Once that is known, you can do wonders with whatever tool you have at hand. The thread on CLCD graphics by Art is just one example of what you can achieve.

I have worked on a monochrome GCLD with a 18F46K22 and done a bare bones text kind application using the Internal oscillator. Getting the speed to acceptable levels is the major aspect of the project. One tip would be to use byte aligned writes to the display. If your hardware is not finalized, ensure that you can read the GLCD besides write to it. Helps in doing pixel aligned instead of byte aligned displays.

Sorry if my words sound cryptic. That's what coding GLCDs does to you after a while ;)

longpole001
- 30th October 2013, 00:03
thanks jason, this is the first glcd i have had to code for , and although its mainly txt , and about 10 other chrs ,

although i can write in other lang including c ++ a little , not tried for pic apps

ill get the larger pic of 18f67k22, 4k ram , 128k program , internal 64Mhz osc , as it same pin out as the 16k1947 ( except for 2 pins ) for the prototype

will add the 1mbit SRam chip via spi , in the design , but expect the bit maps can be stored in the program memory space ?

i have not got any coding examples for the GLCD code as yet and will start doing the look around for some pic basic code for examples in the coming week , so if you can share some with me that would be much appreciated

A lot of the modules i have have some examples but i expect its going to take me while to complete the glcd programing and complete a lot of the modules


cheers

Sheldon

Jerson
- 30th October 2013, 03:59
Sheldon

Sorry, I do not do much PicBasic coding these days as I have shifted to ARM core. Most code I have is in C.

I'm not sure if Arts' thread has any code. You could take hints from that.

longpole001
- 30th October 2013, 06:18
hi jason , if you come accros some glcd basicpic coding , send me a a link or a quick email

richard
- 31st October 2013, 00:24
I wrote this pbp3 serial I/f for a 64/128 glcd , it works ok and has software adjustable contrast even. but its much easier to do on an arduino mega
in c

longpole001
- 31st October 2013, 05:51
cheers for that