boards: Remove support for the Jiminy-Mega256RFR2 #12182
Conversation
- The Jiminy-Mega256RFR2 is seemingly unmaintained, as no one has responded
on requests to test changes on it. This lack of support has been blocking
various PRs in the last few months
- No one seems to use it
- Boards that are added to RIOT should match at least one of the following
- It is actively maintained
- It has a significant user base
- It is an off-the-shelf product, so it might be easily obtained for testing
==> The Jiminy is matching none of the above
maribu
added
Discussion: RFC
|
To also have the info received on the mailing list available here: There is interest in keeping support for the CPU (ATmega256RFR2), as adding upstream support for the Merkur Board is in progress. The Merkur Board is an off-the-shelf product and commercially available e.g. here, or here (site currently having issues). |
|
#9172 lacks the final review from us, but it might need some more work by @Josar too. @Josar are you still interested in this? If we get the radio code merged, would that help you with working with upstream RIOT directly or are you now on a different project? |
|
I, as one of the two actual users, agree that its probably best to drop support for the board and just keep the cpu support for the Merkur board. As the Jiminy-Board schematics never got published it does not make sense to keep it, especially if it is delaying PRs. |
|
While your arguments are valid, the right process AFAIK would be to deprecate the board first. This way we can phase support out slowly (and also maybe give the merkur board time to be merged in the meantime). |
Let's recapitulate the context: @shr70 confirmed that in total two persons on this planet have access to the hardware and can be counted as potential users of the code. Also, he confirmed that he no longer is an active user, so there is at most one active user of the code in this universe as far as we know. With this context in mind, I'm not sure if @miri64's suggestion to follow a multi-step depreciation process is a real suggestion or a joke. |
|
However, with the apparent context of the board only having two users, I agree that our usual process would be overkill. |
|
As always, I'm a supporter of the wrecking-ball approach, so a +1 from me. @shr70, you want to keep the CPU, but this is the only board using it. How are we going to support the CPU without having a board to test it? There is an Xplained board for that CPU. If you want to have support for the CPU it may be a good option to use that board in RIOT (independently of the board you use yourself) so that other devs can get it easily. Now that I think about it, it may be a good strategy for people with custom boards that need to have their CPU supported in RIOT to add a dev board with that CPU instead. |
|
@PeterKietzmann should also have a Jiminy-board. I am fine with dropping the support for the Jiminy-boards. As the xtimer for 16bit counter had issues which could not be resolved as all provider PRs did not get enough attention to reach master. And with the xtimer issues a continues network could not be maintained so this 16bit mcu based board can not be used in an LoWPAN. |
|
@benpicco i would like to contribute the at86rf part but i have to see if i find time for reworking it. Besides that the mcu can also be used for pinoccio boards https://github.com/Pinoccio maybe some of them can be bought. |
|
The MCU can also be found on the ATRCB256RFR2-XPRO dev board which can be bought off the shelf for ~30€. btw, which xtimer PRs are you referring to? |
|
I think that ztimer will overcome the issues with 16 bit timers, if I remember correctly. ztimer is on the way in anyway, so effort on fixing xtimer might be better spend on reviewing and contributing to ztimer |
|
@benpicco I was trying to search for the same thing but got confused about which is the "real" board, the one you mentioned or the ATMEGA256RFR2-XPRO. That one is ~€60, no big deal either. I don't want to goo too much off topic, but I'm biased towards manufacturer-supplied EVs, on the basis of availability and support. Of course the Merkur is more useful for "real" usage, as it is a module, but it requires additional HW to program and access the serial, and many resources seem to be in German only. While I think that running on SOMs is very good for RIOT (it opens the door to wider scale deployments) I'm not sure if a SOM is so good as the main testing board for a CPU port. |
jcarrano
added
the
CI: ready for build
|
Do we really need >1 ack? |
Apparently not. The HTTPS certificate of the website at http://pinocc.io/ has expired, the sale link is broken, the linked support page is no longer available, activity in the forum seems to have faded in 2016, and I would be surprised to see tumbleweeds rolling there. I think it is pretty safe to say that the Pinoccio is no longer available and, thus, no off-the-shelf product. If I remember correctly, one conclusion of the maintainer assembly in Helsinki was to improve support for handling boards outside of RIOT's master, rather than trying to add support for every board out there. I'd say the evaluation board of the ATmega256RFR2 is a good candidate for inclusion, and the Jiminy and Pinoccio are good candidates for out of tree support. |
I'd say yes, as we are not following the standard deprecation process here. Maybe @dylad can give the second ACK, as he suggested to drop support of the board? |
Agree 100%. For these things, always go for the better established, highest volume suppliers. |
maribu
removed
the
Discussion: RFC
|
@dylad: Added the entry. ACK and merge? |
maribu
changed the title
Contribution description
This PR drops support for the Jiminy-Mega256RFR2 board
Reasoning
==> The Jiminy is matching none of the above
Testing procedure
I think that the CI will do enough testing in this case.
Issues/PRs references
PRs that are (or have been) waiting for someone with the Jiminy to test: #11366, #11923, #11190, #11122, #11039, #11027, ...