BITCLOUD - Buttons problem

Go To Last Post
24 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,
I'm having this error:

Quote:

.../src/buttons.c:84: undefined reference to `GPIO_IRQ_6_read'
.../src/buttons.c:89: undefined reference to `GPIO_IRQ_7_read'

I couldn't found that function "GPIO_IRQ_x_read", It's not defined anywhere...
I was looking that function on BitCloud_ZIGBIT_1_10_0.

Any idea why this function is not defined anywhere???

If I have to do by myself,
What it's supposed to do? read the IRQ flag?

thanks everybody

Last Edited: Fri. Oct 16, 2015 - 02:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

troyka wrote:
I couldn't found that function "GPIO_IRQ_x_read", It's not defined anywhere...

They are generated by preprocessor in gpio.h file.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gpio.h has inside:

Quote:

INLINE uint8_t GPIO_##name##_read(void) {return (PIN##port & (1 << bit)) != 0;} \
INLINE uint8_t GPIO_##name##_state(void) {return (DDR##port & (1 << bit)) != 0;} \
.
.
.
// the macros for the manipulation by GPIO_IRQ_7
HAL_ASSIGN_PIN(IRQ_7, E, 7);
// the macros for the manipulation by GPIO_IRQ_6
HAL_ASSIGN_PIN(IRQ_6, E, 6);

I assume that the compiler is responsible to replace the ##name## for IRQ_6 and 7 am I right?

Just for a test, I renamed gpio.h to gpio_.h and nothing happens, the compiler error was the same at first, so I think that the #include on buttons.C it's not being called.
But the compiler didn't complain about that...
I also didn't found a path for
BitCloud_ZIGBIT_1_10_0\BitCloud\Components\HAL\avr\atmega1281\common\include\gpio.h
any idea what could be the problem??

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

troyka wrote:
any idea what could be the problem??
What exactly do you do to get those errors?

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is my attempt to add IRQ support for the RAVEN boards taking zigbit SDK as an example.
the main.c is calling:

Quote:

void APL_TaskHandler(void)
{
BSP_OpenButtons(NULL,buttonsReleased);
} //not finished this, maybe another call is needed

then modified bspTaskManager.h :
Quote:

enum
{
BSP_LCD = (uint8_t)1 << 0,
BSP_BUTTONS = (uint8_t)1 << 1, //added this line
};

I'm using the same buttons.c and buttons.h from zigbit.

then to the bspTaskManager.c added:

Quote:

/**********************
\brief BSP button handler.
************************/
void bspButtonsHandler(void);
/***************************
\brief BSP battery handler.
*****************************/
void bspBatteryHandler(void);
/**********************
Implementations section
************************/
/***********************
\brief BSP task handler.
**************************/
void BSP_TaskHandler(void)
{
#ifdef _BUTTONS_
if (bspTaskFlags0 & BSP_BUTTONS)
{
bspTaskFlags0 &= (~BSP_BUTTONS);
bspButtonsHandler();
}
#else
if (0)
{
}
#endif
if (bspTaskFlags0)
{
SYS_PostTask(BSP_TASK_ID);
}
}

then defined the variable _BUTTONS_ on \BitCloud\Components\BSP\BoardConfig and looks like this:
Quote:

#ifdef BOARD_RAVEN
#define _LCD_
#define _TEMPERATURE_SENSOR_
#define _BATTERY_SENSOR_
#define _BUTTONS_
#endif

Then, when you told me about GPIO.h, found this two lines that was not defined to raven's gpio.h:
Quote:

// the macros for the manipulation by GPIO_IRQ_7
HAL_ASSIGN_PIN(IRQ_7, E, 7);
// the macros for the manipulation by GPIO_IRQ_6
HAL_ASSIGN_PIN(IRQ_6, E, 6);

will raven get IRQ working with this code?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

