Hi Brandon,
> I am working with the TS-7300 and doing some work with it for a
> school project. I am using the GPIO to read from a keypad and I have
> a little question. I am able to successfully read from the keypad but
> I am trying to make my code a little bit cleaner by having the
> functions I use in a separate file. I use two functions, port_B_Init
> and port_F_Init, to initialize the ports and get the pointers to the
> registers. If I create a new file that holds these functions and put
> an include line in the main file I get a segmentation fault when
> trying to set these pointers. What is the proper way to do this? If
> I only need one pointer( like only the data reg) then I just return
> the pointer and everything is fine. But what if I need a pointer to
> both the data and direction register? I have tried creating the
> pointers in the main program and passing them as arguments to the
> functions and have the function modify the address they point to but
> thats where I get the segmentation fault. It's not a big deal if the
> functions are in the same file, I would just like to know how you guys
> would handle this.
A good way to develop application code is to hide the hardware
accesses behind an interface, eg. define a key-pad API, something
as simple as
keypad.h
int keypad_init();
int keypad_read();
Then the implementation hides all the access
keypad.c
static volatile int *portdata = <port data register>;
static volatile int *portdir = <port direction register>;
int keypad_init()
{
/* setup the port */
}
int keypad_read()
{
return *portdata;
}
Your main application would include the keypad.h file, and
when you compile the application you would compile and
link your main.c and keypad.c. Later when you get lots
of library functions, you can compile them into a library
(static or dynamic).
Note that while the above code is an ok style for bare-metal
microcontrollers, for a 'device driver' under Linux, its still
a bit of a hack. Drivers are generally written in kernel
space. But for many applications that is a little bit overkill.
An issue with GPIO pins is that if you have multiple devices
connected to the pins, and if the pins and directions need to
be manipulated by the multiple device drivers, you need some
form of locking to make accesses appear atomic. Some processors
(eg. ARM) have set and clear bit registers that are inherently
atomic, while others don't.
By hiding your key-pad access behind an API, you can reimplement
the functions if you use a different hardware access method
later. If you want to use C++, then the Keypad API would
be a virtual base class, and KeypadGPIO would be an inherited
class implemented using GPIO.
However, I'm sure the above code abstraction will work for your
application.
Cheers,
Dave
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|