Hi,
do you mind to create a pull request for it? This imho would make discussion of
the code easier. You can add [WIP] in the title to highlight it's work in
progress.
Cheers,
Marian
Am 27. Januar 2019 11:44:21 MEZ schrieb Federico Pellegrin :
>Hi,
>I did a mostly working (please see below for
Hi everyone,
this PR #9407 [1] is waiting for someone to test it on a Thingy:52 or a
RuuviTag. You'll need a current development version of OpenOCD in $PATH. Testing
will be as simple as running
make BOARD=thingy52 PROGRAMMER=openocd flash
make BOARD=thingy52 term
in `examples/hello_worl
Hi everyone,
> I seem to remember that we tried making sched_active_thread non-volatile
> at some point, breaking things, but that has also been a long time ago.
I think the reason might be that the compiler reordered access to the variables.
See C99 standard section 5.1.3 ยง5:
> The least requi
Hi,
I think the question is what mapping you want to have between a board (the
physical hardware) and a RIOT board. If the mapping should be 1:1, than one
physical board could have different CPUs and configurations.
If you however agree with a 1:n mapping, than having different RIOT boards for
ea
Hi,
I just opened a pull request to drop the jiminy-mega256rfr2 [1]. If you want
this board to remain supported, please drop a line there.
# Reasoning
## Inclusion policy
During the maintainer assembly in Helsinki I understood that our inclusion
policy is that a board needs to fulfill at least
Hi,
I'd personally go the vanilla version, but not for philosophical reasons. My
reasons would be:
- More consistent to other toolchains (no TI specific stuff)
- Does not rely on TI for future updates (in case TI looses interest in
maintaining their on version)
So +1 for vanilla GCC.
Kind reg
Hi,
are there still users of the board avsextrem? I'd like to create a PR to drop
support for it. I believe this is again a board with no users left.
Kind regards,
Marian
pgpaeW6SpGQ1y.pgp
Description: OpenPGP digital signature
___
devel mailing list
Hi,
If I remember correctly stdio in RIOT is not buffering at all, but pyterm is
buffering until \n. You might solve the issue by passing an additional flag to
pyterm or using a different terminal.
Kind regards,
Marian
Am 23. September 2019 11:55:51 MESZ schrieb smlng :
>Welcome Rik!
>
>withou
Hi,
see https://github.com/RIOT-OS/RIOT/pull/12537
Kind regards,
Marian
On Fri, 25 Oct 2019 16:06:02 +0200
Robert Olsson wrote:
> Hi,
>
> More questions on this topic... are there any PR pending for the
> radio integrated in the AtMega128rfa1 and AtMega256rfr2? Very much
> the same but not o
Hi Thomas,
> Also, a clear and falsifiable problem statement should be given.
could you elaborate on what you mean by a problem statement being falsifiable?
Do you want to be able to check that a given problem cannot be solved by
existing features?
> This should IMO address the question, why tim
Kind regards,
Marian
On Mon, 9 Dec 2019 20:35:24 +0100
"Thomas C. Schmidt" wrote:
> Hi Marian,
>
> On 09/12/2019 20:06, Marian Buschsieweke wrote:
>
> >> Also, a clear and falsifiable problem statement should be given.
> >
> > could you elabora
Hi,
I was just literally about to send an email with pretty much the same arguments
Kaspar wrote right now. So I skip them and throw in a +1 instead.
> Below that, context switching takes the bulk of the time, so spinning (not
> using a callback) is probably preferable.
I think that the ws281x d
Hi,
here are my thoughts on the discussion.
# Not Getting Lost in Requirement Analysis and Problem Specifications
A good requirement analysis is a valuable tool for both development and
evaluation of a software component. But once a solid understanding of the
problem to solve is reached, additio
Hi,
in order to push this forward I just opened a PR for an RDM at
https://github.com/RIOT-OS/RIOT/pull/12970. This PR is in an early state and
both feedback and help will be greatly appreciated.
> IMO, users should just not use these timer values as timestamps.
> That maybe needs to be stated a
Hi,
I just noticed that most of the ADC implementations providing their own
adc_res_t do not cover all values. The API documentation states that
adc_sample() should return -1 on unsupported resolutions. This indicates that
all possible resolutions have to be defined in any case, so that a user cou
hat. (I will also add the minimum resolution in that.)
Kind regards,
Marian
> Cheers,
> Hauke
>
> On 12/26/19 10:01 AM, Marian Buschsieweke wrote:
> > Hi,
> >
> > I just noticed that most of the ADC implementations providing their own
> > adc_res_t do not cover
and mark the result invalid.
> >
> > While touching this API, would it make sense to also change the return
> > type from `int` to `int32_t`? This would allow for 16-bit ADCs on 16-
> > and 8-bit platforms... Just thinking loud here :-)
> >
> > Cheers (and th
Hi,
every failing test indicates a bug. (From time to time the bug is found in the
test rather than in the code to test.) Feel free to open an issue for the
failing tests. I personally favor a tracking issue that lists each failing test
with a checkbox. It is motivating to tick them of one by one;
Hi,
> I was wondering if it is even possible at all. The current version of
> the PWM peripheral has its resolution limited to 256.
this is because currently only the 8 bit timers are used for PWM. There are
also 16 bit timers that can be used for PWM, but those are not yet implemented.
I heard
the missing PWM periph for
> the atmega-based Arduinos/". It sounds like PWM should work just fine on
> this board (unless RIOT handles arduino boards differently than
> non-arduino boards with the same cpu, but that sounds unlikely). Why
> would it suddenly not work anymore?
>
Hi,
I like the idea of alphanumeric identifiers. How about using `#define` or
a `enum` that map a alphanumeric token to the RIOT internal numeric identifier?
That way the strings come for free in terms of ROM usage. (But as a downside,
those strings would be hard to e.g. reuse from within the shel
21 matches
Mail list logo
