Dear Markus Hubig,
On 06.08.2012 18:49, Markus Hubig wrote:
On Mon, Aug 06, 2012 at 03:01:40PM +0200, Andreas Bießmann wrote:
On 06.08.2012 11:11, Markus Hubig wrote:
+static unsigned int saved_state[3] = {STATUS_LED_OFF,
- STATUS_LED_OFF, STATUS_LED_OFF};
+void coloured_LED_init(void) +{
- /* Clock is enabled in board_early_init_f() */
But coloured_LED_init() is called way before!
Beware, this coloured LED stuff is sometimes used for very early debug purposes. To get this working you will need to switch the clocks here.
If you not insist on this colour LED framework I would appreciate to not add this coloured_LED_init for the stamp9g20 but use the status LED framework -> README.LED
Are you shure about this?
No, I've not worked with that status LED thing. Contrastingly I thought that LED stuff is at91 specific. But there are some other ARM SoC using this colored LED and status LED thing. So this appears to be a wrong decision.
Is I just remove this and put the
- at91_set_gpio_output(CONFIG_RED_LED, 1);
- at91_set_gpio_output(CONFIG_GREEN_LED, 1);
- at91_set_gpio_output(CONFIG_YELLOW_LED, 1);
in __led_init() I have no LED's at all and the commandlie tool 'led' stopps working... At all the Status LED stuff is a bit confusing ...
It's not clear to me if the STATUS_LED_BIT should be e.g. 1 or e.g. AT91_PIN_PC5.
It's not clear what the benefit of using this is.
It's not clear if the coloured_LED stuff is part of it or something extra.
Sorry, I can not help you here.
Maybe it's better is I just switch on the green LED in board_init?
but you will loose the led cmd which may be useful.
For now I just switched the clock on in coloured_LED_init. At least I have some LED now.
Thats ok with me.
Best regards
Andreas Bießmann