Does using memory allocation API such calloc / malloc cause issues on ARM based boards ? I recently faced a issue wherein I used calloc (1024 Bytes) and this buffer was used across many functions in a single source file. I observed the output of a particular function varied randomly when calloc was used, but when I switched over to a fixed array, the issue never showed up. Hence I am wondering if calloc has got any limitations on a small memory footprint board.
Memory allocation issues on ARM boards
arm
Related Solutions
You don't need an MMU for external RAM memory, the determining factor if you need one is a completely separate issue from simply needing more space. If you've been coding directly to the metal it may actually make your life easier not having an MMU. I'd also like to note that an MMU is virtually never an external component but rather on the SoC die.
You can find ARM SoCs in many families that allow external memory from the ARM7 on up for example the NXP LPC2212 Series not saying its the best, just the first ARM7 SoC that came up in google with an external memory interface, there are lots of options.
I'd pay more attention to the features of the various cores in the ARM families as you can find almost all of them in SoC's with external memory controllers.
Now as to what type of memory you need and how to get it working, that depends on the SoC you choose and what memory the external memory controller supports. For instance the ARM7 SoC i linked supports external SRAM as well as flash's and roms and supports up to 4 16MB banks, so you could hook external flash and SRAM to it at the same time.
You could use separate RAM and flash IC's there are also packages called MCP (Multi Chip Package) that can include both flash and ram in 1 package. How you choose these devices depends on many factors, you'd need to be more specific about your application.
How easy this is to hook up depends on the speed you need. Most external memory controller have programmable clock rates. The memory interface clock rates could be very high at least 10MHz and likely much higher. In short your very likely not breadboarding something like this, you need to design a PCB and pay special attention to signal integrity issues for these lines.
Your best bet is to pick a core you want to play with and a find one of the many development boards out there with external memory on it.
The problem with using a microcontroller to drive an LCD is that an LCD requires constant attention. This can be mitigated with a CPLD driven over SPI (using DMA, of course), but then you run into the other problem: Color LCDs require a lot of data. 320x240 in black and white is marginal at 9.6KB, but make it 24 bit color and suddenly you need to deliver 230KB of data in 1/60th of a second. (Don't forget, though, that you can get 4-bit, 16-color control just by tieing the low 20 bits to one setting). A 24-bit frame buffer no longer fits in onboard RAM on most microcontrollers, and you probably don't have time to read from an external RAM chip, clock the data out, and still do other processing. Trying to do this with a CPLD (or an FPGA) and a RAM chip gets you well over the $2 price that caused you to balk in your question.
The traditional solution to interfacing a microcontroller with a color LCD is a display controller like an SSD1963. Here's a very simple block diagram:
Parallel input to a big RAM frame buffer (Translation: More than $2) interfaced with a register-configurable parallel LCD interface. The parallel input is usually compatible with a memory bus interface.
The color LCD market is not always easy to find on the web, usually being the domain of OEMs only, with the rest buying displays from companies who integrate the controller with the display. The best resource I've found has been Crystal Fontz, specifically this page on choosing graphic LCDs. Scroll to the bottom for the controllers, which include the following options (note: Not all are color controllers):
- Epson S1D13521B01 E Ink Broadsheet (1 module)
- Epson S1D13700 (11 modules)
- Epson SED1520 Compatible (8 modules)
- Himax HX8345 Compatible (1 module)
- ILITek ILI9325 Compatible (3 modules)
- KS0107/KS0108 Compatible (26 modules)
- Novatek NT7534 (14 modules)
- Orise Technology OTM2201A (1 module)
- Orise Technology SPFD5420A (1 module)
- RAiO RA8835 (1 module)
- Sanyo LC7981 (13 modules)
- Sino Wealth SH1101A (2 modules)
- Sitronix ST7920 (29 modules)
- Solomon SSD1303 (1 module)
- Solomon SSD1305 (9 modules)
- Solomon SSD1325 (2 modules)
- Solomon SSD1332 (1 module)
- Solomon SSD2119 (2 modules)
- ST STV8105 (1 module)
- Toshiba T6963 (23 modules)
Related Topic
- Electronic – Cycle counting with modern CPUs (e.g. ARM)
- Electronic – How to add memory to an ARM Cortex Microcontroller
- Olimex ARM-USB-OCD-H with LPC-P1114 and LPC-P1227 boards questions
- Electronic – Selecting external RAM for an ARM static memory controller
- Electronic – NVIC memory map ARM cortex M3 STM32f103
Best Answer
Assuming you get no error return from the calloc/malloc, the odds are about 9999 to one on that you have a bug, either due to misuse of malloc, misuse of the space so allocated, incorrect memory sections/placement or just because the fixed and malloced buffers will have different addresses.