Hello,
Since our older flash chips have 256KB erase sectors, we could never use
the FTL as the erase buffer would have not fit the available ram of the mcu.
So we've always used our own driver, which is directly wrapping an mtd
device with ioctl calls. And it works, so we're not going to chan
Hello,
Can this be wired in the GPIO system?
There are gpio interrupts iirc. these could be used to trigger a signal.
If a system does not have gpio interrupts, polling can do the same trick.
Just my two cents!
Sebastien
On 09/07/2025 15:16, Alan C. Assis wrote:
Hi Everyone,
Some years ag
Hello,
I have already suggested that before and I insist this is a serious
proposal:
* Reduce the number of commits that enter nuttx upstream main branch
each day.
There are several methods to do that, associated with different states
of comfort and different technical solutions.
Sebasti
Hello
If you are in a hurry you can use another pico as picoprobe
https://mcuoneclipse.com/2022/09/17/picoprobe-using-the-raspberry-pi-pico-as-debug-probe/
I find that quite cool.
Sebastien
On 14/04/2025 14:09, Alan C. Assis wrote:
Hi Kevin,
I will order a Pico Debug probe, it is something
Great, thanks for the precision.
I still wonder about the increased flash use but it is still possible to
improve that later.
+1
Sebastien
On 14/04/2025 15:58, Xiang Xiao wrote:
The functionality in system/dd and nshlib is unsync, this patch:
1. update system/dd to get the same functio
Hello
1 - code duplication has never been rejected in nuttx
2 - it hurts no one since each of them can be selected individually.
My vote: Do nothing unless you actually justify the real life problem
you're facing that requires this.
Ideally: -1 because that's just cosmetics.
But I know you
I dont see this announced on the mailing list
Sebastien
On 14/04/2025 13:43, alin.jerpe...@sony.com wrote:
Hi Alan,
12.9 is already released
I will prepare a 12.9.1 release ASAP
Best regards
Alin
Från: Alan C. Assis
Skickat: den 14 april 2025 13:25
Till: d
There was no diatribe this time. I had the same single argument the
whole time: for long term self compatibility, we can not change the
behaviour of existing critical code. That's what matter.
We just added the complete deletion idea later.
The addition of new, well specified CRC routines is v
meone asks about the implementation
of crc16, you can reply to them as soon as possible instead of
hiding behind emails.
I won't reply to any messages from you anymore, I wish you all the
best, thanks.
BRs,
Sebastien Lorquet 于2025年4月9日周三
17:17写道：
Wh
code-modification proposal to pass."
Sebastien
On 09/04/2025 10:20, chao an wrote:
I like your second option, so could we remove the implementation of
both crc16/crc16part interfaces and rename to
crc16xmodem/crc16xmodempart?
BRs,
Sebastien Lorquet 于2025年4月9日周三 16:00写道：
He
Hello,
once again, the number of usage is unimportant and irrelevant.
The ONLY thing that matters is that when I call function POOP, it always
does POOP. Not something else.
Because users you are unaware of expect this function to do POOP and
they may not be able to change their code.
If y
I Maintain, DO NOT CHANGE THE DEFAULT CRC ROUTINE.
No. The open source project provides the ability for proprietary forks to
override the master branch default with the company default. Your approach
stalls the development process. A trivial change like this should not take
a week to commit.
Hello,
Nathan proposal to have a kconfig, with a default to the historical
algorithm, is a good solution.
I Maintain, DO NOT CHANGE THE DEFAULT CRC ROUTINE.
CRCs are relied upon for data structure integrity validation.
If you change the default, new code will consider valid data record as
e spending a lot of time trying to figure out why existing
code is not working and end up discovering that the issue is the CRC
incompatible with Linux or other OS.
If breaking API is an issue, we could propose these modifications to the
next major version (version 13).
BR,
Alan
On Mon, Apr 7,
Hello,
This rename:
- breaks several build you had to fix incrementally
- it fixes nothing not the name.
The modlib name is unfortunate but I think we can live with it.
Also why is the commit showing the name as "ELF" and not "LIBELF"?
That is not acceptable for me. Also -1.
However, I
hub.com/freebsd/freebsd-src/blob/main/sys/libkern/crc16.c
Linux:
https://github.com/torvalds/linux/blob/master/lib/crc16.c
So I want to convince you further, I think this is better for the future
development of NuttX
Sebastien Lorquet 于2025年4月7日周一 21:19写道：
Hello,
Compatibility with other OSes in
There was a lot of comments in the github and I may have missed the
whole of it.
Your information was reassuring, I am not opposing it anymore.
Care is being taken about this issue, that is the most important of all.
Sebastien
On 07/04/2025 15:35, chao an wrote:
@ Sebastien Lorquet
Hello,
Compatibility with other OSes in this domain is dubious.
What is the actual need for cross-OS crc16 compatibility?
Self-compatibilty is much more important. What is a non volatile storage
structure was created by the old CRC (old release) is checked with the
new CRC?
This will be an
Hello,
I agree that for compacity, reintroducing the possibility to disable the
VFS entirely would be quite interesting.
That is a large challenge!
Sebastien
On 24/03/2025 20:38, Alan C. Assis wrote:
Hi Tim,
Yes, these suggestions make sense!
I think for NXBoot should be nice to have the
Hello,
I also dont have a github account (anymore), also for reasons.
If you contribution is small enough (like a few lines) you can just show
it on the mailing list and people with a github account may pick it up
when they have time.
Or send a git patch that would be easy to apply for peopl
omatic pipelines either, this compliance should
be manual work.
My previous questions were to clarify the community agreed style.
I aim to improve the existing tooling, with minimal change on the actual
kernel/apps/c codebase as possible.
On Wed, 19 Mar 2025 at 11:44, Sebastien Lorquet
wrote:
I wil
e/nuttx/blob/master/INVIOLABLES.md#clear-consistent-standardized-coding-style
From: Nathan Hartman
Sent: Wednesday, March 19, 2025 6:03 AM
To: dev@nuttx.apache.org
Subject: Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
On Wed, Mar 19, 2025 at 5:45 AM Sebasti
t to
change
the style at all. The current style was chosen by Greg and we should
respect that :)
śr., 19 mar 2025 o 14:05 Nathan Hartman
napisał(a):
On Wed, Mar 19, 2025 at 5:45 AM Sebastien Lorquet
wrote:
(snip)
Messing *all* developer working copies with huge diffs just for code
formatting i
I will just tell one generic thing:
Please just dont push commits just to change the code style globally.
What is written is written.
Messing *all* developer working copies with huge diffs just for code
formatting is a no-go. This will prevent bissections and backports.
Define some relevant
Hello
For me the wrong is not to change, but to break the old working thing.
The old IOCTLs can be maintained. Either by design, or as a config
option like CONFIG_WLIOC_ENABLE_LEGACY with default yes.
That would work for me, I think, as it would allow running old code
without changing it (or
Hello,
I suggest people have a look at the RF interface that was rejected when
I suggested it.
Just to see if that could contribute something to the proposal.
There was ONE upper half driver with an unified ioctl interface for all
radio devices.
https://git.sr.ht/~f4grx/hn70ap/tree/main/i
Thanks for this message.
I have reviewed the pull request and I approve these changes given the
described context.
The tests coverage looks good.
I suggest a short notice in the release notes *summary* (that will be
read by more people), as historical information for future users that
could
On 27/02/2025 13:53, Filipe Cavalcanti wrote:
1. Contributing Guidelines with hints for Reviewers.
We are adding additional section for Reviewers to Contributing
Guidelines in order to provide checklist and complementary set of
rules that should filter out breaking code as much as possible a
Hello,
Same, negative vote *in this state*.
The idea of LTS releases is extremely useful and important but I believe
it needs a little more organization and time.
Let's first implement everything that is being decided in the other vote
first.
Depolyable Automated Hardware testing is also v
Hello,
The pico sdk allows changing the speed dynamically.
I've had one run stable at 400 MHz for a frequency counter project,
executing from RAM, not from flash. It required pushing the core voltage
to 1.30V. The stuff does not even heat, and I did not check power draw.
USB serial was still
how to find it now :)
Probably the best approach is to support both a network interface for
the radio and a character device. Similar to what is currently the case
with CAN bus. Both approaches have their applications and use cases.
czw., 13 lut 2025 o 09:54 Sebastien Lorquet
napisał(a):
Hell
Hello
the hardware and driver are cool.
However, if this driver is accepted, I will be very mad, as several
years ago, I built a complete radio transceiver driver framework based
on character devices (for the si4463, using a lower/higher half
approach, and it was fully working), and this was
avoid that some PRs
that don't reach the maximum number of reviews be allowed to be merged.
Typically, those who are most eager to impose new rules are not the same as
those who are subject to them!
BR,
Alan
On Wed, Feb 12, 2025 at 2:55 PM Sebastien Lorquet
wrote:
Again, I will vot
Again, I will vote against this. Not that it matters if a majority wants
to approve it.
This is a bypass of all other rules we're trying to enforce.
If such situation arise, there are two cases:
- either the submitter still cares and will yell at people to get it
approved
- either it will b
source SBOM (json file) file will be provided together with the download
link and will provide insight on our fill source code and license
a build SBOM (json file) will be generated after a build containing only
the code that was compiled on that device
@Sebastien Lorquet I understand your
Hello
I have an absolutely neutral position on this issue.
We dont use sboms.
but maybe in some future we might be required to provide it. However I
dont have any clue of that happening in the near or mid future.
What does it look like? It's just a static file somewhere, right?
Sebastien
O
Hi,
Thanks for the call.
The change looks reasonable as far as I am concerned.
It looks like it increases memory usage a little bit, but it's not dramatic.
I dont know if we have policies regarding memory usage statistics.
Micropython is quite strict about this.
Someone should double-check
What is the goal of lazy consensus? Faster merge? This is what we are
trying to prevent I think.
I promise you, if there is a loophole in the process, it will be exploited.
Better start strict and keep some room to adapt if we find problems,
than allowing an absence of review from the very st
Hello,
I agree. Only bugfixes, criticity threshold to be determined, but new
features seem unnecessary to me.
Sebastien
On 11/02/2025 12:43, Tiago Medicci Serrano wrote:
Hi,
I would make the scope even more restricted. Considering an LTS should be
100% compatible with an existing defconfig
Hello,
I am adding a negative opinion to this.
Lazy consensus is exactly what lead to absence of any testing and breakages.
If something is not looked at, it MUST NOT be integrated silently. It
must be delayed until someone looks at it.
If no one acts, the mailing list can be called for acti
Being cheeky here, but these are only good if we enforce these, and if
they are actually enforceable :) Self-certification is considered a joke
in many industrial places :)
Also, as an open source project, we are protected by the apache licence,
which says that we offer no warranty.
The euro
Hello,
This is an excellent idea.
How will we manage maintenance of these LTS releases? Some fixes are
likely to require some backports?
Sebastien
On 11/02/2025 09:54, Alin Jerpelea wrote:
Hi all,
there have been suggestions that we should create LTS releases
I propose that we mark every
Hello,
Thank you a million Tomek for having summed up everything.
1 +1
2 +1
3 +1
4 +1
5 +1
6 +1
7 +1
8 +1 same PR but different commits maybe?
9 +1 make sure tests are relevant to the function being tested and
provide useful coverage of the fix/feature.
10 +1 with allowing managed exc
Could we put that in a wiki so may people can edit every point, until
it's complete?
Sebastien
On 10/02/2025 17:18, Alin Jerpelea wrote:
Hi Sebastian,
don't you think that such checklist would help identify the issues and help
us fix them?
Best regards
Alin
On Mon, 10 Feb 2025,
It looks like a good start. I really hope this tool will also be usable
with the future hardware testing farms.
Testing on riscv qemu is certainly important as it will provide info
about some kinds of regressions, but it is far from sufficient.
Thanks for this work.
Sebastien
On 08/02/2025
Hello
I have obvious concerns that I will not repeat here.
We could apply to this once the current management issues are resolved,
as I think they will.
Sebastien
On 10/02/2025 10:12, Alin Jerpelea wrote:
Hi all,
I was considering to apply to the Open SSF Best practice badge
https://www.b
Hi,
a bit of a summary of the 10 previous messages
NDTS: NuttX Distributed Test System
NDHT: NuttX Distributed Hardware Test
nuttx-hwtest as we already have nuttx-apps
It's not original, I know lol
citest config: I suggest to keep citest and hardware test absolutely
separate. You want to b
Hello Alan, and Tomek,
Is this a good rule?
I have the feeling that any pull request could come with unexpected
problems, and if no one reviews it, it does not mean that the problems
are going away.
As suggested by anchao in previous emails, this is what happened in the
spinlock issue. No o
I can test
-nucleo-H743ZI (MB1137 B-01)
-nucleo-H743ZI2
-STM32F492I-disco (MB1075 B-01 it has peripherals and external RAM)
-STM32L1 discovery (MP963 C)
-ESP32 devkit
-raspberry pi pico
-raspberry pi pico 2
-our custom boards using STM32F429, STM32H743ZI
I will consider acquiring more boa
Tomek,
Regarding this pull request:I'm trying to test it quickly on our
STM32F427 based board, I cant pull the jtag probe before monday.
I have checked out the apache_8 branch of
https://github.com/hujun260/nuttx/tree/apache_8
-the tools/process_config.sh file is still broken, I could work
Hi,
On 06/02/2025 10:00, raiden00pl wrote:
Chips with the same architecture use the same code,
so when we test a more advanced chip, we also test the code for a less
advanced chip.
Same code on slightly different chips is interesting because it
underpins the least documented differences betwe
Hello,
On 05/02/2025 15:43, chao an wrote:
I just want to solve them. I know it's difficult for every developer. So if
you come across similar issues, you
don't need to spend too much time trying to solve them on your own.
Yes, I understand very well, but fixing too fast can lead to bugs
elsewh
in
this domain, redesign it carefully on your own code fork, and then push a
final working version to nuttx.
I'm also really grateful for your advice. I believe everything is getting
better.
BRs,
Sebastien Lorquet 于2025年2月5日周三 22:01写道：
Hi,
On 05/02/2025 13:03, chao an wrote:
I talked
I would say testing as much as possible is always a benefit.
I have worked for more than 15 years as an embedded specialist managing
mission critical code, and every bug we found later in the project was
in a test gap.
As my boss usually say, "If it's not tested, it doesnt work" and this
has
Hi,
On 05/02/2025 13:03, chao an wrote:
I talked with
Xiaoxiang in WeChat before.
This is not an Apache Project communication channel, so it does not
exist as far as we are all concerned.
These changes MUST be tested in a separate code branch so all platforms
can be tested and validated f
Hello Xiaomi dev team,
If I understand correctly spinlocks are basically a no-op when no SMP is
involved, which is the majority of CPUs supported by NuttX. You shall
not break all platforms.
I urge you all to revert any commit that might have broken something in
this domain, redesign it care
Hello,
I respectfully suggest to reduce the required hardware development to
the absolute minimum otherwise it will never move forward in a
satisfactory manner.
Many devboards can be flashed over usb and provide an UART.
IMHO it represents a sufficiently complex first step towards hardware
Great news, now that the build errors are sorted out, we are greeted
with the
* * * r u n t i m e e r r o r s * * *
the binary does not even start. it's stm32f429.
tomorrow is jtag day.
THIS IS FINE. I AM CALM. NO PROBLEM. I AM HAPPY.
Sebastien
On 04/02/2025 11:59, Sebastien Lo
lp us
stop this mess :-(
Tomek
On Tue, Feb 4, 2025 at 10:50 AM Sebastien Lorquet wrote:
I dont have a github account, this website looks like it is very
important for you. you keep mentioning it at every occasion.
linkage of nuttx and apps repo is a problem and I think more efforts
should be
/board/src'
make[1]: *** [Makefile:184: board/libboard.a] Error 2
make[1]: Leaving directory
'/home/slo/Sources/product-env/nuttx/arch/arm/src'
make: *** [tools/Unix.mk:552: nuttx] Error 2
Sebastien
On 31/01/2025 20:24, Tomek CEDRO wrote:
On Fri, Jan 31, 2025 at 6:01 PM Seb
Hello
The other thread made the remark that this pull request was merged
https://github.com/apache/nuttx/pull/15437
However it appears that it was undocumented.
this problem was noticed by the ai bot
shortly after this it was approved by two people and merged
this is a breach of your own rul
The damn AI bot said:
*In short, the PR needs significant improvements before it can be
considered for merging.* It needs to be more thorough and provide the
necessary information for reviewers to evaluate the change effectively.
Follow the template more closely and fill in all the required se
I agree, here is an example change I had to do:
int itf_bring_up(int sd, struct ifreq *pifr)
{
int ret;
- pifr->ifr_flags = IFF_UP;
+ IFF_SET_UP(pifr->ifr_flags);
ret = ioctl(sd, SIOCSIFFLAGS, (unsigned long)pifr);
if (ret < 0)
{
@@ -263,7 +263,7 @@int itf_bring_up(
side quests lol
Sebastien
On 31/01/2025 17:25, Nathan Hartman wrote:
On Fri, Jan 31, 2025 at 7:50 AM Tomek CEDRO wrote:
On Fri, Jan 31, 2025 at 1:41 PM Sebastien Lorquet
wrote:
Of course I also tried with the commit before that one, and it didnt
work either.
Sebastien, did you try the
nterface like POSIX must be stable,
which is obvious. But POSIX doesn't define everything, especially when
it comes to embedded systems.
pt., 31 sty 2025 o 17:30 Sebastien Lorquet
napisał(a):
hello
My proposal is:
1) define how the app build system is invoked and never move that
2)
in the inviolables... (I did not check)
Sebastien
On 31/01/2025 16:20, Tomek CEDRO wrote:
On Fri, Jan 31, 2025 at 3:35 PM wrote:
On 2025-01-31 13:48:32, Tomek CEDRO wrote:
On Fri, Jan 31, 2025 at 1:41 PM Sebastien Lorquet wrote:
Of course I also tried with the commit before that one, and it
Dont loose too many time, reversing the commit already fixed the problem.
Or I'll charge you my own time :)
I think the two cancel anyway :)
It's a stm32f429 cpu, so you have all the stm32 "common" board stuff
inbetween.
host is debian 12 or wsl.
the problem happen just when running configu
Hi,
On 31/01/2025 15:07, Tomek CEDRO wrote:
On Fri, Jan 31, 2025 at 2:54 PM Sebastien Lorquet wrote:
On 31/01/2025 13:56, Tomek CEDRO wrote:
Can you please report that Issue on GitHub? 🙂
I dont have github accounts anymore.
The mentioned commit was part of PR
https://github.com/apache
On 31/01/2025 13:56, Tomek CEDRO wrote:
Can you please report that Issue on GitHub? 🙂
I dont have github accounts anymore.
It's a custom board, we're not shipping devboards in industrial access
control.
Sebastien
wsl so something cursed like that.)
Sebastien
On 31/01/2025 13:23, Tomek CEDRO wrote:
I have this problem on BSD too and need to replace with gsed (GNU Sed
variant). Would be nice to fix :-)
Tomek
On Fri, Jan 31, 2025 at 11:30 AM Sebastien Lorquet wrote:
After git bisect over more than 2000
On 31/01/2025 13:16, Tomek CEDRO wrote:
On Fri, Jan 31, 2025 at 10:30 AM Sebastien Lorquet wrote:
Many problems arise when the nuttx and nuttx-apps are not in sync.
I always keep its masters in sync.. if there is no info on the website
we need to update documentation :-)
This is not
Reverting this does not seem to be a problem at all and fixes my problem.
Why was this added in the first place?
Maybe it increased some developer metric to show how productive they are.
We'll never know.
Sebastien
On 31/01/2025 11:29, Sebastien Lorquet wrote:
After git bisect over
rces/ccv5-env/ccv5/board/src »
make[1]: *** [Makefile:184 : board/libboard.a] Erreur 2
make[1] : on quitte le répertoire
« /home/slo/Sources/ccv5-env/nuttx/arch/arm/src »
make: *** [tools/Unix.mk:552 : nuttx] Erreur 2
Sebastien
On 31/01/2025 10:57, Sebastien Lorquet wrote:
Can you believe it?
After git bisect over more than 2000 revisions, I found that this commit
broke configure.sh for my board
slo@slolin:~/Sources/ccv5-env/nuttx$ git bisect good
27685aa179ad7608394fb8a97e11ef532888a75d is the first bad commit
commit 27685aa179ad7608394fb8a97e11ef532888a75d
Author: yezhonghui
Date
project deadlines.
dont be surprised that I dont trust nuttx anymore.
all your lengthy build tests are for nothing if you dont check and apps
and os work together all the time!
Sebastien
On 31/01/2025 10:30, Sebastien Lorquet wrote:
No rant here just facts, of the kind that makes my he
No rant here just facts, of the kind that makes my head explode.
Many problems arise when the nuttx and nuttx-apps are not in sync.
This should not happen, because nuttx sort-of promises an os/app
separation, and I dont think it is actually enforced.
I'm not talking about internal interfaces
so thats how it's going to happen?
One small email from one of the one company that causes most of the
problem, no discussion, and that is done?
Think about that once again.
My idea at this stage is quite different.
Every large company wanting to push many commits into nuttx should have
a
Hello
On 1/30/25 08:05, Tomek CEDRO wrote:
For instance if Sebastien had his board attached to local CI machine
that builds and runs the master all the time it would be really easy
and quick to catch possible problems and fix them right away not after
one year. It may be even possible to catch c
ss and preferably has
experience
in managing distributed open source projects. I don't know if we have
such
a person in our group.
śr., 29 sty 2025 o 11:33 Sebastien Lorquet
napisał(a):
hi
On 29/01/2025 10:21, raiden00pl wrote:
Sebastian, so you're saying that you and your company
commits
coming daily is not a sustainable way to manage project.
but lets be honest. nothing will happen, right? I've been here for long
enough to be sure of that.
so I'm out.
this is good for you: I'll stop complaining.
Take care and good luck.
wt., 28 sty 2025 o 16:19 Tomek
my trust in nuttx is now hard to maintain.
Every day a DELUGE of commits (from xiaomi, this is a fact) is added to
the repository.
I am struggling to understand what happens in this project.
so many fixes are pushed, how is that even possible? this is a quicksand
project!
Also, how are su
Hello,
The way we did it for our product, was to copy a canned board and modify
it for our hardware.
The resulting config can be out of tree, which is useful, even more so
when you do a custom project that is not sold and cannot be bought by
others.
Usually we have a separate git repo wit
Hi,
If I happen to contribute again that is how you are going to get my
contributions, because I deleted all my github accounts in dec 2024 when
they forced copilot on everyone.
Everyone has to be ready for the enshittification of any large platform.
At my dayjob we already have a nuttx mirr
Hello,
On 1/2/25 23:52, Alan C. Assis wrote:
Hi Yousif,
This is the kind of feedback we like to hear! Thank you for that!
NuttX is used in many areas including critical real-time applications.
So, if your question is: Is NuttX safe enough to be used in medical
application, the answer is YES!
24, at 08:19, Alan C. Assis wrote:
Hi Sebastien,
I think you raised a legitime (and important) concern.
Who could tell us if this usage of the fediverse is fine or not?
Maybe some optimization could be done to avoid sending too many messages.
BR,
Alan
On Sat, Dec 28, 2024 at 6:31
Hi,
You know me I'm not an easy person.
If the solution to being spammed by email notifications is to instead
spam the fediverse, then this is a Very Bad Idea (c)
The solution is instead to reduce the number of useless notifications so
your emails looks less like spam. eg buils successes sho
Hi,
the problem you demonstrate exists in the code below, but it's a coding
bug. it's missing the signed cast to compare wrapping variables.
It is well known that to compare counters that can rollover/wrap, the
subtraction to check if the timer has elapsed *must* be using signed
arithmetic.
should be handled, and it's not always possible to move to
64 bits timestamp easily.
Thats all.
Sebastien
On 04/11/2024 16:38, Sebastien Lorquet wrote:
What could possibly go wrong in existing apps, I wonder.
Changing the signedness of such an important variable to remove ONE
warning a
What could possibly go wrong in existing apps, I wonder.
Changing the signedness of such an important variable to remove ONE
warning at the risk of breaking NUMEROUS systems is insane.
Dont tell me everyone uses 64 bits. Many systems will still use 32 bits
for legacy reasons. Now if they upda
have and it doesn't look like it will get any
better.
Although verification of simple changes has been greatly improved recently
thanks to Lup,
so one-line PRs affecting certain parts of the OS (like boards and archs)
should be much faster to verify.
śr., 23 paź 2024 o 10:06 Sebastien Lorquet
Hi,
Maybe I'm not the only one thinking that more than 6 hours of build
checks for one-liner pull requests is excessive?
More so when said hours of work test nothing of the actual effect of
these changes.
:):):)
Sebastien
On 22/10/2024 15:49, Alan C. Assis wrote:
Hi Nathan,
Thank you f
Looks like a cool chip, have a look:
https://ww1.microchip.com/downloads/aemDocuments/documents/MPU64/ProductDocuments/Brochures/PIC64GX-Product-Family-5500.pdf
Sebastien
the proper thing to do is close these
bogus requests and ask contributors to fill actual required information.
Was the use of ai discussed and voted by the project? No need, I'll be
the only one against it?
Sebastien
On 01/10/2024 13:01, Tomek CEDRO wrote:
On Tue, Oct 1, 2024 at 10:
to write new code. Specifically if it's now AI reviewed.
But I will be able to run test code of your choosing on a raspi pico or
nucleo-l432kc
Sebastien
On 13/09/2024 22:43, Sebastien Lorquet wrote:
Hello,
Thank you for the additional information, of course I understand the
gsoc had
Yikes
Sebastien
On 9/29/24 00:27, Lee, Lup Yuen wrote:
We're experimenting with an LLM Bot (Large Language Model) that will review
NuttX Pull Requests. This article explains how we created the LLM Bot in
One Week:
(1) We call GitHub API to fetch NuttX Pull Requests
(2) Append the PR Body to th
Hello,
I am vey pleased to see a serious non commercial project being
interested in NuttX.
I hope you enjoy it.
I have hacked some code for the si4463 radio chip.
Sebastien
On 26/09/2024 00:36, Matteo Golin wrote:
Hello everyone,
My name is Matteo, and I am a lead on Carleton University'
Hi,
A friend of mine just showed me this language: Cello.
Usually I hate aliens NIH languages, BUT
This one is implemented entirely in C, using preprocessor magic and a
small runtime.
It provides a lot of functions to make C much safer for people that are
worried about C safety.
In no way
Hello,
Thank you for the additional information, of course I understand the
gsoc had to be completed in a limited time, and the current code is a
prototype.
I think it will be cool if we manage to make it production quality for
all users of the nuttx codebase.
I will probably send my farne
we just need to understand how to use SPI NAND,
FTL, MTD,
> etc.
>
> Xiang, since you and your team ported YAFFS to NuttX, maybe you
guys could
> help us to get MnemoFS working on real flash on NuttX.
>
> BR,
>
> Alan
>
>
NAND,
FTL, MTD,
etc.
Xiang, since you and your team ported YAFFS to NuttX, maybe you
guys could
help us to get MnemoFS working on real flash on NuttX.
BR,
Alan
On Fri, Sep 13, 2024 at 6:17 AM Sebastien Lorquet
wrote:
> Hello
>
>
1 - 100 of 315 matches
Mail list logo
