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
- using a macro HAVE_SPI_SPEED_FOO (as done in gpio driver) and let specific cpu override it as needed ?
Let me know what's best and I'll create a PR (provided that you are ok with the request of adding extra speeds...)
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".
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.
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.
> What is expected for not-so-common boards (like the ek-lm4f120-xl ?) ?
Actually this board is not that uncommon: it seems thousands of
students use it each year in this EDX online course for example
(
https://www.edx.org/course/embedded-s…).
But alas, they do not use it with RIOT...
Sure, because TI was giving them for few $, but the board has
been replaced by Tiva-C
> 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 ?
>
Can you rebase, I will try to test (I have the hardware).
Done ! Tested locally, pushed and hopefully CI server will agree
