You may try to overwrite BIN in nshlib/Makefile to libnsh.a.
On Tue, Apr 26, 2022 at 2:38 PM Michael Jung wrote:
> Hello everybody,
>
> I am currently experimenting with buildroot to create a NuttX SDK, which
> includes a GCC toolchain build using NuttX as the C library and basically a
> sysroot
Hello everybody,
I am currently experimenting with buildroot to create a NuttX SDK, which
includes a GCC toolchain build using NuttX as the C library and basically a
sysroot environment that contains static libraries (for e.g. libwebsockets,
sqlite, etc...), which can optionally be linked by users
There is another precedent here: nuttx/wireless/ieee802154. For that radio
family, there are 3 applications interfaces: There is a dumb serial
driver and a network driver. The network driver supports both a simple raw
interface and also an IPv6 LoPAN interface.
There is nothing that can be don
The main reason why I'm raising this topic is that I think that the CAN
lower part should be a standard way the upper layer talks to CAN HW and the
upper half should perform the translation to a char or netdev interface.
Now that is not true. Basically I'm looking into the minimal set of
functions
Hi Petro,
I understand having 2 upper separate layers for CAN isn't welcomed.
However I don't see any real particular gains for a generic can_ops_s
for both the SocketCAN and CAN Char driver.
For example SocketCAN net_driver_s interface uses the dev->d_buf
interface to transfer data and then in
Hello,
Recently I've been working on LIN bus support with SAME70 based device. In
general the integration was done smoothly and I would like to contribute my
work to the community. The LIN is pretty similar to CAN and in Linux is
abstracted as a SocketCAN device. During my integration I chose a mo
