Article: Encode Sensor Data with CBOR
This article explains how we may encode Sensor Data with the TinyCBOR Library on NuttX... https://lupyuen.github.io/articles/cbor2 Up Next: Rust Embedded on NuttX :-) Lup
Re: Move to C99 for common code
I think that eliminating some older architectures would be a good thing. There should be some criteria for selecting those: - The should be minimal ports with no extensive development, - They should not be popular or have been popular. - They should not have extensive board support - They should have no value to the retro-computing community. There are several that meet these criteria: sh1, m16c, z8.
Re: Move to C99 for common code
In general yes, but my main point was that I saw designated initializer list heavily used in drivers code that is intended to be common. Also there are some C99 features like inline functions in common code. So we need to make an effort and clean-up common code to get back C89 compatibility. Best regards, Petro On Sun, Jan 9, 2022, 1:41 PM Alan Carvalho de Assis wrote: > On 1/9/22, Nathan Hartman wrote: > > On Sat, Jan 8, 2022 at 11:34 AM Alan Carvalho de Assis < > acas...@gmail.com> > > wrote: > > > >> I agree! There are few places where designated initializer list are used > >> in > >> the common code (in arch/ and boards/ they can be used without further > >> concern), so it can be fixed at no time. > >> > >> In the other hand this flexibility is the root causes for confusion, > >> mainly > >> for new contributors. It does appear orthogonal that part of the code > are > >> using C99/C11 and part are using C89. > > > > > > > > Architecture-specific code can use whatever that architecture's compiler > > supports and in some cases might even have to use special features or > > syntax. > > > > The question is only about common code. > > > > Common code that must work on all architectures is what has to be C89. > > That is what I said, but the point is: if NuttX mix C99/C11 in some > places in the source code tree and in other places it only accepts C89 > it creates confusion for people. > > All this discussion started when our colleague saw a designated > initializer list commit coming in a PR and thought it was forbidden, > but in fact it was legal because it was to arch/ directory. > > Following a single standard could avoid this kind of confusion, but > unfortunately we cannot move to C99 or newer until we have compilers > for old arch supported by NuttX. Also forcing C89 to arch/ and board/ > will require a huge effort to adapt those source code. So we have a > dilemma/catch 22. > > BR, > > Alan >
Re: Move to C99 for common code
On 1/9/22, Nathan Hartman wrote: > On Sat, Jan 8, 2022 at 11:34 AM Alan Carvalho de Assis > wrote: > >> I agree! There are few places where designated initializer list are used >> in >> the common code (in arch/ and boards/ they can be used without further >> concern), so it can be fixed at no time. >> >> In the other hand this flexibility is the root causes for confusion, >> mainly >> for new contributors. It does appear orthogonal that part of the code are >> using C99/C11 and part are using C89. > > > > Architecture-specific code can use whatever that architecture's compiler > supports and in some cases might even have to use special features or > syntax. > > The question is only about common code. > > Common code that must work on all architectures is what has to be C89. That is what I said, but the point is: if NuttX mix C99/C11 in some places in the source code tree and in other places it only accepts C89 it creates confusion for people. All this discussion started when our colleague saw a designated initializer list commit coming in a PR and thought it was forbidden, but in fact it was legal because it was to arch/ directory. Following a single standard could avoid this kind of confusion, but unfortunately we cannot move to C99 or newer until we have compilers for old arch supported by NuttX. Also forcing C89 to arch/ and board/ will require a huge effort to adapt those source code. So we have a dilemma/catch 22. BR, Alan
