| Author |
Message |
|
|
 Posted: Nov 29, 2011 - 02:41 PM |
|
Joined: Nov 29, 2011
Posts: 3
|
|
Hi, I'm new to the world of AVR and having some problems about configuring I/O, though I tried to do it according to the different tutorials I found. I'm using a dev board http://alvidi.de/avr32_modul.html with an AVR32 UC3A1512, and I'm developping with AVR32Studio.
I manage to blink some LED correctly using gpio_set_gpio_pin(AVR_32_PIN_PB..)and gpio_clr_gpio_pin()
I also manage to get an input value using GPIO_GET_PIN_VALUE(...) and affect this value to another pin with a LED connected.
The problem I have is I'm working with a external memory, so I need to alternatively write and read with the same pins. Surprisingly when I use those set_pin and get_pin methods one after the other the compilation is okay, but then the values I read are not correct, and the micro is still acting as if the pin was an output during the get method.
using DDRA=... is not recognized by the compiler I use (doesn't work with CDT internal builder and gnu make builder)
Then I thought about using gpio_configure_pin, but is it the way I should do that ?
It seems quite high level and I don't want something using 30 clock cycles. I will need to be very fast with my application since I will have to switch pins from writing/reading at least 100K times/second.
What is the correct way to switch pins from input to output in low level ?
Thanks for any help |
|
|
| |
|
|
|
|
|
|
Posted: Nov 29, 2011 - 02:55 PM |
|
Joined: Oct 06, 2010
Posts: 51
|
|
Probably the best way is to use the AVR's built-in peripherals for interfacing with your external memory. What kind of memory are you trying to use?
In my application, I have an AVR UC3A3256 connected to two DSPs using the Static Memory Controller (the DSPs are implementing the HPI protocol, allowing me to access their internal memory). This AVR peripheral enables access to external memory, and with proper configuration, will be the most efficient method for controlling reads and writes to your GPIO pins.
Why reinvent the wheel when Atmel's already done all the hard work for you? |
|
|
| |
|
|
|
|
|
|
Posted: Nov 29, 2011 - 03:13 PM |
|
Joined: Nov 29, 2011
Posts: 3
|
|
I am using a static SRAM with no communication protocol, that's why I need to reinvent the wheel.
There are 19 adresses pins and 8 data pins, so I need to write/read the data in an "old fashioned" way :/ How do you do to switch a pin from output to input ?
Another question is, is it normal gpio.h and gpio.c doesn't compile when I use the cdt internal builder ? |
|
|
| |
|
|
|
|
|
|
Posted: Nov 29, 2011 - 03:41 PM |
|
Joined: Oct 10, 2007
Posts: 395
Location: Valls, Spain
|
|
Your static SRAM will work better and faster when connected to the EBI and using the SMC (memory accesses could be done as if accessing the internal SRAM of the MCU), but since you are using the A1512 which doesn't have en EBI, your only option seems to be the GPIO bit banging.
The AVR32 also has something called the CPU local bus, and the GPIO pins happen to be connected to it, meaning that you could toggle the pins as fast st the CPU is running. The GPIO driver in the software framework will allow you to configure and use the local bus very easily. I don't see any reason for you to reinvent the wheel... |
_________________
Daniel Campora
http://www.lear.com
|
| |
|
|
|
|
|
|
Posted: Nov 29, 2011 - 04:08 PM |
|
Joined: Nov 29, 2011
Posts: 3
|
|
Okay, thank you for the answer.
So to use the gpio driver, do I need to configure pins as input or outputs or is it kind of automatical when I use gpio_set_gpio_pin and gpio_get_pin_value ?
Do I need to use gpio_configure_pin to switch a pin from input to output ? |
|
|
| |
|
|
|
|
|
|
Posted: Nov 29, 2011 - 04:17 PM |
|
Joined: Aug 25, 2011
Posts: 395
Location: Europe
|
|
gpio_set_gpio_pin and gpio_clr_gpio_pin both enable the driver for the specified pin, which overrides whatever your SRAM might output. You can use gpio_set_gpio_open_drain_pin(...) to disable the output driver.
Be careful when requesting data from the SRAM, because if you still have the MCU set to output high or low on one of the data pins and then the SRAM outputs something on the same lines, you can easily get short-circuits. Always disable the output driver before letting the SRAM drive the lines. |
|
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
