Closed RickKimball closed 9 years ago
The LED and BUTTON definitions are legacy code from the Leaflabs Maple and Maple Mini boards.
It's fairly meaningless for non Maple boards.
I have 1 generic C8 board that has an LED on PC13 and one C8 board that doesn't have an LED at all. I also have other larger boards that have LEDS on PG15 and I think another board with a LED on PD1
As the generic boards don't have any part numbers, and there are loads of different variations of them if you look on the Chinese language sites.
I don't think it's practical to support all of them from the boards menu
I can change the generic C series board to use PC13 for its LED as this seems the most common location, but it won't apply to all boards.
With the button, I already removed the Leaflabs API calls to check the state of the button and also toggle the LED. However the definition for the LED is used elsewhere in the code for error reporting, and I'd need to remove the error reporting code if I removed the LED definition completely
Actually, I think the general consensus is that checking for things like errors in parameters passed to API calls and then stopping and flashing the LED in case of a mistake, is probably pointless, and the code may as well just crash.
So I may just remove the error led flash stuff, independently of looking at the definitions of the LED and BUTTON pin
Do you have any suggestions ?
I tried to find schematics for the first couple of ebay $4.66 c8 boards without any luck. I'm fine with whatever you want to do. I mainly posted an issue so other people might see it. When your first exposure is to try and blink an led to verify everything is working and nothing happens, it is kind of a let down.
As far as the button, I'd leave it as I would like to use a button and I don't want to have to go back and put the code in.
With the error LEDS, if the pin is open and is consistent with the maple mini, you might use that. So there is less documenting.
-rick
Maybe a "pin mux" web page that provides a UI that lets you select what each pin does what and a button that generates a new pins_arduino.h.
Rick
I doubt its worth building a whole web page for.
Probably better that someone just documents what needs to be changed, and puts that information in the wiki
Rick I've added a page about how to create a new board. Its not a complete and totally detailed reference, but it hopefully covers the key points
The other thing I'm going to do, is remove references to the BOARD_LED_PIN from the code.
Its really only applicable to the Maple hardware, and its not something that is in the core Arduino API e.g. For the Uno etc, every knows that the LED is on pin 13, but AFIK there isn't a #define for this in the Arduino API anywhere
Its actually a bit more work than it sounds, as there are examples that use the definition, so I need to change and test all of them as well (which can take a while)
But its worth doing
@RickKimball
I've reworked the code, so that BOARD_LED_PIN and the Button pin definitions have been removed from all the code and examples.
The examples have been updated to work with Maple Mini but won't work on other boards that don't have the LED the same pin (PB1 aka pin 33)
The button pin definition has not been used for ages, because I removed the non Arduino API functions to test for button press etc, some time ago
I have written up details and reasons for this change to my blog http://www.rogerclark.net/arduino-stm32-board_led_pin-has-been-removed/
Quick stupid question. Why cant these be put into the defines in the boards definitions. That way you pick the core that works and can have blink demos that just work. I think its kind of pathetic that the arduino team didnt do that half a decade ago.
On Apr 24, 2015, at 6:15 PM, Roger Clark wrote:
@RickKimball
I've reworked the code, so that BOARD_LED_PIN and the Button pin definitions have been removed from all the code and examples.
The examples have been updated to work with Maple Mini but won't work on other boards that don't have the LED the same pin (PB1 aka pin 33)
The button pin definition has not been used for ages, because I removed the non Arduino API functions to test for button press etc, some time ago
I have written up details and reasons for this change to my blog http://www.rogerclark.net/arduino-stm32-board_led_pin-has-been-removed/
— Reply to this email directly or view it on GitHub.
Yes.
They could easily be put in the board.txt file now that I've removed them from the code.
Build extra flags is probably the place to put them
However, there are so many different generic boards with LEDs on different pins, it would totally fill the boards list with a myriad generics each with a name that would probably need to include which pin the LED is on.
Overall it doesn't follow the Arduino convention to have this define. I.e the Uno etc doesn't have it. People are told to use pin 13.
But this only applies to official hardware
Boards like the Sparkfun pro mico have the led on a different pin, and people have to change their code
If it was practical I would do it via a sub menu, but I just don't think its practical.
+1 to practicality and IMHO if you're using this stuff you are probably beyond led blinky, especially if targeting a random Chinese board off of ali*
@sweetlilmre
Agreed.
I'll close this for now as its impractical and also "non Arduino"
https://github.com/rogerclarkmelbourne/Arduino_STM32/blob/master/STM32F1/variants/generic_stm32f103c/board/board.h#L43
I have this board from ebay
http://www.ebay.com/itm/360925962777
The led is on PC13 not PC14. Also, it doesn't have a button.
http://img2.dib-bid.com/gallery3/3/f3/55526/055526-2-03.jpg Visible connection on this pic.
Others might also be having this problem