Raspberry Pi Camera Module Review – Eye Pi by Gareth Halfacree 2013jul19
http://www.linuxuser.co.uk/reviews/raspberry-pi-camera-module
Does the Raspberry Pi’s first official accessory live up to its high-resolution hype, or is its outlook blurred?
Technical Specs
Sensor: Omnivision 5647, five megapixel
Lens: 3.6mm F/2.0 fixed-focus
Dimensions: 21.6mm x 25mm x 8.65mm (excluding cable)
Weight: 3g (excluding cable)
Cable Length: 150mm (15-core 1mm pitch ribbon cable)
Connection: Camera Serial Interconnect (CSI)
Maximum Still Resolution: 2,592×1,944 (currently limited to 1,920×1,080)
Maximum Video Resolution: 1,920×1,080 (1080p) 30fps
The Omnivision five megapixel sensor is found behind a fixed-focus 3.6mm lens, but you can adjust the focus with a little hacking
The Camera Module is the first piece of add-on hardware to come out of the Raspberry Pi Foundation itself – and it addresses a real need in the Pi community. Many users are looking to use the Pi for computer vision projects ranging from near-space balloon launches – in which the Pi provides a live stream of its journey while storing higher-resolution snapshots for when it returns to the ground – to burglar alarms and home automation systems.
The official Camera Module dodges issues encountered using webcams on a Pi – thanks to its esoteric USB implementation – in a couple of clever ways. First, it bypasses the USB part of the Pi altogether by connecting to the previously-unused Camera Serial Interface (CSI) located near the USB socket. Second, it taps into the graphics processing unit (GPU) of the Broadcom BCM2835 chip that powers the Pi – giving it vastly more computational power than devices that use the Pi’s relatively weedy CPU.
The result is a camera that draws surprisingly little power, weighs just 3g, has the footprint of a postage stamp and yet is capable of capturing five megapixel still images and 1080p high-definition video at thirty frames per second. Better still, it does all this for less than £20. Granted, that’s around the same as you’d pay for a Raspberry Pi Model A to which the camera can be connected – but given its capabilities, it’s still a bargain.
The Camera Module arrives, in traditional Foundation fashion, as a bare circuit board with a small, 15cm ribbon cable as the only accessory. Gently inserted into the CSI port on the top of the Pi, the camera is ready to go – once you’ve updated your Raspbian installation. Those who have chosen alternative operating systems for their Pi are, at this point, left out in the cold: currently, it’s Raspbian or nothing.
Even fully updated, the software to drive the camera is in a very early stage. Many functions – such as the ability to record EXIF tags into image files – simply don’t work. Other features work incorrectly: attempting to capture any image above 1,920×1,080, for example, makes the camera take a Full HD cropped image and then resize it rather than capturing the full frame of the sensor – a problem the Foundation’s development team is working to resolve.
Another issue, less likely to be fixed any time soon, comes in how the camera is driven. While webcams are supported on the Pi through Video4Linux, allowing them to interact with various third-party software packages, there’s no such driver for the official camera module. As a result, the only way to drive it is to use two command-line packages – raspistill and raspivid – the source code for which is available.
The software is easily the worst part of the camera, but it’s also the part that will change most rapidly. Even between the writing of this review and its publication, the Foundation has likely fixed several of the bugs mentioned here – and will continue to improve the software.
When used within the constraints of the software, the camera certainly delivers: still images are crisp, providing they don’t hit the Full HD crop limit, and video is impressive – although prone to banding if your power supply isn’t up to scratch. The fixed-focus lens is a slight drawback, with objects any closer than two to three metres appearing blurred – but if you’re willing to hack the camera apart, you can remove the glue from the lens and adjust the focus manually with a twist.
Verdict
4/5
There’s no denying that the Raspberry Pi Camera Module is a bargain, despite costing nearly as much as the Model A itself. The software needs serious work and the lack of Video4Linux support is disappointing, but its small size and high-resolution sensor will likely find it a home in many imaging-related projects.
.END
Friday 19 July 2013
Sunday 7 July 2013
Keil uVision LPC111xx startup files etc
Description of the LPC11xx Example Software Package, NXP Semiconductor
https://github.com/Mrjohns42/RSL/tree/master/lpc11xx.keil-examples-CMSIS-update_2/lpc11xx.keil-examples-CMSIS-update
...
The Description of the Example software
This example demonstrates the use of build-in peripherals on the NXP
LPC11xx family microcontrollers.
The Example software includes, common library, peripheral APIs, and test modules
for the APIs.
The common library include startup file, standard definition and
header files, processor specific setup module, generic interrupt related APIs,
timer routine.
The peripheral directories include, ADC, GPIO, timer, SPI, I2C,
Watchdog timer, UART, external interrupt, various USB class drivers ,etc.
Depending on the configuration of LPC11xx, it may include a CAN controller
or a USB Device controller, or none of them. The header file of register
definition, LPC11xx.h, the clock configuration, and the NVIC APIs, includes
both CAN and USB, but may not apply to the MCU you are using.
The development environment is Keil's, an ARM company now, uVision MDK 3.85
or later, and ULINK2 ICE. The target boards is NXP Internal Eval board with
LPC11xx MCU on it.
Please note that, the latest Keil MDK may or may not include the startup file,
the header files, and Cortex related API files for NVIC and Systick driver. These
files are also included in our common library. If the users wish not to use Keil
MDK, the compiler needs to:
(1) set up the include path to COMMON/INC
(2) change #include <lpc11xx.h> to "#include "lpc11xx.h" where is located
under COMMON/INC directory.
(3) Add "core_cm0.c" from COMMON/SRC into your own project.
The project is created for both target option "FLASH(Release)" and "RAM(Debug)".
For "FLASH", the image code can be programmed into the flash and executed;
for "RAM", the image code can be loaded into internal SRAM(IRAM)
for easy debugging. The "RAM.ini" in each directory is a Keil uVision debugger
script file, once the debugger starts, the code will be loaded to the IRAM
first, then, "RAM.ini" will be executed and reset program counter(PC) to
0x10000000(IRAM starting address) that code will be executed from.
For Flash Update, a FLM file for Keil MDK built-n flash utility is included if
the revision of Keil MDK you have doesn't support LPC11xx yet. If the LPC11xx
is not listed in the Keil MDK Device Database, choose "Cortex M0" as shown in
our example project file, then, copy the file "LPC_IAP_CD0_32.FLM" from Sample Code
Bundle Root directory to "C:\Keil\ARM\Flash". Now, you go to "Options/Utilities/Flash
Programming Setting", add "LPC114x IAP 32kB Flash" from a list of flash algorithm,
and use the Keil Built-in flash utility to program the flash.
Some external components, such as I2C temperature, SPI serial EEPROM, will be
required to add on the board in order to complete the test below.
Known problems:
(1) Keil MDK configuration Wizard has not been tested for Clock configuration.
(2) When using Flash download, at the end of the flash update, GUI shows
"Error: Flash download failed, Cortex M0". although, the flash has been updated
correctly. So, this message should be ignored. It depends on the revision of the
Keil MDK you use. For MDK with LPC11xx support, this shouldn't be an issue.
The directory tree and content of the sample software
common
-- inc
-- lpc11xx.h CMSIS Cortex-M0 Core Peripheral Access Layer Header
File for NXP LPC11xx Device Series
-- core_cm0.h CMSIS Cortex-M0 Core Peripheral Access Layer Header
File
-- system_LPC11xx.h CMSIS Cortex-M0 Device Peripheral Access Layer
Header File for the NXP LPC11xx Device Series
-- type.h Type definition Header file for NXP LPC11xx Family
-- systick.h Cortex M0 Systemtick header and definition
-- gpio.h GPIO setting and I/O pin connfigured as external
interrupt definition
-- uart.h UART setting header and definiton
-- timer16.h 16-bit TIMER setting header and definition
-- timer32.h 32-bit TIMER setting header and definition
-- clkconfig.h clock configuration header and definition
-- src
-- core_cm0.c CMSIS Cortex-M0 Core Peripheral Access Layer Source
File
-- startup_LPC11xx.s CMSIS Cortex-M0 Core Device Startup File
for the NXP LPC11xx Device Series
-- system_LPC11xx.c CMSIS Cortex-M0 Device Peripheral Access Layer
Source File for the NXP LPC11xx Device Series
-- gpio.c GPIO setting APIs and I/O pin connfigured as
external interrupt and interrupt handler
-- uart.c UART setting API and interrupt handler
-- timer16.c 16-bit TIMER setting APIs and interrupt handler
-- timer32.c 32-bit TIMER setting APIs and interrupt handler
-- clkconfig.c Misc. clock configuration setting and APIs in
addition to system_lpc11xx.c
Blinky
-- blinky.c General test, GPIO, Timer and NVIC test module,
note:
API modules are in the COMMON directory and
shared and used by some other peripheral testing.
-- blinky.uvproj uVision 4.x project file
ADC
-- adc.h ADC header
-- adc.c ADC APIs
-- adctest.c ADC controller test module
-- adc.uvproj uVision 4.x project file
GPIO
-- gpiotest.c External interrupt test module, APIs are
from COMMON directory
-- gpio.uvproj uVision 4.x project file
Systick
-- systick.c ARM Cortext M0 Core system tick test module, APIs
are from COMMON directory
-- systick.uvproj uVision 4.x project file
I2C
-- i2c.h I2C header
-- i2c.c I2C APIs
-- i2ctest.c I2C test module
-- i2ctest.uvproj uVision 4.x project file
I2CSlave
-- i2cslave.h I2C slave header
-- i2cslave.c I2C slave APIs
-- i2cslvtst.c I2C slave test module
-- i2cslave.uvproj uVision 4.x project file
Timer32
-- timer32test.c 32-bit Timer test module, note: API modules
are in the COMMON directory and
shared and used by some other peripheral testing.
-- timer32.uvproj uVision 4.x project file
PWM
-- pwmtest.c PWM test module, note: PWM API modules
are in the COMMON directory, shared and used
by some other peripheral testing.
-- pwm.uvproj uVision 4.x project file
UART
-- uarttest.c UART test module, note: UART API modules
are in the COMMON directory, shared and used
by some other peripheral testing.
-- uart.uvproj uVision 4.x project file
RS485
-- rs485.h RS485 header
-- rs485.c RS485 APIs
-- rs485test.c RS485 test module
-- rs485.uvproj uVision 4.x project file
WDT
-- wdt.h Watchdog timer header
-- wdt.c Watchdog timer APIs
-- wdttest.c Watchdog timer test module
-- wdt.uvproj uVision 4.x project file
CAN
-- can.h CAN header
-- can.c CAN APIs
-- cantest.c CAN test module
-- can.uvproj uVision 4.x project file
CAN on_chip
-- rom_driver_CAN.h CAN on-chip API function header
-- rom_drivers.h ROM drivers header
-- main.c CAN on-chip test module
-- CAN on_chip.uvproj uVision 4.x project file
CANopen on_chip
-- rom_driver_CAN.h CAN on-chip API function header
-- rom_drivers.h ROM drivers header
-- main.c CAN on-chip test module
-- CANopen on_chip.uvproj uVision 4.x proje
.END
https://github.com/Mrjohns42/RSL/tree/master/lpc11xx.keil-examples-CMSIS-update_2/lpc11xx.keil-examples-CMSIS-update
...
The Description of the Example software
This example demonstrates the use of build-in peripherals on the NXP
LPC11xx family microcontrollers.
The Example software includes, common library, peripheral APIs, and test modules
for the APIs.
The common library include startup file, standard definition and
header files, processor specific setup module, generic interrupt related APIs,
timer routine.
The peripheral directories include, ADC, GPIO, timer, SPI, I2C,
Watchdog timer, UART, external interrupt, various USB class drivers ,etc.
Depending on the configuration of LPC11xx, it may include a CAN controller
or a USB Device controller, or none of them. The header file of register
definition, LPC11xx.h, the clock configuration, and the NVIC APIs, includes
both CAN and USB, but may not apply to the MCU you are using.
The development environment is Keil's, an ARM company now, uVision MDK 3.85
or later, and ULINK2 ICE. The target boards is NXP Internal Eval board with
LPC11xx MCU on it.
Please note that, the latest Keil MDK may or may not include the startup file,
the header files, and Cortex related API files for NVIC and Systick driver. These
files are also included in our common library. If the users wish not to use Keil
MDK, the compiler needs to:
(1) set up the include path to COMMON/INC
(2) change #include <lpc11xx.h> to "#include "lpc11xx.h" where is located
under COMMON/INC directory.
(3) Add "core_cm0.c" from COMMON/SRC into your own project.
The project is created for both target option "FLASH(Release)" and "RAM(Debug)".
For "FLASH", the image code can be programmed into the flash and executed;
for "RAM", the image code can be loaded into internal SRAM(IRAM)
for easy debugging. The "RAM.ini" in each directory is a Keil uVision debugger
script file, once the debugger starts, the code will be loaded to the IRAM
first, then, "RAM.ini" will be executed and reset program counter(PC) to
0x10000000(IRAM starting address) that code will be executed from.
For Flash Update, a FLM file for Keil MDK built-n flash utility is included if
the revision of Keil MDK you have doesn't support LPC11xx yet. If the LPC11xx
is not listed in the Keil MDK Device Database, choose "Cortex M0" as shown in
our example project file, then, copy the file "LPC_IAP_CD0_32.FLM" from Sample Code
Bundle Root directory to "C:\Keil\ARM\Flash". Now, you go to "Options/Utilities/Flash
Programming Setting", add "LPC114x IAP 32kB Flash" from a list of flash algorithm,
and use the Keil Built-in flash utility to program the flash.
Some external components, such as I2C temperature, SPI serial EEPROM, will be
required to add on the board in order to complete the test below.
Known problems:
(1) Keil MDK configuration Wizard has not been tested for Clock configuration.
(2) When using Flash download, at the end of the flash update, GUI shows
"Error: Flash download failed, Cortex M0". although, the flash has been updated
correctly. So, this message should be ignored. It depends on the revision of the
Keil MDK you use. For MDK with LPC11xx support, this shouldn't be an issue.
The directory tree and content of the sample software
common
-- inc
-- lpc11xx.h CMSIS Cortex-M0 Core Peripheral Access Layer Header
File for NXP LPC11xx Device Series
-- core_cm0.h CMSIS Cortex-M0 Core Peripheral Access Layer Header
File
-- system_LPC11xx.h CMSIS Cortex-M0 Device Peripheral Access Layer
Header File for the NXP LPC11xx Device Series
-- type.h Type definition Header file for NXP LPC11xx Family
-- systick.h Cortex M0 Systemtick header and definition
-- gpio.h GPIO setting and I/O pin connfigured as external
interrupt definition
-- uart.h UART setting header and definiton
-- timer16.h 16-bit TIMER setting header and definition
-- timer32.h 32-bit TIMER setting header and definition
-- clkconfig.h clock configuration header and definition
-- src
-- core_cm0.c CMSIS Cortex-M0 Core Peripheral Access Layer Source
File
-- startup_LPC11xx.s CMSIS Cortex-M0 Core Device Startup File
for the NXP LPC11xx Device Series
-- system_LPC11xx.c CMSIS Cortex-M0 Device Peripheral Access Layer
Source File for the NXP LPC11xx Device Series
-- gpio.c GPIO setting APIs and I/O pin connfigured as
external interrupt and interrupt handler
-- uart.c UART setting API and interrupt handler
-- timer16.c 16-bit TIMER setting APIs and interrupt handler
-- timer32.c 32-bit TIMER setting APIs and interrupt handler
-- clkconfig.c Misc. clock configuration setting and APIs in
addition to system_lpc11xx.c
Blinky
-- blinky.c General test, GPIO, Timer and NVIC test module,
note:
API modules are in the COMMON directory and
shared and used by some other peripheral testing.
-- blinky.uvproj uVision 4.x project file
ADC
-- adc.h ADC header
-- adc.c ADC APIs
-- adctest.c ADC controller test module
-- adc.uvproj uVision 4.x project file
GPIO
-- gpiotest.c External interrupt test module, APIs are
from COMMON directory
-- gpio.uvproj uVision 4.x project file
Systick
-- systick.c ARM Cortext M0 Core system tick test module, APIs
are from COMMON directory
-- systick.uvproj uVision 4.x project file
I2C
-- i2c.h I2C header
-- i2c.c I2C APIs
-- i2ctest.c I2C test module
-- i2ctest.uvproj uVision 4.x project file
I2CSlave
-- i2cslave.h I2C slave header
-- i2cslave.c I2C slave APIs
-- i2cslvtst.c I2C slave test module
-- i2cslave.uvproj uVision 4.x project file
Timer32
-- timer32test.c 32-bit Timer test module, note: API modules
are in the COMMON directory and
shared and used by some other peripheral testing.
-- timer32.uvproj uVision 4.x project file
PWM
-- pwmtest.c PWM test module, note: PWM API modules
are in the COMMON directory, shared and used
by some other peripheral testing.
-- pwm.uvproj uVision 4.x project file
UART
-- uarttest.c UART test module, note: UART API modules
are in the COMMON directory, shared and used
by some other peripheral testing.
-- uart.uvproj uVision 4.x project file
RS485
-- rs485.h RS485 header
-- rs485.c RS485 APIs
-- rs485test.c RS485 test module
-- rs485.uvproj uVision 4.x project file
WDT
-- wdt.h Watchdog timer header
-- wdt.c Watchdog timer APIs
-- wdttest.c Watchdog timer test module
-- wdt.uvproj uVision 4.x project file
CAN
-- can.h CAN header
-- can.c CAN APIs
-- cantest.c CAN test module
-- can.uvproj uVision 4.x project file
CAN on_chip
-- rom_driver_CAN.h CAN on-chip API function header
-- rom_drivers.h ROM drivers header
-- main.c CAN on-chip test module
-- CAN on_chip.uvproj uVision 4.x project file
CANopen on_chip
-- rom_driver_CAN.h CAN on-chip API function header
-- rom_drivers.h ROM drivers header
-- main.c CAN on-chip test module
-- CANopen on_chip.uvproj uVision 4.x proje
.END
Keil uVision Tutorials notes
Lab 1: A “Blinky” Introduction to C and Assembly Programming EE-379 Embedded Systems with Applications, Electrical Engineering Department, University at Buffalo Last update: Cristinel Ababei, January 2013
http://www.dejazzer.com/ee379/labs/lab1_blink.pdf
Getting Started with Keil uVision NILAY BANKER NOVEMBER - 4 - 2012
http://www.circuitstoday.com/getting-started-with-keil-uvision
How To Use keil uVision 4 IDE - Project Setup, Debug And Simulation
http://tentuts.meritox.com/2012/05/how-to-use-keil-uvision-4-ide-project.html
Keil MDK-ARM uVision Setup for STM32F4-DiscoveryBoard
http://www.eng.auburn.edu/~nelson/courses/elec5260_6260/Keil%20Setup%20for%20STM32F4-Discovery.pdf
uVision4 articles - SharaBooks
http://www.sharabooks.com/keil-uvision-4.html
Lab 1: A “Blinky” Introduction to C and Assembly Programming EE-379 Embedded Systems with Applications Electrical Engineering Department, University at Buffalo
Last update: Cristinel Ababei, January 2013
1. Objective
The objective of this lab is to give you a “first foot in the door” exposure to the programming in C and
assembly of a program, which when executed by the microcontroller (NXP LPC1768, an ARM Cortex-M3)
simply blinks LEDs located on the development board. You also learn how to use the ARM Keil uVision
IDE to create projects, build and download them to the board (either Keil MCB1700 or Embest EMLPC1700).
2. Pre-lab Preparation
Optional (but encouraged)
You should plan to work on your own computer at home a lot during this semester. You should install the
main software (evaluation version) we will use in this course: the Microcontroller Development Kit (MDKARM), which supports software development for and debugging of ARM7, ARM9, Cortex-M, and Cortex-R4
processor-based devices. Download it from ARM’s website [1] and install it on your own computer. This is
already installed on the computers in the lab.
MDK combines the ARM RealView compilation tools with the Keil µVision Integrated Development
Environment (IDE). The Keil µVision IDE includes: Project Management and Device & Tool
Configuration, Source Code Editor Optimized for Embedded Systems, Target Debugging and Flash
Programming, Accurate Device Simulation (CPU and Peripheral).
You should read this lab entirely before attending your lab session. Equally important, you should/browse
related documents suggested throughout the description of this lab. These documents and pointers are
included either in the downloadable archive for this lab or in the list of References. Please allocate
significant amount of time for doing this.
.END
http://www.dejazzer.com/ee379/labs/lab1_blink.pdf
Getting Started with Keil uVision NILAY BANKER NOVEMBER - 4 - 2012
http://www.circuitstoday.com/getting-started-with-keil-uvision
How To Use keil uVision 4 IDE - Project Setup, Debug And Simulation
http://tentuts.meritox.com/2012/05/how-to-use-keil-uvision-4-ide-project.html
Keil MDK-ARM uVision Setup for STM32F4-DiscoveryBoard
http://www.eng.auburn.edu/~nelson/courses/elec5260_6260/Keil%20Setup%20for%20STM32F4-Discovery.pdf
uVision4 articles - SharaBooks
http://www.sharabooks.com/keil-uvision-4.html
Lab 1: A “Blinky” Introduction to C and Assembly Programming EE-379 Embedded Systems with Applications Electrical Engineering Department, University at Buffalo
Last update: Cristinel Ababei, January 2013
1. Objective
The objective of this lab is to give you a “first foot in the door” exposure to the programming in C and
assembly of a program, which when executed by the microcontroller (NXP LPC1768, an ARM Cortex-M3)
simply blinks LEDs located on the development board. You also learn how to use the ARM Keil uVision
IDE to create projects, build and download them to the board (either Keil MCB1700 or Embest EMLPC1700).
2. Pre-lab Preparation
Optional (but encouraged)
You should plan to work on your own computer at home a lot during this semester. You should install the
main software (evaluation version) we will use in this course: the Microcontroller Development Kit (MDKARM), which supports software development for and debugging of ARM7, ARM9, Cortex-M, and Cortex-R4
processor-based devices. Download it from ARM’s website [1] and install it on your own computer. This is
already installed on the computers in the lab.
MDK combines the ARM RealView compilation tools with the Keil µVision Integrated Development
Environment (IDE). The Keil µVision IDE includes: Project Management and Device & Tool
Configuration, Source Code Editor Optimized for Embedded Systems, Target Debugging and Flash
Programming, Accurate Device Simulation (CPU and Peripheral).
You should read this lab entirely before attending your lab session. Equally important, you should/browse
related documents suggested throughout the description of this lab. These documents and pointers are
included either in the downloadable archive for this lab or in the list of References. Please allocate
significant amount of time for doing this.
.END
Creating a new Keil project learning notes
Porting Your Code to the uVision Environment by: Chris Brown, Freescale
http://cache.freescale.com/files/32bit/doc/app_note/AN4552.pdf
4 Creating a new Keil project from the Kinetis Sample Code
Currently, no Keil projects exist in the Kinetis sample code package. Therefore, you will need to create a folder, named Keil, under the KINETIS512_SC\build folder. Next, you will need to create subfolders for your projects (the location for these folders will be KINETIS512_SC\build\Keil\<project name>).
After you have manually created your new project folder(s) in the location specified above, follow the step by step instructions to create your new uVision project.
1. Navigate to Project->New uVision Project….
2. Point the dialog box to the project folder you just created and save your new project there.
3. Select the appropriate Freescale MCU from the Generic CPU database (MK60N512VMD100 for this example). Do not be concerned that you can only select one part. There will be a chance to add other parts (or change the current part) later.
When prompted to copy the recommended startup_<device>.s file to the Project Folder and add the file to the project, click no. We will add our own *.s file to the project later.
4.1 Creating new targets and groups
Now you must add the project files to your project. But first, correctly setup the groups to organize your workspace. Follow these instructions to setup the workspace.
1. Click the Files, Extensions, Books, and Environments… dialog button.
2. A dialog box opens. Here you can add or modify targets and groups, as well as add or remove files to or from the groups. For convenience and organization, rename Target 1 to MK60N512 – Flash. Do this by double-clicking Target 1. Double-Click
3. Rename Source Group 1 to Project, the same way that Target 1 was renamed. Before adding files to the groups, add all of the appropriate groups. The groups added are as follows:
• common
• drivers
• cpu
• platforms
4. Create a new project target (named MK60N512 – RAM) by clicking the “New (Insert)” button and name the newly created target appropriately. After the new target is created, it is necessary to perform the target setup actions described in Memory configuration for a RAM target for this target.
5. Click Ok to exit the Components, Environment and Books dialog box.
4.4 Adding files and include paths
Now that the groups are correctly setup, add the appropriate files to the groups.
Follow these instructions:
1. Right click on the group folder icon (listed in the group column of Table 1 below) in the Project pane and click the Add Files to Group '<folder name'... button.
2. Then browse to the appropriate folder in the Add Files to Group dialog box, select the files in that folder, and click the Add button.
NOTE
By default, uVision is set to find only source files, and finds header files automatically. Therefore, you will not need to add the header files, though you may want to add some header files manually if the file is modified often.
The following table lists all of the files that are located in the sample project folder structure. Not
all of these files will be used for every project and it is recommended that only necessary files be added to a project (the unnecessary files for the hello_world example are in italics in the table).
...
.END
http://cache.freescale.com/files/32bit/doc/app_note/AN4552.pdf
4 Creating a new Keil project from the Kinetis Sample Code
Currently, no Keil projects exist in the Kinetis sample code package. Therefore, you will need to create a folder, named Keil, under the KINETIS512_SC\build folder. Next, you will need to create subfolders for your projects (the location for these folders will be KINETIS512_SC\build\Keil\<project name>).
After you have manually created your new project folder(s) in the location specified above, follow the step by step instructions to create your new uVision project.
1. Navigate to Project->New uVision Project….
2. Point the dialog box to the project folder you just created and save your new project there.
3. Select the appropriate Freescale MCU from the Generic CPU database (MK60N512VMD100 for this example). Do not be concerned that you can only select one part. There will be a chance to add other parts (or change the current part) later.
When prompted to copy the recommended startup_<device>.s file to the Project Folder and add the file to the project, click no. We will add our own *.s file to the project later.
4.1 Creating new targets and groups
Now you must add the project files to your project. But first, correctly setup the groups to organize your workspace. Follow these instructions to setup the workspace.
1. Click the Files, Extensions, Books, and Environments… dialog button.
2. A dialog box opens. Here you can add or modify targets and groups, as well as add or remove files to or from the groups. For convenience and organization, rename Target 1 to MK60N512 – Flash. Do this by double-clicking Target 1. Double-Click
3. Rename Source Group 1 to Project, the same way that Target 1 was renamed. Before adding files to the groups, add all of the appropriate groups. The groups added are as follows:
• common
• drivers
• cpu
• platforms
4. Create a new project target (named MK60N512 – RAM) by clicking the “New (Insert)” button and name the newly created target appropriately. After the new target is created, it is necessary to perform the target setup actions described in Memory configuration for a RAM target for this target.
5. Click Ok to exit the Components, Environment and Books dialog box.
4.4 Adding files and include paths
Now that the groups are correctly setup, add the appropriate files to the groups.
Follow these instructions:
1. Right click on the group folder icon (listed in the group column of Table 1 below) in the Project pane and click the Add Files to Group '<folder name'... button.
2. Then browse to the appropriate folder in the Add Files to Group dialog box, select the files in that folder, and click the Add button.
NOTE
By default, uVision is set to find only source files, and finds header files automatically. Therefore, you will not need to add the header files, though you may want to add some header files manually if the file is modified often.
The following table lists all of the files that are located in the sample project folder structure. Not
all of these files will be used for every project and it is recommended that only necessary files be added to a project (the unnecessary files for the hello_world example are in italics in the table).
...
.END
CMSIS-SVD learning notes
System View Description
This chapter contains the introduction and specification of the CMSIS System View Description format (CMSIS-SVD). The introduction section outlines the objectives and benefits CMSIS-SVD.
Introduction
CMSIS-SVD formalizes the description of the programmer's view for the system contained in ARM Cortex-M processor-based microcontrollers, in particular the memory mapped registers of the peripherals. The detail contained in system view descriptions is comparable to what is found in device reference manuals published by silicon vendors.
The information ranges from a high level functional description of a peripheral all the way down to the definition and purpose of an individual bit field in a memory mapped register.
CMSIS-SVD files are developed and maintained by the silicon vendors. Silicon vendors manage their descriptions in a central, web-based Device Database and the CMSIS-SVD files are downloadable via a public web interface once they have been released by the silicon vendor. Tool vendors use these descriptions for providing device-specific debug views of peripherals in their debugger. Last but not least CMSIS compliant device header files are generated from CMSIS-SVD files.
CMSIS-SVD Benefits
The benefits for the Software Developer:
Consistency between device header file and what is being displayed by the debugger.
Detailed information about peripherals, registers, fields, and bit values from within the debugger, without the need to reference device documentation.
Public access via a web interface to new and updated descriptions as they become available from silicon vendors.
Improved software development efficiency.
The benefits for the Silicon Vendor:
A tool vendor independent file format enables early device support by a wide range of toolchains with limited effort.
The XML-based format helps ease the integration into in-house design flows.
Automated generation of CMSIS compliant device header files.
Full control throughout the life cycle of the CMSIS-SVD files from creation to maintenance via the web-based Device Database.
The benefits for the Tool Vendor:
Unified file format across silicon vendors helps the efficiency of supporting a wide range of new devices in a timely manner.
Silicon vendors provide early review access to individuals ahead of the publishing date.
Updated descriptions are available over the web simplifying the maintenance of device support.
SVD File Description
The CMSIS-SVD format is based on XML. The specification of the System View Description format was influenced by IP-XACT, a design description format used in, for example, IP stitching and IP reuse. Due to the much wider scope and complexity of IP-XACT it was decided to specify a separate format, which is focused and tailored toward the description of the programmer's view of a device only.
CMSIS-SVD XML Hierarchy
CMSIS-SVD Hierarchy Levels
One CMSIS-SVD file contains the description of a single device. A device consists of a processor and at least one peripheral. Each peripheral contains at least one register. A register may consist of one or more fields. The range of values for a field may be further described with enumerated values.
Device Level: The top level of a System View Description is the device. On this level, information is captured that is specific to the device as a whole. For example, the device name, description, or version. The minimal addressable unit as well as the bit-width of the data bus are required by the debugger to perform the correct target accesses.
Default values for register attributes like register size, reset value, and access permissions can be set for the whole device on this level and are implicitly inherited by the lower levels of the description. If however specified on a lower level, the default setting from a higher level will get overruled.
Peripherals Level: A peripheral is a named collection of registers. A peripheral is mapped to a defined base address within the device's address space. A peripheral allocates one or more exclusive address blocks relative to its base address, such that all described registers fit into the allocated address blocks. Allocated addresses without an associated register description are automatically considered reserved. The peripheral can be assigned to a group of peripherals and may be associated with one or more interrupts.
Registers Level: A register is a named, programmable resource that belongs to a peripheral. Registers are mapped to a defined address in the address space of the device. An address is specified relative to the peripheral base address. The description of a register documents the purpose and function of the resource. A debugger requires information about the permitted access to a resource as well as side effects triggered by read and write accesses respectively.
Fields Level: Registers may be partitioned into chunks of bits of distinct functionality. A chunk is referred to as field. The field names within a single register must be unique. Only architecturally defined fields shall be described. Any bits not being explicitly described are treated as reserved. They are not displayed in the System Viewer and are padded in the bit fields of the device header file. The case-insensitive field named "reserved" is treated as a keyword and each field with this name is ignored.
Enumerated Values Level: An enumeration maps an unsigned integer constant to a descriptive identifier and, optionally, to a description string. Enumerations are used in C to enhance the readability of source code. Similarly, it can be used by debuggers to provide more instructive information to the programmer, avoiding a lookup in the device documentation.
Vendor Extensions: The CMSIS-SVD format includes a section named vendorExtensions positioned after the closing tag peripherals. This allows silicon vendors and tool partners to innovate and expand the description beyond the current specification.
Multiple Instantiation
CMSIS-SVD supports the reuse of whole sections of the description. The attribute derivedFrom for the peripheral-, register-, and field-section specifies the source of the section to be copied from. Individual tags can be used to redefine specific elements within a copied section. In case the name of the description source is not unique, the name needs to be qualified hierarchically until the element composite name becomes unique. Hierarchies are separated by a dot. For example, <peripheral name>.<register name>.<field name>.
Peripheral Grouping
Peripherals that provide similar functionality (Simple Timer, Complex Timer) can be grouped with the element groupName. All peripherals associated with the same group name are collectively listed under this group in the order they have been specified in the file. Collecting similar or related peripherals into peripheral groups helps structuring the list of peripherals in the debugger.
Descriptions
On each level, the tag description provides verbose information about the respective element. The description field plays an important part in improving the software development productivity as it gives instant access to information that otherwise would need to be looked up in the device documentation.
.END
This chapter contains the introduction and specification of the CMSIS System View Description format (CMSIS-SVD). The introduction section outlines the objectives and benefits CMSIS-SVD.
Introduction
CMSIS-SVD formalizes the description of the programmer's view for the system contained in ARM Cortex-M processor-based microcontrollers, in particular the memory mapped registers of the peripherals. The detail contained in system view descriptions is comparable to what is found in device reference manuals published by silicon vendors.
The information ranges from a high level functional description of a peripheral all the way down to the definition and purpose of an individual bit field in a memory mapped register.
CMSIS-SVD files are developed and maintained by the silicon vendors. Silicon vendors manage their descriptions in a central, web-based Device Database and the CMSIS-SVD files are downloadable via a public web interface once they have been released by the silicon vendor. Tool vendors use these descriptions for providing device-specific debug views of peripherals in their debugger. Last but not least CMSIS compliant device header files are generated from CMSIS-SVD files.
CMSIS-SVD Benefits
The benefits for the Software Developer:
Consistency between device header file and what is being displayed by the debugger.
Detailed information about peripherals, registers, fields, and bit values from within the debugger, without the need to reference device documentation.
Public access via a web interface to new and updated descriptions as they become available from silicon vendors.
Improved software development efficiency.
The benefits for the Silicon Vendor:
A tool vendor independent file format enables early device support by a wide range of toolchains with limited effort.
The XML-based format helps ease the integration into in-house design flows.
Automated generation of CMSIS compliant device header files.
Full control throughout the life cycle of the CMSIS-SVD files from creation to maintenance via the web-based Device Database.
The benefits for the Tool Vendor:
Unified file format across silicon vendors helps the efficiency of supporting a wide range of new devices in a timely manner.
Silicon vendors provide early review access to individuals ahead of the publishing date.
Updated descriptions are available over the web simplifying the maintenance of device support.
SVD File Description
The CMSIS-SVD format is based on XML. The specification of the System View Description format was influenced by IP-XACT, a design description format used in, for example, IP stitching and IP reuse. Due to the much wider scope and complexity of IP-XACT it was decided to specify a separate format, which is focused and tailored toward the description of the programmer's view of a device only.
CMSIS-SVD XML Hierarchy
CMSIS-SVD Hierarchy Levels
One CMSIS-SVD file contains the description of a single device. A device consists of a processor and at least one peripheral. Each peripheral contains at least one register. A register may consist of one or more fields. The range of values for a field may be further described with enumerated values.
Device Level: The top level of a System View Description is the device. On this level, information is captured that is specific to the device as a whole. For example, the device name, description, or version. The minimal addressable unit as well as the bit-width of the data bus are required by the debugger to perform the correct target accesses.
Default values for register attributes like register size, reset value, and access permissions can be set for the whole device on this level and are implicitly inherited by the lower levels of the description. If however specified on a lower level, the default setting from a higher level will get overruled.
Peripherals Level: A peripheral is a named collection of registers. A peripheral is mapped to a defined base address within the device's address space. A peripheral allocates one or more exclusive address blocks relative to its base address, such that all described registers fit into the allocated address blocks. Allocated addresses without an associated register description are automatically considered reserved. The peripheral can be assigned to a group of peripherals and may be associated with one or more interrupts.
Registers Level: A register is a named, programmable resource that belongs to a peripheral. Registers are mapped to a defined address in the address space of the device. An address is specified relative to the peripheral base address. The description of a register documents the purpose and function of the resource. A debugger requires information about the permitted access to a resource as well as side effects triggered by read and write accesses respectively.
Fields Level: Registers may be partitioned into chunks of bits of distinct functionality. A chunk is referred to as field. The field names within a single register must be unique. Only architecturally defined fields shall be described. Any bits not being explicitly described are treated as reserved. They are not displayed in the System Viewer and are padded in the bit fields of the device header file. The case-insensitive field named "reserved" is treated as a keyword and each field with this name is ignored.
Enumerated Values Level: An enumeration maps an unsigned integer constant to a descriptive identifier and, optionally, to a description string. Enumerations are used in C to enhance the readability of source code. Similarly, it can be used by debuggers to provide more instructive information to the programmer, avoiding a lookup in the device documentation.
Vendor Extensions: The CMSIS-SVD format includes a section named vendorExtensions positioned after the closing tag peripherals. This allows silicon vendors and tool partners to innovate and expand the description beyond the current specification.
Multiple Instantiation
CMSIS-SVD supports the reuse of whole sections of the description. The attribute derivedFrom for the peripheral-, register-, and field-section specifies the source of the section to be copied from. Individual tags can be used to redefine specific elements within a copied section. In case the name of the description source is not unique, the name needs to be qualified hierarchically until the element composite name becomes unique. Hierarchies are separated by a dot. For example, <peripheral name>.<register name>.<field name>.
Peripheral Grouping
Peripherals that provide similar functionality (Simple Timer, Complex Timer) can be grouped with the element groupName. All peripherals associated with the same group name are collectively listed under this group in the order they have been specified in the file. Collecting similar or related peripherals into peripheral groups helps structuring the list of peripherals in the debugger.
Descriptions
On each level, the tag description provides verbose information about the respective element. The description field plays an important part in improving the software development productivity as it gives instant access to information that otherwise would need to be looked up in the device documentation.
.END
Subscribe to:
Posts (Atom)