board: Initial Commit for LimiFrog Version 1
Original Issue: #3020 (comment)

@katezilla thanks for this PR! There are some open questions which must not be faults, but just my unknowing of details. But in general the PR is in a good shape :-)

@katezilla thanks for addressing some of my comments. Your PR looks great now! There is still the thing about the gpio mapping. Could you please adapt that?
Did you already test some peripherals? In that case, I'd ask for lending me the hardware.

Using GPIOs as input and output works. The interrupt handler seems to cause a hard fault. Before spending too much time in searching the error, could someone with a nucleo-l1 board please check if this appears on that board with and without this PR (that also changes cpu/stml1/periph/gpio.c)? Thinking about @haukepetersen ;-) , or who else owns this board?

@katezilla great work! I think we are close before merging when the minor comments from today are addressed.
For the protocol: I successfully tested SPI and I2C yesterday. Will check GPIO now

Very nice indeed! Looking forward to see the Limifrog with RIOT on it in action.

P.S. I own an Nucleo L1, too.

Oh, good to know :-) ! If you find a minute you could try with the periph_gpio example, if the interrupt handler causes a hard fault without and with this PR.

I don't have it with me right now. Can you ping me on Monday?

If Hauke haven't checked it until then, I'll do so.

@OlegHahm, @haukepetersen this is a reminder to test above described behaviour.

I'm on it.

Hej, just looked at the GPIO driver together with @OlegHahm. With our board here, even in- and output does not seem to work with the gpio test app anymore (but this might be caused by the legacy implementation not wanting to work with the test case...). I think debugging the GPIO driver in it's current state does not make too much sense, since it is old legacy code. The nicer option would be to re-implement the GPIO driver in a clean way (as done for the f1/f3/f4).

Hm, looking just roughly over the driver, it does not look too bad or different from the other ones that you mentioned (for me). Anyway, would you agree that a new driver implementation is out of scope of this PR? What do you think about using the compat-header-solution in this PR and working on a follow-up PR regarding the driver implementation? If it is @katezilla who will do this, it would be nice if you could lend us your nucleo-l1.

You need to adapt the vector table in cpu/stm32f1/vectors.c . Please compare how it was done in #3535.

Works :-) . Please squash your commits into two. One should hold changes about the stm32l1 changes (gpio driver and interrupt vector). The other one should contain the porting of the limifrog board. Note that the linkerscript is located in the CPU folder but belongs to the porting of the board. It does not matter in which order the commits appear

squashed

Dammit! Travis complains about some applications. You should add #include "cpu.h" in periph.cpu:23

Thanks! Next time please write a short line that comments addressed. Otherwise I'll just see this randomly.

added the include :)

Happy times, and go