On 5/26/2024 5:03 PM, Stuart Ianna wrote:
With the riscv/litex port, we're able to access the TIME and TIMEH CSRs in
usermode. I would like to take advantage of this feature to replace the
proxies for syscalls, such as timer_gettime with an equivalent
implementation that avoids a context switch,
On 5/26/2024 8:10 PM, Stuart Ianna wrote:
Some of the integration at this level is going to be tricky, as Litex
customisations may not be risc-v generic.
The only guideline with this is that all RISC-V-and-Litex-specificlogic
needs to be constrained to reside in arch/risc-v/src or
Adding non-standard APIs would be not be a good decision for the
future of a standards compliant OS.
Sorry to respond again. Perhaps I am not understanding properly. Are
you proposing another set of APIs or instead proposing to replace the
standard APIs with a different implementation.
On 5/26/2024 5:03 PM, Stuart Ianna wrote:
With the riscv/litex port, we're able to access the TIME and TIMEH CSRs in
usermode. I would like to take advantage of this feature to replace the
proxies for syscalls, such as timer_gettime with an equivalent
implementation that avoids a context
There is some brief information about dhara here:
https://github.com/dlbeer/dhara . It is an FTL that provides many of the
features described previously:
* Wear leveling,
* Hardware/software EEC
It does not appear to do
* Bad block detection
* Marking of bad blocks
The nicest thing is
Seems like dhara.c was integrated into mainline, but they didn't submit
support to YAFFS (if I remember correctly it was because YAFFS requires
license payment for commercial usage).
There no references to either under fs/.
The YAFFS website is not responding. This is what I get about
> Mr. Greg Nutt implemented it for Atmel about 10 years ago, but if I
> remember correctly, he never got it well tested because there is no
FS for
> NAND on NuttX.
I did test the FS's that were available and they mostly worked on these
platforms. I could actually run nxffs and smartfs for a
On 5/9/2024 11:02 PM, Mark Stevens wrote:
Hmmm... the UART device will closed when the kernel thread is killed, right?
When the device is closed, it is also flushed I believe. If those two things
are true, then data loss would be expected, right?
Yes, the UART is closed just before we
On 5/9/2024 10:23 PM, Mark Stevens wrote:
The issue arises if I try to kill the kernel thread reading from the UART and
then try to start a user thread reading from the same UART.
Hmmm... the UART device will closed when the kernel thread is killed,
right? When the device is closed, it is
This problem is reported for a lot a platforms and seems to be a
hardware issue, usually associated with FIFOs and buffers.
If you rule everything else out, then you can also consider some of the
more unusual causes. On some hardware, small differences in BAUD can
result in the kind of data
On 5/4/2024 7:57 AM, Kenneth Pettit wrote:
On the Tiny Tapeout discord channel, the engineer who submitted the
Z80 design said the z88dk toolchain was the "most mature". Looking at
it I believe he may be correct as it has a full compliment of tools
simialr to an GNU toolchain. It uses sdcc
On 5/3/2024 8:31 AM, Kenneth Pettit wrote:
There is an effort to make a Z80 replacement chip:
https://app.tinytapeout.com/projects/668
This is just a start since there are limited I/O pins on Tiny Tapeout,
but I think the plan might be to eventually put it on an MPW to have a
fully
On 5/3/2024 2:12 AM, Lee, Lup Yuen wrote:
https://lupyuen.github.io/articles/pr#check-coding-style
Nice article. This would be good to have in the documentation.
I'm not aware of a script that does auto-formatting for NuttX Code. I do it
manually in VSCode :-)
There used to be a couple of
'nsh: i2c: command not found' means that the i2c app was not built into the
image and/or was not registered at build time. NSH is simply complaining that
you are trying to run an app that does not exist.
Did you remember to include logic in your board/src file in order to initialize
and
On 4/14/2024 7:02 AM, Ahmad Noori wrote:
Hi
I have a custom board with stm32h743vit6
I port nuttx to this board and i am using it.
I have problem with mmcsd sdio and i cant mount sd card. I get error 19
when mount sd card.
I test my hardware with stm32cubeide and its ok.
Please help me to
On 3/28/2024 9:21 PM, yfliu2008 wrote:
> I am still trying to understand existing userland address envrionment
in NuttX kernel mode, I saw the following regions defined in
"arch/Kconfig": config ARCH_TEXT_VBASE, config ARCH_DATA_VBASE, config
ARCH_HEAP_VBASE, config ARCH_SHM_VBASE, config
On 3/28/2024 8:23 PM, Gregory Nutt wrote:
...
On all platforms that I am aware of, the virtual address of the
framebuffer is just a configurable constant. This makes sense if the
framebuffer is in a fixed virtual address in every process. The kernel
can manage the virtual address space
On 3/28/2024 7:05 PM, yfliu2008 wrote:
Yes the user land only use standard file operations like
"mmap()/read()/write()/munmap()/ioctl()" etc to access the device memory and interruption
status via the exposed device files like "/dev/uio3" etc.
Sorry it took me so long to catch on.
My
dard POSIX mmap() to accomplish the mapping.
On 3/28/2024 3:01 PM, Gregory Nutt wrote:
I found this document which describes the use cases for UIO in Linux:
https://www.kernel.org/doc/html/v4.13/driver-api/uio-howto.html . They
use mmap() to addess device memory: "|/dev/uioX| is
3/28/2024 12:25 PM, Gregory Nutt wrote:
A more interesting task would be to port NxLib to run on top of the
existing NuttX NX Windows System:
* https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629474
* https://cwiki.apache.org/confluence/display/NUTTX/NX+Graphics
A more interesting task would be to port NxLib to run on top of the
existing NuttX NX Windows System:
* https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629474
* https://cwiki.apache.org/confluence/display/NUTTX/NX+Graphics+Subsystem
That would not be particularly easier,
On 3/28/2024 11:17 AM, Shijo George wrote:
I was planning to port NanoX to NuttX as part of GSoC. Is anyone familiar
with NanoX? Any suggestions and help would be much appreciated.
Regards ,
Shijo george
This will likely be a very difficult job. Nano-X is a complete X-11
replacement from
On 3/28/2024 1:03 AM, yfliu2008 wrote:
...
Have "up_addrenv_map(), up_addrenv_unmap()" alike interfaces added to
encapsulate MMU mapping operations of different chip architectures. These are used by UIO
component to a.
As an architectural description it is confusing to understand what you
On 3/28/2024 8:21 AM, Gregory Nutt wrote:
On 3/28/2024 1:03 AM, yfliu2008 wrote:
Have UIO framework added which exposes an "uio_register_device()"
interface to BSP so that to instantiate different UIO devices
with specific device path, address range and IRQ data.
Then userland ap
On 3/28/2024 1:03 AM, yfliu2008 wrote:
Dear experts,
I am wondering if we can have an Userspace IO alike component added to NuttX
kernel? It can help exposing video frame buffers or neural network
accelerators alike devices to user land services. Often kernel has little to do
with such
nly) would be the more practical way to accomplished what you want to do.
On 3/21/2024 4:43 PM, Gregory Nutt wrote:
I think we need to continue to use PRs at some point in the process.
PRs are so tied into our CI that I don't think we could work around it.
Can you use another GIT repository? If
I think we need to continue to use PRs at some point in the process.
PRs are so tied into our CI that I don't think we could work around it.
Can you use another GIT repository? If you create a PR on gitlab or
bitbucket, someone could move the PR to github. Or perhaps we could
take commits
On 3/15/2024 11:10 PM, Saurav Pal wrote:
All in all, I am *against* Rust being introduced in the kernel. However, I
am fine with the language being in the very leaf nodes. Like some drivers,
userspace applications, or userspace filesystems (FUSE)... especially those
that only interact with the
nity support" because it means
something like "unanimity" and as a guy called Nelson Rodrigues once said:
"All unanimity is dumb".
Although (fortunately) we don't have full community support, it seems we
have a direction: only application support for now.
Best Regards,
Ala
On 3/13/2024 4:11 PM, Alan C. Assis wrote:
I think we are having a CMakefile deja-vu here, don't we? (I hope we don't
lose any developer this time)
Let's make sure that we have full concurrence from the community. Our
responsibility is to serve the whole community and not just the special
On 3/13/2024 2:42 PM, Tomek CEDRO wrote:
You want Rust in the core go ahead write RustOS have fun maintaining it for 5
years and show us its better :-)
You are probably right in that. It would probably be necessary have to
be a different OS if any extensive amount of Rust is used. POSIX
There is some discussion in Issue #11907 proposing to use the Rust
language within the OS (vs Rust applications on a pure C OS). If anyone
has any feelings, Pro or Con, you should participate in this
discussion. This kind of decision impacts the entire community and
should have the input of
On 3/12/2024 5:12 AM, Nathan Hartman wrote:
Try Alan's suggestion to use stack monitor, and that will help understand
if there is something wrong. (If it shows that old stack size was OK, while
we know corruption was happening, then we will know to look for some out of
bound write.)
Does the
After enlarging the stack size of "AppBringUp" thread, the remote node can boot NSH
on RPMSGFS now. I am sorry for not trying this earlier. I was browsing the "rpmsgfs.c"
blindly and noticed a few auto variables defined in the stack... then I thought it might worth a try so
I did it.
That is
On 3/12/2024 1:10 AM, yfliu2008 wrote:
On the other hand, if we choose not mounting NSH from the RPMSGFS, it can boot
smoothly and after boot we can manually mount the RPMSGFS for playing.
That sounds like an initialization sequencing problem. Perhaps
something is getting used before it has
:20 PM, Simon Filgis wrote:
Is there a way to colorize heap to track down the bandid? Like CRC pattern
on all the spaces around and check on every call that the CRC pattern ist
still OK?
Gregory Nutt schrieb am Mo., 11. März 2024, 19:27:
If the memory location that is corrupted is consistent
Gregory Nutt wrote:
The reason that the error is confusing is because the error probably did
not occur at the time of the assertion; it probably occurred much earlier.
In most crashes due to heap corruption there are two players: the
culprit and the victim threads. The culprit thread actually
.c:117 task: Idle_Task
process: Kernel 0x70023c0
The call stack looks like:
#0 _assert (filename=0x7060f78 "kasan/kasan.c", linenum=117, msg=0x7060ff0 "panic", regs=0x7082720
Original
From:"Greg
On 3/10/2024 4:38 AM, yfliu2008 wrote:
Dear experts,
When doing regression check on K230 with a previously working Kernel mode
configuration, I got assertion error like below:
#0 _assert (filename=0x704c598 "mm_heap/mm_malloc.c", linenum=245, msg=0x0,regs=0x7082730
This does indicate
On 2/24/2024 11:42 AM, Gregory Nutt wrote:
On 2/24/2024 11:39 AM, Jernej Turnsek wrote:
@Tomek No, my SD card filesystem is notu mounted read-only, because I
can
delete single files. I believe that rm * is just not implemented.
There is no logic in NSH that expands "*" to a list of
On 2/24/2024 11:39 AM, Jernej Turnsek wrote:
@Tomek No, my SD card filesystem is notu mounted read-only, because I can
delete single files. I believe that rm * is just not implemented.
There is no logic in NSH that expands "*" to a list of all files in the
current directory. It is passed on to
Makes sense since mount points should be "removed" with umount.
rm on a mount point should work. rm does not necessarily remove it. It
maps to unlink which removes the name from mount point, or file. Logic
in the VFS will detect detect the open count. The entity will exist
nameless until
On 2/23/2024 6:19 PM, Gregory Nutt wrote:
On 2/23/2024 5:57 PM, Alan C. Assis wrote:
/tmp:
test1
test2
test3
nsh> rm -r .
nsh: rm: unlink failed: 1
nsh> ls
/tmp:
nsh>
It reported error "unlink failed: 1", but removed all the files.
1 = EPERM, Operation not p
On 2/23/2024 5:57 PM, Alan C. Assis wrote:
/tmp:
test1
test2
test3
nsh> rm -r .
nsh: rm: unlink failed: 1
nsh> ls
/tmp:
nsh>
It reported error "unlink failed: 1", but removed all the files.
1 = EPERM, Operation not permitted
I suspect that occurred when it tried to rm ".". Try
However, I think it is a mistake to put the hooks in for syncfs and
not implement syncfs for other file systems that need it. From what
you say, syncfs() would be a no-op for those other file systems which
is (usually) wrong. Perhaps they could just call fsync() from
sync()? Doing
SP
On Wed, Feb 14, 2024 at 9:27 PM Gregory Nutt wrote:
It implementes the syncfs file system interface:
https://linux.die.net/man/2/syncfs
On 2/14/2024 8:16 AM, Saurav Pal wrote:
Hi all,
I was going through the codebase of different file systems, and I haven't
yet understood the syncfs() met
It implementes the syncfs file system interface:
https://linux.die.net/man/2/syncfs
On 2/14/2024 8:16 AM, Saurav Pal wrote:
Hi all,
I was going through the codebase of different file systems, and I haven't
yet understood the syncfs() method of mountpt operations.
There aren't any existing
The STM32F427AI is in the same family as STM32F427xx (STM32F427V,
STM32F427Z, STM32F427I) and STM32F429xx, which are already supported.
The first thing to do is to decide which is of the supported parts is
most like the STM32F427AI. Mostly likely it is just a difference in
memory size or
You would need to mount with -t vfat. That is how it the system knows
that the file system is vfat.
It seems like you should be able to omit the file system type when
mounting and let the system figure out the file system type, but that
does not appear to be supported.
On 2/12/2024 2:30
On 2/8/2024 2:50 PM, Alan C. Assis wrote:
Thank you for clarifying Greg, but I think PIC32 is using little
endian, at least I can't see CONFIG_ENDIAN_BIG defined to them at boards/
You are right. MIPS is traditionally big-endian or powers up
big-endian, but Microchip opted to force little
The network monitor is part of apps/netutils/netinit so it is not a part
of NSH. NSH can automatically perform the network initialization if so
configured and which, optionally, starts the network monitor thread.
But the logic is not architecturally a part of NSH nor does it depend on
N SH.
nt.
Maybe in the future this event could be driven by ASF, like Linux
Foundation does.
Best Regards,
Alan
On Mon, Jan 29, 2024 at 10:30 AM Gregory Nutt wrote:
Shouldn't this be "Apache NuttX Workshop 2024" instead of "Nuttx
Workshop 2024". Apache NuttX is the full, legal name o
Shouldn't this be "Apache NuttX Workshop 2024" instead of "Nuttx
Workshop 2024". Apache NuttX is the full, legal name of the RTOS; Use
of NuttX alone is considered ambiguous and is discouraged by the ASF.
at 4:31 PM Gregory Nutt wrote:
Aren't most CPUs available as soft cores? Certainly Xtensa was intended
for that purpose. ARM and MIPS have been common soft cores in ASICs for
more than a decade. As is RISC-V soft core in FPGAs.
https://en.wikipedia.org/wiki/Soft_microprocessor
In the past
Aren't most CPUs available as soft cores? Certainly Xtensa was intended
for that purpose. ARM and MIPS have been common soft cores in ASICs for
more than a decade. As is RISC-V soft core in FPGAs.
https://en.wikipedia.org/wiki/Soft_microprocessor
In the past, there was some interest in
st yet. With the help of "echo used
/proc/memdump", I can see used memory nodes list added.
If needed I can create a Github ticket to track this so that some experts can
reveal the root cause later.
Regards,
yf
Original
On 1/24/2024 3:44 PM, Gregory Nutt wrote:
The on-demand paging logic is obsolete and incomplete as well as
incorrect for the current architecture. It was an experiment only for
the LPC3131 when I was running out of a small SRAM with dynamic paging
from SPI flash. It really should
The on-demand paging logic is obsolete and incomplete as well as
incorrect for the current architecture. It was an experiment only for
the LPC3131 when I was running out of a small SRAM with dynamic paging
from SPI flash. It really should be removed.
True on-demand paging as you envision
Are you running app in foreground or background from NSH, i.e.,
nsh> app
nsh> app &
The second should show this kind of interleaved behavior. In the first,
nsh should block until the app exits.
Do you have waitpid() enabled? The first behavior depends on the
availability of waitpid()
In general you would have to have two copies of NuttX and run them AMP.
A single OS with multiple CPUs would require SMP. SMP generally
requires that the CPUs appear identical in the two CPU address spaces
(with the exception of interrupts).
There was a long email thread discussing this
There is instrumentation in ostest that prints heap usage after each
test test. That should isolate the memory leak.
On 1/19/2024 2:07 AM, yfliu2008 wrote:
Dear experts,
With "rv-virt/knsh32", I noticed the "used Kmem" shown by "free" command keeps growing
after each run of "ostest",
Everything you need to know is in that referenced wiki page:
https://cwiki.apache.org/confluence/display/NUTTX/Debugging+ELF+Loadable+Modules
I don't know anything about QEMU or RISC-V. But assuming that NSH is
your init application...
* NSH is not in memory when you start the OS; it
On 1/9/2024 8:06 PM, yfliu2008 wrote:
Yes, in kernel mode each user space program has similar but isolated virtual
address spaces. So it seems that we can't set break points to them like FLAT or
PROTECTED build.
Not sure if we need some sort of debug agent in KERNEL build so that it can
On 1/9/2024 7:28 PM, Alan C. Assis wrote:
Hi Yf,
Just look at your System.map and you will see that all those main() became
_main.
It isn't possible to have a unique main() symbol, otherwise we will have a
duplicated symbol, also even if the compiler accepted that, how could NuttX
know you
This is old and does not specifically address kernel mode, but I think most of
the debug tips do apply in kernel mode too. The load address is a constant for
kernel ELF modules so at least that part doesn't apply. But the rest probably
does.
On 1/9/2024 7:20 PM, yfliu2008 wrote:
Alan,
+1
On 1/3/2024 10:43 AM, Nathan Hartman wrote:
On Wed, Jan 3, 2024 at 11:22 AM Gregory Nutt wrote:
On 1/3/2024 10:11 AM, Fotis Panagiotopoulos wrote:
That would seem a little odd since there was a PR a few years ago to
change all instances of assert/ASSERT to DEBUGASSERT to save code size
On 1/3/2024 10:11 AM, Fotis Panagiotopoulos wrote:
That would seem a little odd since there was a PR a few years ago to
change all instances of assert/ASSERT to DEBUGASSERT to save code size.
How is that so?
As I see here:
https://github.com/apache/nuttx/blob/master/include/assert.h#L122
On 1/3/2024 5:12 AM, Fotis Panagiotopoulos wrote:
Hello everyone,
I am glad that we all agree on this matter.
We can handle this in the following steps:
1. Ensure that any new PRs and apps follow this convention.
This is up to the reviewers, to enforce.
2. Get rid of all DEBUGASSERTs in
On Tue, Jan 2, 2024 at 11:16 AM Fotis Panagiotopoulos
wrote:
DEBUGASSERT shall only be used for the kernel.
assert shall only be used for apps.
Rationale:
DEBUGASSERT is a custom macro that only exists in the NuttX world.
As such it is best being used in NuttX-specific code.
assert on the
There is a QEMU port to the i486 under boards/x86/qemu-i486
I am not sure of the state that was left in. I don't think that has
been touched for a while so I would also expect some bit rot.
That port was tested on a retro hardware board. The person that
developed that board reported that
Might be easier to use if the OPEN option SELECTED the FIFO and named
pipes. That way the POPEN option will appear in the menus when FIFOs
are disabled.
On 12/20/2023 1:45 PM, Gustavo Soares wrote:
After enabling 'FIFO and named pipe drivers' I was able to use popen()
and pclose()
The Zigbee support is interesting. NuttX does not have a Zigbee stack,
but does have IEEE 802.15.4 which works with the same physical radio.
The IEEE 802.15.4 logic is quite an accomplishment. The original
development was done by Anthony Merlino and Sebasiten Lorquet. I see
that there
On 12/10/2023 4:05 PM, Shane Curcuru wrote:
I think we have to be careful with the word "contribution". The ASF
cannot accept any contribution that is licensed and copyrighted by
some other entity. To "contribute" the code is to donate the code to
the ASF without retaining any claims to
On 12/10/2023 7:15 AM, Alan C. Assis wrote:
I understand your point. And in fact I think the issue is not your
contribution itself, but the future contribution from developers of RTEMS
and Linux that are using GPL.
I think we have to be careful with the word "contribution". The ASF
cannot
But again, I think we can avoid this tortuous path and fix the CMake or
Makefile to build on Windows.
Fully understand.
It is likely that you could create a pure Windows native build (using a
Windows native toolchain) or a pure Cygwin build (using a tool chain
built under Cygwin) with CMake.
AFAIK, the Cygwin build using a windows native tool chain has been
broken for years. There is no advice anyone can give that that is just
going to make it work. It is broken and no one has interest in fixing
that which they have broken. People make many changes to the build
system but never
Worth taking a look at: https://news.itsfoss.com/xiaomi-vela-open-source/
On 11/4/2023 6:12 PM, Robert Middleton wrote:
I'm a little confused as to what the difference is between the MTD folder
and the EEPROM folder. It seems that both folders have support for the
at24xx and at25xx series of chips, so it's not obvious which one is
better.
MTD is more of a
On 11/3/2023 4:02 PM, Robert Middleton wrote:
Hi,
I am working on a project that will need to be able to read/write the
ID page of an EEPROM(currently a M95M02 SPI device from ST). From the
code that I have seen, it seems that this chip is already supported,
but there is no code to read/write
On 10/26/2023 4:48 PM, Nathan Hartman wrote:
I wonder if this hasn't been solved already in some industry-accepted
manner. For example (not saying this is the solution, just thinking out
loud) there is a redundancy mechanism that makes two network interfaces
look like one, with automatic
On 10/25/2023 10:41 PM, Zhe Weng 翁喆 wrote:
But I do have another idea:
Maybe you can try to register two network devices even if you only have a
single GMAC, just dup all the rx packets to both interfaces, and let all tx
packets go out. Since the IP addresses are different on each
On 10/25/2023 9:27 AM, Matthias Roosz wrote:
Hi all,
forgive my ignorance, I’ve just started diving into networking topics
(including handling connections via Berkeley sockets). My final goal is to
make my device reachable via two separate IP addresses with a single PHY.
Once there are two IP
On 10/25/2023 8:48 AM, Gregory Nutt wrote:
On 10/25/2023 8:18 AM, Alan C. Assis wrote:
On 10/25/23, Nathan Hartman wrote:
On Wed, Oct 25, 2023 at 5:16 AM Ville Juven wrote:
Hi all,
I noticed that when spawning a new task/process from a file in
nsh_fileapps, the scheduler is locked prior
On 10/25/2023 8:18 AM, Alan C. Assis wrote:
On 10/25/23, Nathan Hartman wrote:
On Wed, Oct 25, 2023 at 5:16 AM Ville Juven wrote:
Hi all,
I noticed that when spawning a new task/process from a file in
nsh_fileapps, the scheduler is locked prior to calling posix_spawn(),
which
does the file
On 10/14/2023 1:48 AM, guangyuan wang wrote:
Hi
I note that the Nuttx supports POSIX well. And I'd like to check whether I
could use Nuttx core to replace the Linux core in Ubuntu OS.
No, probably not. It depends on what you mean and how much effort you
want to put into it. Remember that
. Uros was replacing file system tasks with internal
flash tasks so from his point of view, the FLASH based tasks were
internal (or built-in) and not external (on a file system).
On 10/12/2023 3:16 PM, Alan C. Assis wrote:
Hi Greg,
On 10/12/23, Gregory Nutt wrote:
On 10/12/2023 2:18 PM, Alan C
On 10/12/2023 3:26 PM, MIGUEL ALEXANDRE WISINTAINER wrote:
Some idea how to capture the data returned by exec ?
exec does really return any data other than an int status code which
only indicates if the task was correctly started.
If you want some text output, you would have to add
On 10/12/2023 2:18 PM, Alan C. Assis wrote:
The execv on Linux also fails when we can an builtin program, try it:
You are right, but the semantics are really confusing. In Bash,
commands that are included inside of Bash are called built-in commands
and you cannot execute them. We ignore
On 10/12/2023 2:05 PM, Alan C. Assis wrote:
Ah ok, I tested using the original code with "ls" instead "/bin/ls"
and the result as similar to NuttX: didn't print anything.
That is a different problem; it did not find ls. On linux, use /execvp/
instead of /execv //or //execve/. With execve,
On 10/12/2023 2:31 PM, MIGUEL ALEXANDRE WISINTAINER wrote:
I can run (execv) i2c from hello
works!
Now Gustavo can you this TIP to make work the PCA/PCF GPIO extender
Thanks!
nsh> hello
Executing 1 /bin/i2c
Usage: i2c [arguments]
Where is one of:
There are
I'm not the right guy to talk about CI,but I believe that every modified
C file is run through Lint. If you have questions, I am sure someone
else can expound.
On 10/10/2023 12:33 PM, Daniel Appiagyei wrote:
Hey,
I was running the [cppcheck](https://cppcheck.sourceforge.io/) static
analysis
These reports with regard to DEBUGASSERT have been reported before.
DEBUGASSERT is defined in a ccouple of ways. Here is one way:
do \
{ \
if (predict_false(!(f))) \
On 10/4/2023 8:02 PM, Gustavo Soares wrote:
Hi Greg!
Yes, if I use #include this problem is solved, but
then the code loses the reference to that specific struct causing another error.
And how exactly "the file does not exist"? I can open it and it is at the nuttx
repo, I shared it's link.
Actually, the problem is very simple. This file does not exist.
#include
You probably wanted
#include
The more I look at what you are trying to do, the more confused I get.
There is a file at drivers/ioexpander/pcf8575.h, but you are not
permitted to include that. That contains
Why wouldn't the compiler access nuttx/drivers/ioexpander/pcf8575.h?
Access to internal driver files by applications is specifically
forbidden. This is part of the enforcement of the modular design to
assure that people do not do that kind of thing: Applications must
not have access to
Why wouldn't the compiler access nuttx/drivers/ioexpander/pcf8575.h?
Access to internal driver files by applications is specifically
forbidden. This is part of the enforcement of the modular design to
assure that people do not do that kind of thing: Applications must not
have access to
On 10/4/2023 7:02 PM, Gustavo Soares wrote:
Why wouldn't the compiler access nuttx/drivers/ioexpander/pcf8575.h?
Access to internal driver files by applications is specifically
forbidden. This is part of the enforcement of the modular design to
assure that people do not do that kind of
On 9/21/2023 6:34 AM, Simon Filgis wrote:
When I started with networking, I set the IP via kconfig. I remember that
it was necessary to enter the same IP at two different places. Netlib and
FTP server in my case. Maybe your IP is overwritten by another app? A
buildin app that you use for
On 9/21/2023 6:53 AM, Petro Karashchenko wrote:
setting "address.sin_addr.s_addr" + "bind" is kind of a way you can use to
receive requests only from an interface that has a specific IP address.
This is useful if your system has multiple network interfaces and you want
to provide some kind of
On 9/21/2023 5:06 AM, Gustavo Soares wrote:
Why is it a different IP? The server is listening to one but this
method returns another one.
You provide almost no information for anyone to really help you.
Where is the server and client? It sounds like you are saying that the
HTTP server is
1 - 100 of 1577 matches
Mail list logo