troyka wrote:
will raven get IRQ working with this code?
You'll also need to add IRQ handling code (interrupt handlers, enable-disable code, etc) to HAL by analogy with ZigBit.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After renaming gpio.h, the compiler complains about "file not found", restoring the name back, the problem was solved.

alexru wrote:
You'll also need to add IRQ handling code (interrupt handlers, enable-disable code, etc) to HAL by analogy with ZigBit.

I hope I'm not making a mistake here, because all those things are already defined. (At least, up to I could find). The only thing that the compiler warns me about was the next two lines on gpio.h

Quote:
// the macros for the manipulation by GPIO_IRQ_7
HAL_ASSIGN_PIN(IRQ_7, E, 7);
// the macros for the manipulation by GPIO_IRQ_6
HAL_ASSIGN_PIN(IRQ_6, E, 6);

The problem was that micro 1284 has no PORT E, so changed the "E" to "D"
It's a little buggy because there is no info anywhere about those functions.
Now, I’m not sure about the 6 and 7, because on the 1284 there is INT0:3
What is the third parameter?

Regards

PS: the code is compiling, but the interrupts are not working at this point.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't quite understand what you are doing. If you want to add buttons to 1284-based platform, then change buttons code to reflect actual IRQs your buttons connected to. What's the point of adding support for non-existent IRQs?

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The problem is that the "1284-based platform" is a RAVEN board, and there is no IRQ support from factory, despite there are IRQ.h and other files...
I need to do a demo using the raven board next month, and need IRQ to generate events.
This is more or less the situation...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

troyka wrote:
The problem is that the "1284-based platform" is a RAVEN board, and there is no IRQ support from factory

Sure there is. HAL supports IRQ0-2, you can call HAL_RegisterIrq()/HAL_EnableIrq()/HAL_DisableIrq() and they will work, use IRQ_0 - IRQ_2 as irq number.

GPIO_IRQ_6_read() is just a function to read GPIO state, it does not matter how its called. For example if there is a code in gpio.h:

HAL_ASSIGN_PIN(0, B, 5);

and IRQ line is on B5 (I have not checked datasheet, use actual IRQ port) then use GPIO_0_read() instead.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You are right since the functions HAL_RegisterIrq()/HAL_EnableIrq()/HAL_DisableIrq() are defined, but GPIO.h does not provide any pin mapping for IRQ.
Let me explain better:
ATMEGA1284 uses PD2 / PD3 / PB2 as IRQ inputs.
There is no HAL_ASSIGN_PIN defined for these pins, at least not in the IRQ way, because is defined:

// the macros for the manipulation by GPIO_USART1_TXD
HAL_ASSIGN_PIN(USART1_TXD, D, 2);
// the macros for the manipulation by GPIO_USART1_RXD
HAL_ASSIGN_PIN(USART1_RXD, D, 3);

so, I added:

// the macros for the manipulation by GPIO_IRQ_7
HAL_ASSIGN_PIN(IRQ_7, D, 2);
// the macros for the manipulation by GPIO_IRQ_6
HAL_ASSIGN_PIN(IRQ_6, D, 3);

Maybe, its intended that the user add those lines...or just call USART1_TX or RX knowing that what you are really using is an interruption pin.
The names IRQ_6 and 7 comes from IRQ.h

/** \brief number of valid interrupt for avr and avr32. */
  IRQ_6 = 6,
/** \brief number of valid interrupt for avr and avr32. */
  IRQ_7 = 7,

I maintain that nomenclature because is already used on buttons.c and seems to be coherent.
On buttons.c is defined GPIO_IRQ_6_read() and 7 as you say before.
But still no results....

this is the app_task_handler:

void APL_TaskHandler(void){
	BSP_OpenButtons(buttonsPressed, buttonsReleased);				
}
static void buttonsReleased(uint8_t buttonNumber){
	  appSendLcdCmd(LCD_CMD_LED_OFF);
}

void buttonsPressed(uint8_t buttonNumber){
	  appSendLcdCmd(LCD_CMD_LED_ON);

}

