Handle GPIOs in User space for Embedded Linux ARM9 - embedded

I have to interface my GSM module with the AM1808 based on ARM9.
I have assigned all the GPIO pins to the Da850.c as well as mux.h files.
I successfully created a uImage and inserted that image in my flash.
I need to handle some of that GPIO from User application.
I know that we can handle the GPIO from the Kerel space but i need to handle from the user space.
As for example I have assigned a GPIO for power key to GSM module. I need to change the pin means (HIGH or LOW) through application.
How I can handle it ?
I am using UBUNTU 10.04 for development.
Thank You in advance.

Most Linux kernels have GPIO mechanisms built in. It's usually easiest to use those. Overview in Documentation/gpio.txt. This is common newbie topic, there are lots of nice tutorials out there like gpio_sysfs.
If you get hung, you could post comment with more info such as which SBC and kernel version you're using (e.g. LogicPD Zoom and 2.6.33), and which GPIO pin(s) you will try first.

You can handle this by using mmap to map the physical memory (via /dev/mem/) into user memory.
There's some example code here:
http://naveengopala-embeddedlinux.blogspot.co.uk/2012/01/reading-physical-mapped-memory-using.html

Related

STM32F7 Discovery - where are the LEDs?

I am learning about ARM development on my STM32F7 Discovery Kit (w/ STM32F746NGH6 Microcontroller) and I'm trying to write a "blinky" program without using high level libraries.
Reading the documentation, I couldn't figure out which MCU pins are all those onboard LED's connected to? What is the right document to check?
Looking at the board I can see some LEDs (LD1, LD2, ...), but how can I reach them in program? I don't see them in header files and if they are controlled via GPIO pins, how to I know which ones?
In the user manual there's no mention of any LED, except in the electrical schematics (where none of the LEDs is connected directly to the MCU afaik- they serve mostly as hard-wired board status indicators).
Is it possible that an advanced board like this doesn't have a single general purpose LED on it?
From the schematic in that document, it looks like you should be able to use LED LD1 on PI1 (GPIO port I pin 1).
Download the STM32CubeF7 software package. It should include a blinky program example specifically for your board. Then see which LED/pin they use in the example program.

Program uploading to LPC 2148 by the time of component assembling

I am developing an elevator GLCD display (128*64) with LPC2148 Micro controller, I have done program and PCB designing also. Now I want to upload the program to micro controller, how to do it? Before fixing micro controller or after fixing micro controller want to upload program?
If I understand correctly you want to program the device without using a bootloader or a JTAG. There is some standalone programmers available for the LPC2148 device. Example here. This will allow the MCU to be programmed before placing it on the board.
The maintainability of your design however raises red flags. You should at least have a JTAG header on the board even if it is not populated. JTAG is very flexible and cheap and add lots of development and testing options.
If I am right, than the LPC2100 series does have an ROM bootloader. You only have to pull a pin (I think P0.14) to ground while reset.
Flashmagic would than be a tool of choice to download the program.
Pro: No additional hardware needed.
Con: The bootloader pin and USART (normally USART0) need to be accessable.
1.Use the Keil compiler to compile your code and
generate hex file
2.Download and Install Flash Utility
3.In flash utility
Select Com port ,Board, Baud rate (may be default) and file
4.Now click on Upload to flash

PIC Bootloader -- USB controller required?

I am working with a simple PIC18F2550 and I'm wondering about how to get a bootloader working on it. It's a very simple device with a USB port and CDC firmware. When I download Tiny Bootloader onto the pic, my PC doesn't recognize the device. Do I NEED to have a USB controller in my circuit in order for it to work? Such as the MAX232?
Would the same apply to the PIC32MX795F512L?
Thanks!
It is clear from the Tiny PIC boot loader documentation that it expects a UART connection rather than USB (that is what the MAX232 is for - it is an RS232 line driver).
You could simply do that and use an external serial to USB converter thus saving the code space required by the USB-CDC stack. Otherwise you will have to modify the boot loader code to use the CDC driver rather than the UART.
You will have to link the USB code with the boot loader, which will no doubt significantly increase its size. You may need therefore also to move the application start address to accommodate the boot loader. Furthermore, if the application needs USB comms, you may need a separate copy of the code in the application unless you provide a method of accessing the bootloader code from the application; which is possible, but not necessarily straightforward.
All that said, note the part at the end of the end of the page about extending the bootloader; On the face of it it seems unsuited to extension. Without looking at the code and its memory map, it is not clear why it has this constraint.
The PIC18F2550 has a USB interface built into it. It is called the "USB SIE" and there is a large section in the datasheet that documents it. If you make the right electrical connections, you should be able to connect your PIC18F2550 directly to a USB port without any active electronics between them. There is no reason you would need extra USB hardware just because you want to run a bootloader.
If you want to troubleshoot your problems with the bootloader, you should probably post another question with more details. It could be a problem with the PIC's configuration bits or something like that. I recommend trying to modify the bootloader to get it to blink an LED as a basic first step just so you can verify that you were able to get its code to run at all.

FT232R USB IC with direct access IO (no UART)

I would like to create a scenario to directly access IOs via USB by using FT232R.
In more detail, scenario is the following: I would like to feed an LIN transceiver IC by a FT232R USB device. However, the FT232R as a USB-serial-converter outputs UART signals, which includes a start bit as well as a stop bit. For me, it is required to not have these start and stop bits, even though they are standardized in UART protocol.
My questions:
Is it possible to use the bang mode of this device to avoid start/stop bits and transfer raw data? Then, how to program the code for doing this?
If not, are there any USB transceiver, which have to possibility via COM/driver access to fulfil my requirement?
Thanks a lot in advance for your help!
Yes, the chip provides 4 pins that can be used for generic bit banging. Here is an application note describing how to use bit banging mode.

suitable Embedded system to be used for image processing and gps/gsm

i am working on a project, where i would like to install an embedded system in a certain location , the system is provided with a camera , the system has to perform image processing functions on the images obtained from the camera.
The system must be attached with gps and gsm modules.
i am in the process of choosing the hardware needed, i am thinking of using a beagle board or FPGA , which one is more suitable for my application ? do you recommend other boards? do you know any gsm or gps modules that can be interfaced with these modules?
Thank you
If your image processing algorithms are too CPU intensive I'll suggest you consider FPGAs. Otherwise, Beagle board is fine.
What is the interface to your camera? USB / FireWire / I2C / other? If the Beagle Board supports what you need, and can handle the processing, that's probably the easiest way to go - FireWire and USB interfaces are not exactly trivial to do on an FPGA, unless you can get a board and a matching Linux distro for it, where everything is configured and working out of the box (and it's probably going to be expensive then...).
GPS modules typically connect over a simple serial connection, so that shouldn't be an issue for either solution.