Hi Ludwig!
On Tue, Aug 09, 2016 at 02:30:25PM +0200, Ludwig Knüpfer wrote:
> Without any further insights I would say your case is different because the
> board is actively maintained, used, and can be bought.
> In the case of the FU boards I had in mind (msb430*) none of these points is
> true.
[ek-lm4f120-xl board can't be bought anymore, only its replacement TivaC can
(and it is not supported by RIOT, at least at the moment)]
It is actively maintained... sort of. I have the feeling that no RIOT developer
has time for it. It is not listed on the RIOT wiki and it is hard to find
someo
Hi,
Without any further insights I would say your case is different because the
board is actively maintained, used, and can be bought.
In the case of the FU boards I had in mind (msb430*) none of these points is
true.
Cheers,
Ludwig
Am 9. August 2016 14:21:44 MESZ, schrieb Marc :
>Hey,
>
>This
Hey,
This discussion is also related to
https://github.com/RIOT-OS/RIOT/pull/5412#issuecomment-237688208
I'm trying to enhance support for ek-lm4fxl-120 board, which is not as popular
as stm boards...
It's a bit complicated to find reviewers with some extra time for reviewing,
and even more for
Hey!
On Tue, Aug 09, 2016 at 02:06:07PM +0200, Ludwig Knüpfer wrote:
> I'm all for cleaning up stale boards, especially I'd they are as hard to
> obtain as for example the FU boards.
Well, hopefully this situation is about to change once the RasPi
infrastructure is in place.
Cheers,
Oleg
--
Yo
All of them?
Am 9. August 2016 14:11:12 MESZ, schrieb Martine Lenders
:
>Hi Ludwig,
>well at least the FU boards are now "obtainable" through the IoT-Lab
>testbed. ;-)
>
>Cheers,
>Martine
>
>2016-08-09 14:06 GMT+02:00 Ludwig Knüpfer
>:
>> Hi,
>>
>> I'm all for cleaning up stale boards, especially
Hi Ludwig,
well at least the FU boards are now "obtainable" through the IoT-Lab
testbed. ;-)
Cheers,
Martine
2016-08-09 14:06 GMT+02:00 Ludwig Knüpfer :
> Hi,
>
> I'm all for cleaning up stale boards, especially I'd they are as hard to
> obtain as for example the FU boards.
> If I'm not mistaken
Hi,
I'm all for cleaning up stale boards, especially I'd they are as hard to obtain
as for example the FU boards.
If I'm not mistaken this would also enable the removal of at least one legacy
driver interface (I have some GPIO API in mind).
Cheers,
Ludwig
Am 9. August 2016 13:52:56 MESZ, schri
I agree with dropping qemu-i386
On the same subject, would it make sense to clean up some other boards
with less than ideal support?
chronos is one board which I frequently run into trouble with because
it is never up to date with the other platform implementations,
especially the stdio is very ha
We should drop a hint somewhere that these boards did exist once
so that interested people can pick up the work from git's history.
On 08/09/2016 01:03 PM, Oleg Hahm wrote:
Hi!
On Tue, Aug 09, 2016 at 10:34:19AM +0200, Martine Lenders wrote:
we now have the third person wondering about the q
Hi!
On Tue, Aug 09, 2016 at 10:34:19AM +0200, Martine Lenders wrote:
> we now have the third person wondering about the qemu-i386 port.
For the record: I count only two.
Otherwise: +1 for the proposal.
Cheers,
Oleg
P.S. Should we drop support for the Spark as well?
--
I'm working on a bittorr
Am Tue, 9 Aug 2016 10:34:19 +0200
schrieb Martine Lenders :
> we now have the third person wondering about the qemu-i386 port. Fact
> is, it doesn't work (we do not even have the unittests activated
> anymore). Is there a reason why we did not drop it yet (except making
> all the good work by René
Hi,
we now have the third person wondering about the qemu-i386 port. Fact
is, it doesn't work (we do not even have the unittests activated
anymore). Is there a reason why we did not drop it yet (except making
all the good work by René void)? Or are we planning to provide better
support for it in th
13 matches
Mail list logo