Any idea or other thing to check?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

troyka wrote:
The names IRQ_6 and 7 comes from IRQ.h
No, they don't. Names used in HAL_ASSIGN_PIN() are purely local, used to form name of the functions to manipulate those pins. That's OK for them to be named as you wish, but actual meaningful names would be better of course.

On the other hand IRQ_6 passed in (see buttons.c):

HAL_RegisterIrq(IRQ_6, IRQ_LOW_LEVEL, bspKey0InterruptHandler);

is actual IRQ number. And 1284 can't handle IRQ_6, so HAL_RegisterIrq() return error. So you need to change at least that parameter.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
And 1284 can't handle IRQ_6

That's right, but as I could see here, IRQ_6 just represent here an integer 6 from HAL_IrqNumber_t, is not representative for int0-3 (not at this point)

Let me show you, may be I'm wrong:

buttons.c initiates the interruptions this way:

  HAL_RegisterIrq(IRQ_6, IRQ_LOW_LEVEL, bspKey0InterruptHandler);

IRQ.H define IRQ_6 this way (cutting all other micros codes here):

typedef enum
{
#if defined(ATMEGA1284) 
/** \brief number of valid interrupt for arm and avr32. */
  IRQ_0 = 0,
/** \brief number of valid interrupt for arm and avr32. */
  IRQ_1 = 1,
/** \brief number of valid interrupt for avr32. */
  IRQ_2 = 2,
/** \brief number of valid interrupt for avr32. */
  IRQ_3 = 3,
/** \brief number of valid interrupt for avr32. */
  IRQ_4 = 4,
/** \brief number of valid interrupt for avr(only rcb platform) and  avr32. */
  IRQ_5 = 5,
/** \brief number of valid interrupt for avr and avr32. */
  IRQ_6 = 6,
/** \brief number of valid interrupt for avr and avr32. */
  IRQ_7 = 7,
#endif
  IRQ_LIMIT
} HAL_IrqNumber_t;

so, the only available interruptions here for the 1284 are 6 and 7 right?

then, buttons.C calls GPIO.H functions this way:

#define BSP_readKEY0() GPIO_IRQ_6_read()
#define BSP_readKEY1() GPIO_IRQ_7_read()

and finally, the added before:

HAL_ASSIGN_PIN(IRQ_7, D, 2);
// the macros for the manipulation by GPIO_IRQ_6
HAL_ASSIGN_PIN(IRQ_6, D, 3); 

Whith this two lines, I'm mapping IRQ_6 to port D pin 2 right? then when "HAL_RegisterIrq(IRQ_6,..." I'm calling int0 this is correct??

I think this is all the way down to hardware for the IRQ
Am I miss understanding this? or some step missing/wrong?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

troyka wrote:
so, the only available interruptions here for the 1284 are 6 and 7 right?
No. Don't read comments, read code. HAL_*Irq() expect IRQ_0-2 to be passed to them. It's pretty clear from halIrq.c file.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ok, I didn’t see halirq.c
That file changes the things...
Thanks for clarify this!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ok, changed the IRQ_6 and 7 by 0 and 1.
Doing a debug, I can see that the interruptions are generated, but no action taken.

Tracing the code, it start looping on the function BSP_TaskHandler().
Originally, this function was empty, looking at zigbit examples found the next: (example with buttons use)

void BSP_TaskHandler(void)
{
#ifdef _BUTTONS_
  if (bspTaskFlags0 & BSP_BUTTONS)
  {
    bspTaskFlags0 &= (~BSP_BUTTONS);
    bspButtonsHandler();
  }
#else
  if (0)
  {
  }
#endif
  if (bspTaskFlags0)
  {
    SYS_PostTask(BSP_TASK_ID);
  }
}

If I don't use the code, the flow stop on BSP_TaskHandler, using this code, is a loop
between SYS_PostTask and BSP_TaskHandler

