For an engineering project i’m envolved on, i have to create a C application running on the Olimex SAM9-L9260 evaluation board.
This application has got to run under the OS (Linux Debian 5.0 prebuilt on that board), so i suppose i don’t have to low-level initialize memory with assembly routines as described in the TEST_BUTT example provided by Olimex.
Well, so far so good.
The problem is that i want to use several features specific for the AT91SAM9260 microcontroller mounted on the board. It means that i should be able to use AT91 registries and functions for managing I/O lines, ADC, Usart etc.
Surfing the web i saw that the most common ways to work with this boards are:
create applications that run without the need of an OS (stand alone applications that initialize memory by themselves and use addresses, definitions and functions defined in some .h file like AT91SAM9260.h, lib_AT91SAM9260.h etc. You can have a very low-level control on the microcontroller’s registries and functionalities)
create applications that run as kernel modules, using headers and code from linux sources and specifically from the directory $LINUX_SRC/arch/arm/mach_at91 (i suppose that in this way the OS allocates specific AT91SAM9260 memory maps, makes interrupt vector etc. Then you can manipulate I/O pins and several peripherals by calling functions starting with “at91_”.
Well, my question is: can i do a simple C application (not a kernel module!!!) that makes me manipulate AT91SAM9260 peripherals by importing some ATMEL or OLIMEX library? If so, could you just make a little C example or could you post some link to look at (please don’t post official ATMEL links… )
The only functionalities i need are: I/O pins managing, AD Conversions and PWM generation.
Thanks in advance and sorry for my potential uncorrect english
Is your I/O oriented application simple enough such that you could choose a microprocessor that does not need the huge complexity of embedded Linux and memory management? You’ll spend 90% of your time on operating system crap-ola instead of the objective.
Out here in the real world, we embedded system engineers don’t use big operating systems unless its essential.
A $50 microprocessor will probably suffice. If you want state of the art, consider an LPC1768 or some such. like mbed.org where you get all the libraries you could want from them. Free.
But using these libraries isn’t what, I think, a student should do. You won’t learn the fundamentals.
If you are not a student, using canned libraries is OK for a proof of concept. But for a real product, you need to own the source code to deal with bugs.
PS: in the world of ARM processors, my opinion is that Atmel’s ARMs are not a good choice, as compared to NXP/LPC or STM.
Anyway, i understand i’ve been a little bit vague on my question, i’ll try to add some usefull detail.
My enterprise has designed and ordered for production a custom board based on ATMEL AT91SAM9260 microcontroller, and while we are waiting for that board, we bought Olimex SAM9-L9260 board to get in touch with AT91 programming environment. This commercial product comes with Linux Debian 5.0 prebuilt.
The main AT91 functionalities i need to deal with are:
GPIO managing: i need to set and read the state of several I/O pins, and in particular i need to send a clock signal to 8 pins almost simultaneously (roughly speaking, i have to manipulate system oscillator to generate a 20 KHz pulsed signal and i have to send this signal on thees 8 pins).
AD Conversion: i need to read a voltage on several pins (not only analog-to-digital dedicated pins but also GPIO programmed to receive voltage values.
That’s all.
I can’t make a total embedded firmware (there is the O.S. running and i must let it be because we need its network services). I should realize a C application that runs in user space and able to access AT91SAM9260 registries to get adc conversions, pwm generation, gpio low-level control etc.
I tried to make such a thing by using the gpio-dev and gpio-sysfs interfaces provided by Linux (gpio pins are seen as files under /dev and /sys filesystems and you can set a logic state by writing on the associated files). Unfortunately theese kind of interfaces are quite limitated for my needs. For example, speaking about GPIO, i cannot control pins simultaneously. And there aren’t user-space interfaces for accessing functionalities like ADC or clock managing: i should access micro-registries directly!
At this point, i start thinking the only way i can solve my problem is programming a kernel module (like a custom device driver) by using $LINUX_SRC/arch/arm/mach_at91 sources and make it run in kernel-space as any other device driver.
Any idea to access micro registries without creating a device driver? Thanks, bye :?
If I remember correctly, I had to access io from userspace on a linux mips arch, i used a mmap() on an opened /dev/mem. AFAIR, access was slow (<1MHz generated on gpio for a 200Mhz soc).
FulvioG:
The main AT91 functionalities i need to deal with are:
GPIO managing: i need to set and read the state of several I/O pins, and in particular i need to send a clock signal to 8 pins almost simultaneously (roughly speaking, i have to manipulate system oscillator to generate a 20 KHz pulsed signal and i have to send this signal on thees 8 pins).
AD Conversion: i need to read a voltage on several pins (not only analog-to-digital dedicated pins but also GPIO programmed to receive voltage values.
That’s all.
I can’t make a total embedded firmware (there is the O.S. running and i must let it be because we need its network services). I should realize a C application that runs in user space and able to access AT91SAM9260 registries to get adc conversions, pwm generation, gpio low-level control etc.
There’s no way you can acheive this on the current linux you have.
First you cannot access low level kernel function (the ones in march) from userspace directly, you will need kernel module with standard linux interface on top.
Then you will have a lot of issues with the timing constraint of linux kernel. It’s not realtime and worse you want to directly access hardware from user space. By the way, what are the constraint you have on your timing (jitter)?
Other solution is to patch the kernel with realtime support, writing realtime kernel module for all your realtime work, controling driver through standard linux interfaces (char devices).
Ultimate solution is to use a dedicated RTOS, like freeRTOS. You will have quite some work to adapt it for your board but it will be the same for linux.
Btw: you can’t have both “precise clock generation” and “software” in the same sentence without a negation in between. Software generated clocks are always a compromise.
)
