Hi Joakim!
> What is a suitable name for the new repo?
> I have been using "riotbuild" for my Docker development at
> https://github.com/gebart/riotbuild
I don't have any particular ideas for the name, so, for me "riotbuild" (or
"riotdocker") would be fine.
> Also, I need to have an organisatio
What is a suitable name for the new repo?
I have been using "riotbuild" for my Docker development at
https://github.com/gebart/riotbuild
Also, I need to have an organisation owner (Oleg, Kaspar, Emmanuel or
Matthias Wählisch) create the repo since maintainers do not have the
proper access to do it
Hi,
Am 23.02.2015 10:04 schrieb "Ludwig Ortmann" :
> are you suggesting macros are better than APIs + functions?
> If so, please explain why and what better means ;)
I was not sure if the compiler optimizes out empty functions, so I assumed
#define INFO(msg) (void)0;
to be the better solution c
Hi Hauke,
I have not consider the RIOT design guideline of reducing macro usage.
In this regard your solution is also for me much better.
The only (IMHO minor) advantage for using "complex" macro is little saving
in cpu cycles and stack memory usage.
ciao
Attilio
On Mon, Feb 23, 2015 at 11:35
Hi,
I got a hint from daviko, that they will include this option in their
next Linux release!
Cheers,
Hauke
On 16.02.2015 16:18, Ludwig Ortmann wrote:
Hi,
I just figured out how to enable echo cancellation for PlaceCam in Linux with
PulseAudio.
It is possible to PulseAudio configuration hi
Hi Ralph,
I would recommend the current version of the official arm-embedded
toolchain [1]. To my knowledge there are no known issues around this
toolchain and RIOT for Cortex-Mx microcontrollers...
Best,
Hauke
[1] https://launchpad.net/gcc-arm-embedded
On 20.02.2015 03:52, Ralph Droms (rd
Hi,
I really focused to this problem, because I do not have target to duplicate
code base only because here missing this “small” things ;)
From my side:
- logging API is good idea, it can by nice to have possibilities implement
logging to any output (stdout, file, net, etc.)
- macros can have s
Hi Attilio,
personally I think Macros might not be the best idea - one of the design
principles of RIOT so far is to limit the use of Macros to the minimum.
You can actually get the same results for the code below by using a
plain API based approach:
log_api.h:
void log_info(...);
implement
Hi Ludwig,
In my simple tinking the macro approach does not exclude the API, just a
pseudo code example:
API log_api.h:
...
void log.info(const char* fmt, ...);
...
#ifdef ENABLE_INFO
#define LOG_INFO(...) log.info(__VA_ARGS__)
#else
#define LOG_INFO(...)
#endif
In RIOT framework and appl
Hi Joakim,
+1 from my side!
Cheers,
Hauke
On 23.02.2015 09:35, Oleg Hahm wrote:
Hi Joakim!
I'm completely fine with that. Thanks for the effort!
Cheers,
Oleg
Am Mon, Feb 23, 2015 at 09:18:42AM +0100 schrieb Joakim Gebart:
I'd like to hear if anyone is strongly opposed to this, otherwise I
Hi Attilio, Martine,
are you suggesting macros are better than APIs + functions?
If so, please explain why and what better means ;)
Cheers, Ludwig
On Mon, Feb 23, 2015 at 09:26:34AM +0100, Attilio Dona wrote:
> Also for me the MACRO approach has to be considered in a design review,
> eventually
Hi Joakim!
I'm completely fine with that. Thanks for the effort!
Cheers,
Oleg
Am Mon, Feb 23, 2015 at 09:18:42AM +0100 schrieb Joakim Gebart:
> I'd like to hear if anyone is strongly opposed to this, otherwise I
> will go ahead and create a new repository tomorrow.
>
> Best regards,
> Joakim Ge
Also for me the MACRO approach has to be considered in a design review,
eventually in addition to a tracing API layer.
Just to add my bit of experience with RIOT about porting msp430 family on
new TI/redhat gcc 4.9:
the default nanolib bundled with the toolchain implies a big printf memory
usage,
Hello,
On Sat, Feb 21, 2015 at 8:06 PM, Ludwig Ortmann
wrote:
> Hi,
>
> On Sat, Feb 21, 2015 at 07:02:58PM +0100, Martine Lenders wrote:
>> This is why I propose we change to a slightly adapted topic branch workflow
>> (also known as feature branch) workflow [1]:
>>
>>- the main RIOT-OS/RIOT
Dear rocking IoTlers,
due to the embedded world this week, several maintainers won't be available
for this week's PlaceCam meeting. Hence, I have two questions:
1.) Is there anything urgent to discuss or can we skip the meeting?
2.) If we don't want to skip the meeting, is there anyone available f
I'd like to hear if anyone is strongly opposed to this, otherwise I
will go ahead and create a new repository tomorrow.
Best regards,
Joakim Gebart
www.eistec.se
On Sun, Feb 22, 2015 at 2:51 PM, Ludwig Ortmann
wrote:
> Hi,
>
> fine with me, thank you for the initiative =)
>
> Cheers,
> Ludwig
>
16 matches
Mail list logo
