Hi, Im looking for a MCU with enough internal ram to bitmap a 1/4vga LCD screen wich is 9600 bytes at least for 1 layer of mono, most ive looked at so far seem to stop short of this, from microchip the dspic30f6010 has 8k internal ram im using the dspic30f4011 atm which has about half that, and now the tables ive been looking at farnell seem to have totaly incorect amounts of ram listed,
any one got any pointers to tables or a device theyve used for such a thing ? or is it possible to somehow compress the bitmap ? I know I could use an external ram but this isnt very attractive.
I gues a lcd controller might do too, but it would be usefull to have a mcu to do some other mcu type stuff with. mostly for debug info for my motor controller but I was thinking of a simple curve tracer for inductors to find the saturation point maybe even a bode plot to find resonant freq etc.
The dsPIC33J256MC710, has over 30kBytes. In smaller packages, there are about half a dozen models with 16K (the dsPIC33FJ64 models mostly offer this size). Seriously though, it'd generally be easier to have something with a simpler memory architecture to manipulate this sort of RAM size quickly. I'd suggest the Toshiba TMP92FD28FG/DFG, which has just come onto the market. I played with an early sample, finding it excellent for doing pre-processing on an imaging system.
Remember that external RAM need not be a great problem, ifthe chip has the memory space/architecture to directly handle such memory, it only involves one extra chip. Some of the latter 16bit 8051 variants can do this.
not stuck completly though I do have a modest investment in getting up to speed etc. as someone else suggested the lpc2106 looks quite good and will do all the motor pwm stuff too. also the DAC would be a bonus.
Im still in 2 minds wether to have a dedicated controller or not. then theres the extra protocol between the 2 controllers, dual port ram would ofc be an ideal solution.
thanks, Im thinking of using a dspic33 now as I can get hold of one with 16kb and motor control now, im thinking it would be the simplest upgrade route from my dspic30f4011 application however im looking at the data sheet to see what changes there are, not too many actually, but im realy baffled by the addition of DMA particularly to the ADC, gone are my ADCBUFF1,ADCBUFF2,3 etc, seems there is just one buff now at least only 1 is specified in the devices include file, although the data sheet seems to show 16 buffs still, and it mentions you can use DMA when more than one result is needed per interrupt, although it doesnt say thats the only way, but the DMA is doing my head in trying to understand it cos its not very clear, at least wrt the adc, everything else seems to at least compile in a dspic33f.
so does anyone know if I can I use it in the same way ie buff1,2,3 are still there but I have to define them myself ? seems it is this way in production samples PS and seems to imply it is removed for the non PS devices in favour of DMA but then it mentions it provides this adress as a DMA area, It also still has the number of conversions per interrupt wich implies it still has somewhere to put the 16 words.
I dont realy need the DMA at least not for the adc as it wont make things any quicker.
Im also wondering what if microchip MCUs are particularly difficult to use compared to others and if it would be easier to start from scratch on another type of MCU ?
What would be realy nice if you could assign port/peripheral to different pins, so you could be sure you could use any combination of peripherals and always have gpio bits wich are sequential/contigous. ie I got stuck not having d0-d8 in one gpio port and had to split it into 2 wich sucked for making it as quick as possible.
There is a single sixteen byte buffer 'block' for each ADC. It starts at the specified address in the memory map. You can program the ADC to use this starting at 0 for each conversion, or 'toggle', so that alternate conversions use the high or low half of the buffer (BUFM=0). If you set the unit to interrupt after a single conversion, and not use DMA, then the data is available through the buffer.
The data is transferred to the buffer block by the hardware, and DMA, takes place from this block.
They are hard to use compared to some chips. Mainly because of the sheer number of peripherals, and the memory architecture.
thanks very much, so it seems like your saying it is backwards compatable with the dspic30 wich is nice, I currently do 4 conversions to genereate 1 interrupt and read them all from the buffer in the ISR, I wasnt too clear if this was still suported as it said either 1 per interrupt or use DMA, or if the buffers were stil there but seems they are, just doesnt have the buffers defined in the h file anymore .. no real biggy.