On Wed, 8 Mar 2023 at 09:55, Alan C. Assis wrote:
>
> Sebastien,
>
> If all the discussions that happens on github start to happen here,
> this mailing list will be just like the nuttx-commits mailing list.
I'll take this as sarcasm. Sebastien is making a lot of valid points,
in good faith, and b
On Wed, 8 Mar 2023 at 13:16, Alan C. Assis wrote:
>
>
> Welcome back go NuttX Lwazi (I'm not been sarcastic, I'm happy to hear
> from you again! You have a great knowledge of BLE can we need! I was
> expecting you to share that working example of BLE application using
> our BLE stack).
>
Thanks, I
ssis wrote:
>
> Hi Lwazi,
>
> I don't know about CC2564, but BLE Stack was working recently to
> ESP32, ESP32C3, nRF52, etc
>
> Is it related to this issue: https://github.com/apache/nuttx/issues/8767
>
> BR,
>
> Alan
>
> On 3/9/23, Lwazi Dub
Hi,
I don't have a newline in my format string but it gets added anyway.
This is a bug. I need to use a loop to print several bytes on the same
line.
Is there a reason why this is forced on everyone ?
if (stream.last_ch != '\n')
{
lib_stream_putc(&stream.public, '\n');
ret++;
On Sat, 8 Apr 2023 at 14:46, Victor Suarez Rovere
wrote:
>
> So isn't GCC POSIX compliant? I mean a static build of gcc executable and
> nothing more (no make, awk or anything)
> The only thing that GCC does is read and write files
> The C library shouldn't be part of the equation since GCC can co
Alan,
Can you summarize? I have not been following this PR. Is make going away?
Thanks,
-Lwazi
On Fri, 19 May 2023 at 11:47, Alan C. Assis wrote:
>
> Hi Everyone,
>
> While PR #6718 is waiting to get merged, please take a look:
>
> https://makefiletutorial.com
>
> BR,
>
> Alan
On Fri, 19 May 2023 at 13:51, Alan C. Assis wrote:
>
> Lwazi, I think Greg summarized it well.
>
Yes, and Maciej too. Thanks
Hi Stewart,
Take this with a grain of salt. I have never used the ioexpander ... took a
quick look after seeing your email.
You need to populate ioexpander_ops_s within your board specific files.
IOEXP_WRITEPIN is the "virtual function" that calls your board specific
write_pin function (which call
It is a typo. Please change to DIRSEC_NDXMASK(f)
There are no errors because fs is already available in every function that
"calls" DIRSEC_BYTENDX.
On Fri, 2 Feb 2024 at 11:55, Saurav Pal wrote:
> Hi Alan,
>
> Thank you for looking at our code base and planning to add Documentation,
> > that is
On Mon, 15 Jul 2024 at 14:30, Alan C. Assis wrote:
> Hi David,
>
> A quick way to test on your board is using version 10.2.0 while we fix the
> issue:
>
> https://nuttx.apache.org/download/
>
> This is the last version before the PR that introduced the issue.
>
> If you have good experience with
On Wed, 14 Aug 2024 at 18:07, Felipe Moura Oliveira
wrote:
> Hello all.
>
> I am porting MFRC_522 Driver to my esp32 board, during test process my
> firmware stuck in "while" and I am think about it (I was with hardware
> issue), look code below:
> When we use this driver, if we have any issue in
ederal de Minas Gerais*
> Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
> <https://twitter.com/FelipeMOliveir?lang=pt-br>
>
>
> On Wed, 14 Aug 2024 at 19:42 Lwazi Dube wrote:
>
> > On Wed, 14 Aug 2024 at 18:07, Felipe Moura Oliveira >
&g
On Wed, 28 Aug 2024 at 09:21, raiden00pl wrote:
> As Alan said `drivers/` should remain independent from `arch`.
> The clean separation of arch from the rest of the code is one of the nicest
> things about NuttX and it should stay that way.
>
I won't argue against clean separation, but why does
On Wed, 28 Aug 2024 at 11:43, raiden00pl wrote:
> I don't know what was the initial intention about `drivers/`, only Greg can
> answer this question.
> But what I see now is that `drivers/` implement `upper-half` drivers, and
> arch specific drivers implement "lower-half" drivers (there are proba
On Tue, 28 Jan 2025 at 13:30, Tim Hardisty wrote:
> Hi all,
>
> I am trying to get MCUboot to work on my custom board with a SAMA5D2
> (Arm V7A) and after a lot of battles am nearly there.
>
> I can boot into MCUboot stored in flash, and I can also download/debug it.
>
> MCUboot is happy enough w
On Tue, 11 Feb 2025 at 18:59, Peter Barada wrote:
> Tim,
>
> Common across bulk of ARM processors, the vector table starting at
> address 0x0 contains the 32-bit value of the stack pointer, address 0x4
> contains the reset vector (i.e. where to start execution in supervisor
> state) and then the
On Fri, 21 Mar 2025 at 12:47, Javier Casas Marin
wrote:
> Hi,
> We are using the FTL driver over a MTD device (flash memory at45db641e).
> When we write something to flash, eventually the ftl_flush function is
> called and it does an erase (MTD_ERASE) and then the write (MTD_BWRITE).
> But in the
On Mon, 24 Mar 2025 at 05:00, Sebastien Lorquet
wrote:
> Hello,
>
> I also dont have a github account (anymore), also for reasons.
>
What are "reasons"? Is this about AI training?
On Mon, 24 Mar 2025 at 04:50, Javier Casas Marin
wrote:
> In AT45DB161D chip, the Opcode 82H = Main Memory Page Program Through
> Buffer *also performs a built-in erase.*
>
> From the datasheet, section 7.8:
> "This operation is a combination of the Buffer Write and Buffer to Main
> Memory Page P
Too late. If I am reading the PR correctly, he has changed the subject and
we are back to the original default.
uint16_t crc16(FAR const uint8_t *src, size_t len)
{
return crc16xmodempart(src, len, 0);
}
He fought for a couple of days before giving up. I don't blame him. This
suggestion, which
this
> is "project management".
>
> We cant just throw any code we like in a large shared project. We're not
> just coding for ourselves at this point.
>
>
> Sebastien
>
>
> On 09/04/2025 17:58, Lwazi Dube wrote:
> > Too late. If I am reading th
On Wed, 9 Apr 2025 at 03:43, Sebastien Lorquet wrote:
> >
> >> 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 deve
On Tue, 8 Apr 2025 at 13:32, Xiang Xiao wrote:
> On Wed, Apr 9, 2025 at 1:16 AM Lwazi Dube wrote:
>
> > On Tue, 8 Apr 2025 at 05:23, Sebastien Lorquet
> > wrote:
> >
> > > Hello,
> > >
> > > Nathan proposal to have a kconfig, with a default to
On Tue, 8 Apr 2025 at 05:23, Sebastien Lorquet wrote:
> Hello,
>
> Nathan proposal to have a kconfig, with a default to the historical
> algorithm, is a good solution.
>
Kconfig will work if you mean this:
int16_t crc16(FAR const uint8_t *src, size_t len)
{
#if defined(CONFIG_CRC16_IBM)
retur
On Tue, 8 Apr 2025 at 14:49, Xiang Xiao wrote:
> On Wed, Apr 9, 2025 at 2:02 AM Lwazi Dube wrote:
>
> > On Tue, 8 Apr 2025 at 13:32, Xiang Xiao
> wrote:
> >
> > > On Wed, Apr 9, 2025 at 1:16 AM Lwazi Dube wrote:
> > >
> > > > On Tue, 8 Ap
atible, doesn't
> sacrifice performance/footprint, and allows for underlying HW
> implementation would be a good thing(tm). :-)
>
> On 4/8/25 13:58, Tomek CEDRO wrote:
> > On Tue, Apr 8, 2025 at 7:17 PM Lwazi Dube wrote:
> >> No. The open source project provides the abi
+1
On Mon, 7 Apr 2025 at 04:58, chao an wrote:
> Hi Community,
>
> I plan to switch the default CRC16 algorithm directory of NuttX from
> CRC-16/XMODEM to CRC-16/IBM:
> https://github.com/apache/nuttx/pull/16147
>
> CRC-16/XMODEM as the default implementation has significant limitations,
> espe
On Mon, 7 Apr 2025 at 18:21, Nathan Hartman
wrote:
> -1 from me also, but please read further:
>
> I would vote +1 if there is a Kconfig to select crc16 type, and
> current (backwards-compatible) type is default. This way, existing
> applications will not break suddenly, but developers who need
>
On Wed, 12 Feb 2025 at 13:10, Tim Hardisty wrote:
> Thanks Lwazi and Peter. By examining the data in the NuttX binary I have
> tentatively concluded that the binary, as stored as an MCUboot signed
> bootable image:
>
> * Has the 32 byte MCUboot header. This contains the address in RAM
> tha
29 matches
Mail list logo
