Hi,
I just came back to the issue mentioned below, reviewing some of the
code. I think that things go wrong in many levels (and this will be
long, sorry about that):
- The patch mentioned below takes into use a common mtimer driver for
all the risc-v platforms. This is fine as a concept, but
Why not start the test infrastructure from sim/qemu? It's more simple to
set up and has unlimited resources. Once the sim/qemu test workflow is
ready, it isn't very hard to duplicate to the real boards.
On Tue, May 23, 2023 at 8:42 AM Alan C. Assis wrote:
> On 5/22/23, Tomek CEDRO wrote:
> > Th
On Tue, May 23, 2023 at 4:28 AM Xiang Xiao wrote:
> CWIKI mayn't be a good place since it requires that the user has an Apache
> account at least to make any change as far as I know.
> It's better to be tracked by a github issue.
That is more to keep RFC and administrative stuff documented.. anyon
CWIKI mayn't be a good place since it requires that the user has an Apache
account at least to make any change as far as I know.
It's better to be tracked by a github issue.
On Tue, May 23, 2023 at 9:27 AM Nathan Hartman
wrote:
> On Mon, May 22, 2023 at 8:44 PM Alan C. Assis wrote:
>
> > On 5/2
On Mon, May 22, 2023 at 8:44 PM Alan C. Assis wrote:
> On 5/22/23, Tomek CEDRO wrote:
> > On Tue, May 23, 2023 at 1:55 AM Alan C. Assis wrote:
> >> I think it is better to keep the documentation in a single place:
> >> https://nuttx.apache.org/docs/latest/contributing/index.html
> >> We're movin
On 5/22/23, Tomek CEDRO wrote:
> On Tue, May 23, 2023 at 1:55 AM Alan C. Assis wrote:
>> I think it is better to keep the documentation in a single place:
>> https://nuttx.apache.org/docs/latest/contributing/index.html
>> We're moving those documentations from confluence to our internal
>> reposit
On 5/22/23, Tomek CEDRO wrote:
> This is why I asked not that long ago about
> Software-Hardware-Support-Compatibility-Matrix.. this would be really
> big table with hardware boards in columns and features in rows with
> green marks (or +1) where full support is confirmed, yellow (or 0)
> meaning
On Tue, May 23, 2023 at 1:55 AM Alan C. Assis wrote:
> I think it is better to keep the documentation in a single place:
> https://nuttx.apache.org/docs/latest/contributing/index.html
> We're moving those documentations from confluence to our internal repository.
> So, that could be nice if you cou
On 5/22/23, Tomek CEDRO wrote:
> On Sat, May 20, 2023 at 2:12 AM Brennan Ashton wrote:
>> On Fri, May 19, 2023, 3:23 PM Tomek CEDRO wrote:
>> > I am thinking about this. "If it works don't fix it" comes to my mind.
>> > Current build system is amazingly simple coherent and fast. Building
>> > firm
On Sat, May 20, 2023 at 2:12 AM Brennan Ashton wrote:
> On Fri, May 19, 2023, 3:23 PM Tomek CEDRO wrote:
> > I am thinking about this. "If it works don't fix it" comes to my mind.
> > Current build system is amazingly simple coherent and fast. Building
> > firmware takes 17 seconds. Why change it?
This is why I asked not that long ago about
Software-Hardware-Support-Compatibility-Matrix.. this would be really
big table with hardware boards in columns and features in rows with
green marks (or +1) where full support is confirmed, yellow (or 0)
meaning work-in-progress, red (or -1) meaning no s
Checking different configurations is an academic problem, I think they call
it configuration sampling and it is part of variability modelling. There
were some papers about sampling of Linux configurations.
The simplest approach is to enable all possible, disable all possible, but
it is not trivial
On Mon, May 22, 2023 at 9:29 AM Sebastien Lorquet
wrote:
>
> If the untold reason is to speed up github tests, then run less tests.
> Do we really need to test build on 13 or 20 arm platforms when only one
> config of the other architectures is tested, and the actual value of
> these build test i
On Mon, May 22, 2023 at 5:02 PM Alan C. Assis wrote:
> Just a update from Espressif: probably ESP32-C5 will have USB OTG, but
> since it was not released yet we cannot confirm it (things can change
> before releasing the chip).
Thank You Alan!! :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Hi Tomek,
Just a update from Espressif: probably ESP32-C5 will have USB OTG, but
since it was not released yet we cannot confirm it (things can change
before releasing the chip).
They suggested that companies interested on get this information
should ask directly to the business support: sa...@es
Hello,
Build performance is not an argument. it's already very fast.
Integration with various tools is a case of "I dont like it", it's not a
good reason for such a fundamental change, it can be resolved with local
configurations.
I cant find any good reason to change except, maybe, complexi
Hi Sebastien,
There are good cons and pros arguments for moving to CMake.
Just like many here I don' t have preference for one or another, but
we need to analyze what is better for NuttX evolution and make a good
decision.
The main pros of moving to CMake:
1) It is easier to integrate with new
Hi,
First of all I need reliable communication with a particular brand of
card I cant disclose, and I dont think any certification is on the scope :)
But EMV certification is probably possible with a bit more dedication.
Usually the complexities are around timeouts, error behaviour, and a lot
I very much agree with all of these arguments.
Thats a too large disruption for too little benefits.
I dont want to be forced to use cmake.
Everything we use here to integrate NuttX is based on makefiles.
Why do we have to bring in yet another dependency? No, cmake is not
installed in our bui
19 matches
Mail list logo
