On 29-01-2016 14:03, Kaspar Schleiser wrote:
Hey,
On 01/29/2016 01:56 PM, Marc wrote:
I would like to drive the SPI at speeds currently not in the enum
types.
What would be the best approach (ie. what would be accepted in a pull
request) :
- adding extra speeds to the global enum
Sounds the most sensible.
Also, I'm wondering if RIOT has any rule for accepting new drivers. I
have been playing with small LCD, ws2812, mm5450, 7segments displays
and
I'm wondering if I should try to make something clean for creating a
PRs
? I see that's devs are already flooded by more important PR, so maybe
you simply don't want these extra "gadgets".
Sure, keep 'em coming!
One problem with drivers will always be that it's not possible to test
them if the hardware is not around. But if the PR looks OK (adheres to
RIOT's conventions and style), we'll merge it anyways.
Hey :)
I was really willing to create new PRs, but I'm still stuck with a PR
that's few months old now (#4392) because I guess there's no time for
this (and I 100% understand that).
I was asked to create separate PR for each periphs (GPIO PR has been
started en of nov, I still have pwm and spi waiting in my queue).
What is expected for not-so-common boards (like the ek-lm4f120-xl ?) ?
Should I wait for someone to ping the PR and tell me what's
missing/expected ? Should I continue to rebase it even if no-one has
time for this ? I could also group everything together (GPIO, SPI, PWM)
so that when someone has few minutes to review it, everything can be
done at once ?
The smaller divers (lcd, ws2912, mm5450) need a big cleaning before a PR
can be pushed, so I don't really want to spend time on this if there is
technically no time for reviewing... And I guess that having PR created
then going to "unmaintained" state is not wanted by RIOT.
Thanks !
Marc
_______________________________________________
devel mailing list
[email protected]
https://lists.riot-os.org/mailman/listinfo/devel
