Getting started with AVR MCU + using keil-MDK to run TQ2440

I haven't updated my blog for two or three months. In the past two months, I have been learning AVR microcontrollers. The complexity of the chip has increased a lot. I read the 300-page data sheet three times before I had a general understanding. Next, I have to do experiments to familiarize myself with each module. I found an excellent introductory book "Microcontroller C Language Programming Training-Based on AVR PROTEUS Simulation" by Teacher Ma Chao. So far, the only basic exercises I have not done are the communication between the host and the slave and the watchdog experiment. Unfortunately, the overall difficulty of the "homework" assigned by this book is not high. Some of the homework that I can think of the solution at a glance did not do, and I did not miss any of the homework that I thought I didn't know how to do.

Every time you start learning a new type of microcontroller, you need to do the following:

1) Choose the right microcontroller chip

2) Choose a suitable development environment

3) Choose the right burning tool

4) Learn to write naked programs to familiarize yourself with the resources on the microcontroller chip

Only in this way can we start application-level development. Based on the needs of game development, I chose atmega1284P and AVR Studio 4 as the development environment. The fifth generation was troublesome to install and could not work with the winAVR compiler, which resulted in the _delay_us(variable) method failing to compile. Only constants could be used as delay parameters. This bug was too annoying, so I had no choice but to switch to the fourth generation + winAVR. I have used IAR in other development environments on the Internet, and I prefer the interface provided by gcc in comparison, so I finally decided to use AVR Studio 4. There is no need to burn, because all simulations are done using proteus. The way of experimentation afterwards was similar to that on 51, which was to experiment with each on-chip resource one by one.

Another month has passed. I have completed the experiment of LCD controller T6963C. A serious problem has emerged: the efficiency of drawing pixels and geometric figures based on the graphic LCD with one pixel occupying 1 bit is extremely low. The reading and writing data are at least 8 bits, that is, in bytes. In this way, if you want to write a pixel, you need

1) Read the byte where the pixel is located

2) Change the corresponding bit

3) Write back to video memory

The result of drawing pixels in this way is that the physical particle effect I hope for cannot be achieved. Maybe this inefficient method can also achieve particle effects, but I didn't try it. Look at the early games like "Tetris" and "Push Box", which are not smooth. In this way, unnecessary bit operations can be avoided and the operation granularity can be enlarged to bytes. Even for games like "Snake" that seem to move smoothly, its frame rate is much lower than that of ordinary games, so inefficient pixel operations can be tolerated. What I want to do is a game based on sprite animation, which requires smooth movement of an image. If a 1-bit pixel LCD does not have a bit-level block copy, it will be extremely troublesome to implement. The only way I can think of is to use an LCD with a serial interface, so that bits can be added before and after the data to achieve data translation.

On the other hand, there are AVR microcontrollers with TFT displays for sale online, so my other option is to buy an AVR development board and continue my experiments on it. I already have an ARM7 board and an ARM9 board with a touch screen. After careful consideration, I decided to upgrade to the ARM platform. I bought the ARM9 board three years ago, so I should be able to handle it now. 

There was no choice for the CPU, which was S3C2440. I knew that I couldn't choose the outdated ADS as the development environment. The extremely unfriendly compilation error message was simply frustrating. I searched and found that I could use keil, which was great. I downloaded the MDK4.5 evaluation version from the ARM official website, and burned it with the J-link that I bought at the same time as the board. After debugging, it worked normally. But the last step of "running naked" took me several days. The methods on the Internet had some problems. The root cause was that ARM's startup Flash has two types, Nor and Nand, and there are also two startup methods. So I referred to a lot of information on the Internet and learned and understood the startup process before I finally made the LED light up correctly. Due to the limitation of the number of flash writes, the ideal way to run naked is to download it directly to RAM to run the program. The hard work of several days was not in vain.

Keil-MDK naked TQ2440 key points:

I. Understanding of the startup process. 

The bare-bones booting of 51 MCU and AVR MCU is very simple, just download the compiled hex file to the MCU, so there is no complicated address configuration. ARM is different, you can boot from Nor flash memory or Nand flash memory.

The following picture is taken from the S3C2440A datasheet.

1) The left picture may be the boot memory map of the Nor flash memory, which should be replaced by other roms, such as eeprom. This mode is no different from 51 and AVR, and is suitable for naked applications. Nor flash memory can be accessed in byte granularity like RAM, so the program in Nor flash memory is executed as if in RAM, and you can also choose to move the program to real RAM and execute it.

2) The figure on the right is the boot memory map of Nand flash memory, which is suitable for booting large programs with operating systems. The access to Nand flash memory is similar to the hard disk on a computer. It is a block device and the boot method is similar. First, the boot program at the beginning of the Nand flash memory is moved to the static memory (SRAM) inside the ARM. The role of the boot program is to load the larger boot program into the real RAM and then jump to it for execution.

II. Create and write a streaking program.

1) When creating, select s3c2440 as the cpu, and let MDK automatically generate the *.s startup code. There is a great document on the Internet about porting a bare-bones program from ADS without using the MDK startup code. There are many things to modify, but I just want a bare-bones program that lights up the LED. With my experience with 51 and AVR, I intuitively think that it should not require very complicated configuration.

2) *.s files can be configured visually in MDK, which is more user-friendly.

 The main configuration is the size of the RAM memory. My TQ2440 is 64M. There is also the port where the LED is connected. The following figure is the circuit diagram of the core board:

You can see the Led is connected to the GPB port.

3) Writing the main program. This is relatively simple.

III. Target option configuration (Project->Option for Target)

Target, Linker, Debug, and Utilities need to be configured. I started the configuration according to Nand, and you can figure out the configuration for Nor yourself.

Note: After trying, I found that in fact, only one DebugInRAM_config.ini configuration file is needed to run the program. The important part is SetupForStart(). The PC value should be set at the beginning of RAM. My PC value is 0x30000000 at the beginning of BANK6. It seems that J-link directly loads the program to the beginning of the external memory. This may be related to the configuration of Init(). If you want to debug, you must fill in all the information.