What is supposed to do here? clear any flag?

Happy new 2011 Alex!!!!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

BSP Will be reposting its task until button is released (pin goes high). If you release the button and still looping there then you need to check your BSP_readKEYx() macros.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ok, found the problem, it seems like the variable, _BUTTONS_ is not defined for the code, so, never executes bspButtonsHandler()...

void BSP_TaskHandler(void)
{
#ifdef _BUTTONS_
  if (bspTaskFlags0 & BSP_BUTTONS)
  {
    bspTaskFlags0 &= (~BSP_BUTTONS);
    bspButtonsHandler();
  }
#endif
  if (bspTaskFlags0)
  {
    SYS_PostTask(BSP_TASK_ID);
  }
}

I defined the variable _BUTTONS_ this way on BitCloud\Components\BSP\BoardConfig

#ifdef BOARD_RAVEN
  #define _LCD_
  #define _TEMPERATURE_SENSOR_
  #define _BATTERY_SENSOR_
  #define _BUTTONS_
#endif

And the configuration file, takes care about BOARD = BOARD_RAVEN, so, what could be happening to cause the code to miss the _BUTTONS_ variable?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

troyka wrote:
I defined the variable _BUTTONS_ this way on BitCloud\Components\BSP\BoardConfig

#ifdef BOARD_RAVEN
  #define _LCD_
  #define _TEMPERATURE_SENSOR_
  #define _BATTERY_SENSOR_
  #define _BUTTONS_
#endif

This is contents of BoardConfig.h, it is used by IAR IDE. For GCC and command line IAR you need to modify BoardConfig (without .h).

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Found it and solve the problem.
One last question:
Using AVR Studio, if I do "clean" project, the compiler cannot reach bspTaskManager.h
Last time I saw this message, copied this file to the application/include folder and let me continuing working...
Is this another configuration file that I'm missing??
thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

troyka wrote:
Using AVR Studio, if I do "clean" project, the compiler cannot reach bspTaskManager.h
Clean button just cleans everything, it has nothing to do with compiler. So I assume that following build fails. Does this happen every time or what? What is the exact error message?

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is the error:

Quote:
src/buttons.c:24:28: error: bspTaskManager.h: No such file or directory
src/buttons.c: In function 'bspKey0InterruptHandler':
src/buttons.c:183: warning: implicit declaration of function 'bspPostTask0'
src/buttons.c:183: error: 'BSP_BUTTONS' undeclared (first use in this function)
src/buttons.c:183: error: (Each undeclared identifier is reported only once
src/buttons.c:183: error: for each function it appears in.)
src/buttons.c: In function 'bspKey1InterruptHandler':
src/buttons.c:194: error: 'BSP_BUTTONS' undeclared (first use in this function)
src/buttons.c: In function 'bspKey2InterruptHandler':
src/buttons.c:204: error: 'BSP_BUTTONS' undeclared (first use in this function)
src/buttons.c: In function 'bspButtonsHandler':
src/buttons.c:233: error: 'BSP_BUTTONS' undeclared (first use in this function)

And the directories are:
FOLDER\Application\TEST1
FOLDER\BitCloud

If I move bspTaskManager.h to FOLDER\Application\TEST1\include, then can't compile because of this:

Quote:
make: *** No rule to make target `objs/EX', needed by `test1.elf'. Stop.
(this is a new error, never seen before)
But I think that it's not the idea to move bspTaskManager right?

One thing that maybe is important. This version that can't compile, is a backup from the previous version that does compile, but is the version that I have copied bspTaskManager to the FOLDER\Application\TEST1\src folder.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

troyka wrote:
This is the error:
I guess something wrong with include paths, which means that something is probably wrong with Makefiles.

Without examining final command lines used to call avr-gcc it is hard to say something meaningful.

I suggest you to apply your changes to a clean SDK and see at what point it breaks.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Used new SDK, working perfect!
thanks!