I fully agree with Tomek. If possible, let's delay the release for a while
and fix what's broken, or at least find the broken configurations/features.
What I have tested so far:
- [X] sim/foc - fixed
- [X] sim/smp - **broken**
- [X] sim/nsh - OK
- [X] sim/crypto - OK
- [X] sim/elf - OK
- [X] sim/f
-1 from me.
Too many things seem broken.
Since the last release there have been a lot of critical changes that are
most likely not very well tested.
It would be nice to have more community involvement in testing this
release.
For my part, I'll spend the next few days testing on the hardware I hav
We should avoid GPL in the kernel as much as possible, best not to use it
at all,
especially when it comes to arch support. Currently the only GPL component
in
the kernel is VIDEO_OV2650, whose license is not entirely clear and GPL is
only
there "just in case".
The only place where GPL might be tol
> I ported some of them a while back and other people ported more than I
did,
> but I don't think there's a list of what was ported and what wasn't. If
> someone could go through CWIKI and Documentation and make a list of what
> isn't ported yet, that will make it easier finish the rest of them.
T
napisał(a):
> 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.
> >
&
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.
But the problem of reusing the same low-level driver code across different
arch implementations is an unsolved
You should check your mfrc522 chip if it's properly powered and the NRSTPD
pin is correctly set.
All your read requests return 0 so most likely the chip is in power-down
state (or not powered at all).
You can also check the soldering of your 522 chip. I have dealt with many
these chips and what I r
One of the ideas that came to mind when working with the x86 architecture
and
the ACRN hypervisor was that this setup could be a powerful tool for
automating
complex tests for NuttX. On a multicore x86 machine with a hypervisor, we
can
compile different NuttX images, run them simultaneously, and te
Hi,
This PR updates the NimBLE version to the latest master:
https://github.com/apache/nuttx-apps/pull/2414.
New NimBLE features like LE ISO channels are not supported yet, only
compilation fixed.
I will open this PR when https://github.com/apache/mynewt-nimble/pull/1795
is merged.
śr., 12 cze 202
-1 from me for Rust in the kernel, +1 for Rust in apps.
Sebastien and Tomek gave enough arguments to avoid Rust in the kernel.
Not a technical argument from me: Rust has too many arrogant members
in the community with a messianic approach (like `Rust will save embedded,
blah, blah, blah`),
it's q
BOARD_SPI0_CS_PIN);
> >
> > #ifdef BOARD_SPI0_MISO_PIN
> > nrf52_gpio_config(BOARD_SPI0_MISO_PIN);
> > nrf52_spi_pselinit(priv, NRF52_SPIM_PSELMISO_OFFSET,
> > BOARD_SPI0_MISO_PIN);
> > #endif
> > #ifdef BOARD_SPI0_MO
ter("/dev/accel0", dev);
>if (ret < 0)
> {
>syslog(LOG_ERR, "ERROR: bmi160_register failed: %d\n", ret);
> }
>
>
> Em seg., 26 de fev. de 2024 às 03:57, raiden00pl
> escreveu:
>
> > You need to specify that SPI is used as mas
You need to specify that SPI is used as master: CONFIG_NRF52_SPI0_MASTER=y
niedz., 25 lut 2024 o 21:22 Mauro Sollar napisał(a):
> Hi,
>
> I'm trying to use the BMI160 sensor with the Nordic nRF52832-dk Kit, help
> me please!
>
> Kconfig Configuration:
>
> System type
> nRF52 Peripheral Selecti
ions once I get that board
> running.
>
> Can the dongle be easily programmed as a BLE sniffer to debug the
> protocol? That would make it valuable.
>
> ACK for the 802.15.4 part, thank you and best wishes for working this.
>
> Sebastien
>
>
> Le 02/02/2024 à 17:26,
The nrf52 port in NuttX has support for BLE using a closed-source
Softdevice controller
from Nordic (
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrfxlib/softdevice_controller/README.html
).
This is a certified BLE stack so there should be no problems with it.
It worked with NuttX B
> Specifically I am looking at the nRF52840 SoC with Thread support.
Hi, Thread is based on IEEE 802.15.4 which is not yet supported by nrf52 in
NuttX. So in addition to the openthread support, you also need support for
the radio layer.
I started writing support for IEEE 802.15.4 for Nordic chips,
ame.
>
>
>
> --
> *От:* "raiden00pl"
> *Кому:* "undefined"
> *Отправлено:* пятница, 8 сентября 2023 г., 12:52
> *Тема:* Re: Addition of STM32H7 MCU's
>
> From what I'm familiar with STM32H7, all chips use the
>From what I'm familiar with STM32H7, all chips use the same registers and
bit definitions.
Therefore, keeping definitions for different chips in different files
doesn't make sense in my opinion.
The only problem is that some chips support some peripherals while others
do not. But this can be
solve
> There are known CAN sources that have GPL code and have been documented
in the LICENSE File
> All this code is protected under the include GPL code config option and
disabled by default
> Is this approach approved or we should completely remove the GPL code
from NuttX?
The code in question is du
stien Lorquet
napisał(a):
> Hi,
>
> Le 25/08/2023 à 11:48, raiden00pl a écrit :
> > Forcing people using cmake to support make is the worst thing that can
> > happen.
> > Open source is voluntary, any contribution is voluntary, any form of
> > forcing
> > others to
I think this is reinventing the wheel. This seems to not be a trivial
change,
and the ready solution in the form of cmake is already there. If an
individual
or a company wants to devote their time to it, I don't see a problem, but
this
must be backward compatible.
The main voice against cmake was t
> Thanks Raiden! Can you hint a complete implementation that I can base
> on the ESP32 work? :-)
You can look at
https://github.com/apache/nuttx/blob/master/arch/arm/src/stm32/stm32_qencoder.c
and search for CONFIG_STM32_QENCODER_INDEX_PIN.
sob., 10 cze 2023 o 02:53 Tomek CEDRO napisał(a):
> On
The index signal (Z index) should be used to reset the encoder position.
You can miss an encoder step for various reasons, and without periodically
checking the absolute position (index pin), you will accumulate errors.
Then, if you set the maximum count of an encoder timer to encoder
resolution, t
Have you tried to increase the stack size for NSH ? Stack overflow in NSH
can cause some really weird hard faults, not that easy to diagnose.
czw., 11 maj 2023 o 18:34 Sebastien Lorquet
napisał(a):
> Hello,
>
> I have a stm32h7 board, based on the stm32h743zi2 nucleo.
>
> I have activated the w
The new SoC from Nordic is coming and it seems to be a powerful beast.
https://www.nordicsemi.com/News/2023/04/Nordic-Semiconductor-redefines-its-leadership-in-Bluetooth-Low-Energy-with-the-nRF54-Series
> The nRF54H20 boasts multiple Arm® Cortex®-M33 processors and multiple
RISC-V coprocessors. T
5, 2023 at 6:16 AM raiden00pl wrote:
> >
> > NVMC support for NRF52 chips was ported from Nordic SDK which was
> released
> > on the BSD license (old times), so these features should depend on
> > CONFIG_ALLOW_BSD_COMPONENTS=y. Users must manually enable support for the
>
NVMC support for NRF52 chips was ported from Nordic SDK which was released
on the BSD license (old times), so these features should depend on
CONFIG_ALLOW_BSD_COMPONENTS=y. Users must manually enable support for the
BSD components to continue using the mentioned features.
Related PR: https://githu
Hi Alan, please add me to the Spreasheet.
pt., 10 mar 2023 o 14:53 Alan C. Assis napisał(a):
> I already sent Editor permission for all those listed in the Spreasheet.
>
> If someone else here is interested to help, just ping me.
>
> BR,
>
> Alan
>
> On 3/10/23, Alan C. Assis wrote:
> > Hi Ever
> - All breaking commits should be discusses on dev so that people get
enough time to digest the change and even better get involved int the flow
I think "all breaking commits" is too broad and impractical.
What about code guarded with CONFIG_EXPERIMENTAL? What about the features
just added or fre
For your custom driver logic you can look at nuttx/drivers/motor/motor.c
which implements the general motor controller interface to interact with
user-space.
Then your all custom motor control logic goes to your board files.
For driving high voltage relays you can look at dedicated smart relay
dri
Related issue: https://github.com/apache/nuttx/issues/5142.
Not using a work queue to handle CAN RX is basically wrong. Unfortunately
all NXP SocketCAN drivers are affected.
wt., 3 sty 2023 o 19:38 Xiang Xiao napisał(a):
> Sorry, "you must do..." may confuse you. What I mean is the CAN driver.
+1 for nuttx and nuttx-apps
sob., 19 lis 2022 o 12:17 Abdelatif Guettouche <
abdelatif.guettou...@gmail.com> napisał(a):
> nuttx and nuttx-apps for me too. For the hyphen, as it was said before
> people can clone the repo under any name they want. We've been doing
> this ever since we joined the
+1: Apache NuttX is ready to graduate to TLP
pt., 21 paź 2022 o 16:20 Boris Astardzhiev
napisał(a):
> +1: Apache NuttX is ready to graduate to TLP
>
> Best regards,
> Boris
>
> On Fri, Oct 21, 2022 at 5:14 PM Marcio Ribeiro
> wrote:
>
> > +1: Apache NuttX is mature enough to graduate.
> > Kind
Do you use the default TIM3 outputs configuration from
nucleo-144/include/board.h ? It uses PA7 as the TIM3 channel 2 output which
is also used for RMII_CRS_DV.
>From the nucleo 144 user manual:
> 2. PA7 is used as D11 and connected to CN7 pin14 by default, if JP6 is ON,
> it is also connected to
Hi Roberto,
this should be easy to port from the arch/stm32 directory.
I plan to port NuttX and the STM32 FOC driver on the ST SL-ETH001V1 eval
board which is based on the STM32F7 chip.
For this I've to expand the STM32F7 PWM driver, including complementary
channels.
I'll start working on this pro
; CONFIG_SEGGER_RTT_BUFFER_SIZE_UP=2048
> CONFIG_SEGGER_RTT_BUFFER_SIZE_DOWN=32
> CONFIG_SEGGER_SYSVIEW_RTT_BUFFER_SIZE=2048
> CONFIG_SEGGER_SYSVIEW_RAM_BASE=0
>
> Best regard
> Zou
>
>
> -- Original --
> *From: * "raiden00pl";
&
005bd8
> 7 3 100 RR pthread --- Waiting Semaphore 002048
> 000732 35.7% pt-0x8019d71 0x20005bd8
> nsh>
>
> pt-0x8019d71 is a USB CDCACM RX thread
>
> Best regard
> Zou
>
> -- Original --
> *From: * "ra
For this reason, stm32_pwm.c has an additional condition checking whether
the channel in 'struct pwm_info_s' is set:
4389 │ int i;
> 4390 │
> 4391 │ for (i = 0; ret == OK && i < CONFIG_PWM_NCHANNELS; i++)
> 4392 │ {
> 4393 │ /* Set output if channel configured */
> 43
m
> my computer and can't check the details now. Maybe raiden00pl knows more.
> IIRC he fixed some of my mistakes in the pinmap :-)
>
> IIRC STmicro has somewhere an application note describing the analog
> features like OPAMP, COMP, etc, and other features and how they differ fro
If you use CONFIG_BUILD_FLAT=y, make sure that __KERNEL__ flag is set here:
https://github.com/apache/incubator-nuttx/blob/master/include/nuttx/mm/mm.h#L85
I remember that at some point I had a similar hardfault in mm which doesn't
make sense and it was due to outdated board Make.defs.
śr., 26 maj
trying to solve
> this, but its deep in the core system where this CONFIG_PWM_PULSECOUNT has
> effect. If I only had more time
>
> Ben
>
> -Oorspronkelijk bericht-
> Van: raiden00pl
> Verzonden: dinsdag 6 april 2021 08:10
> Aan: dev@nuttx.apache.org
> Onderw
If PULSECOUNT is enabled, current logic in stm32_pwm.c assumes that all PWM
instances support PULSECOUNT which is not true. Timers without RCR register
shouldn't use pwm_pulsecount_* functions. Probably that is the problem.
I guess you can do something like this:
https://github.com/raide
As far as I can remember, it never worked that way. If you enable
PULSECOUNT, you can only use timers that support this feature.
Other PWM instances will not work properly.
sob., 3 kwi 2021 o 17:19 napisał(a):
> So /dev/pmw0 = TIM1
> /dev/pmw1 = TIM4
>
> All well.. but with CONFIG_PWM_PULSEC
It looks like a bug. But for some reason with the input buffer turned off,
reading the input pin still works (nrf52840).
niedz., 10 sty 2021 o 19:17 Matias N. napisał(a):
> Hi,
> while debugging the issue I mentioned in the other thread, I found
> something strange: when configuring a pin as inp
Does your I2C device use I2C_M_NOSTART or I2C_M_NOSTOP flags for
communication ? They are not supported by the current NRF52 I2C
implementation.
niedz., 10 sty 2021 o 05:42 Matias N. napisał(a):
> I was about to enable error support but I noticed it is disabled in-code.
> From the look of it the
ver
> initialization. Correct?
>
>
>
> Στις Δευ, 14 Δεκ 2020 στις 9:05 μ.μ., ο/η raiden00pl >
> έγραψε:
>
> > Hi,
> >
> > I want to achieve the following sequence:
> > > 1. Select the desired pin.
> > > 2. Trigger a single conversion, and
Hi,
I want to achieve the following sequence:
> 1. Select the desired pin.
> 2. Trigger a single conversion, and wait for it to finish.
> 3. Read the result.
This is not possible because the channel configuration cannot be changed at
runtime.
But you can achieve similar functionality just by dis
Hi,
there seems to be a bug in the ADC setup logic and adc_reset() is only
called when the ADC driver is first opened.
You can fix it with the patch below, but I need to verify if it doesn't
break the ADC for STM32F3. If it works, I prepare a PR
diff --git a/arch/arm/src/stm32/stm32_adc.c b/arch/a
> I was not aware of the limitation of TFIS only working for RX -> TX.
Where is that documented?
There is "Figure 117: IFS timing detail" in the NRF52840 manual which shows
only RX->TX and I followed this.
I don't see any description of how RADIO behaves on TX->RX when TIFS is
enabled.
So we prob
of the protocol using a logic
> analyzer).
>
> I think that I'm still far at handling all that complexity, since I will
> probably just tackle the whole scanning/advertisement and connection of a
> single device.
>
> Best,
> Matias
>
> On Fri, Jul 17, 2020, at
x27;ve done interfaces for TIMER and RTC peripherals. Tomorrow I'll
prepare a PR.
pt., 17 lip 2020 o 16:09 Matias N. napisał(a):
> Hi,
>
> On Fri, Jul 17, 2020, at 03:30, raiden00pl wrote:
> >I think we should do it like in other BLE implementations for NRF52
> > (
I think we should do it like in other BLE implementations for NRF52
(SoftDevice, Zephyr) and use a combination of RTC and TIMER peripherals.
There are quite a few places in the BLE protocol where we need to count
the time in various ranges from seconds to mili-seconds.
It is not possible t
Great! I was close to ordering a few pieces.
But later I saw the shipping costs and gave up.
So I wait until it is more accessible in the EU.
Open source MCU+FPGA seems to be a powerful tool.
czw., 18 cze 2020 o 03:56 Brennan Ashton
napisał(a):
> This is a chip that I have been excited about for
gt;
> Best,
> Matias
>
> On Wed, Jun 17, 2020, at 04:06, raiden00pl . wrote:
> > You can use Nordic's priorpiate BLE stack (SoftDevice) and after a few
> > hacks even Nordic SDK can be integrated with Nuttx.
> > This gives you a certified BLE stack but i
You can use Nordic's priorpiate BLE stack (SoftDevice) and after a few
hacks even Nordic SDK can be integrated with Nuttx.
This gives you a certified BLE stack but it has a huge disadvantage - it is
a closed source. Looking for bugs in such an environment is a nightmare.
Some time ago I started wo
Rs to
avoid noise in the git history. Especially when it comes to new chip
specific files.
czw., 7 maj 2020 o 16:20 Nathan Hartman
napisał(a):
> On Thu, May 7, 2020 at 1:25 AM raiden00pl . wrote:
> > I got my NUCLEO-G431RB so I can help.
>
> How shall we proceed?
>
> C
You can look how DMAMUX is implemented for stm32h7.
It's more complicated than in G4 and H7 is based on DMA IPv2 but the
concept should be the same.
I got my NUCLEO-G431RB so I can help.
czw., 7 maj 2020 o 00:15 Nathan Hartman
napisał(a):
> On Wed, May 6, 2020 at 6:10 PM Nathan Hartman
> wrote:
> How does the RCC (clock tree) compare?
RCC looks like in G0 family, which is not registers compatible with older
versions. But clock tree is similar to those found in F4/F7.
czw., 16 kwi 2020 o 02:34 David Sidrane
napisał(a):
> How does the RCC (clock tree) compare?
>
> On Wed, Apr 15, 2020,
>
> This document address migration from F1 to F3 and addresses all major
> differences between F1 and F3: AN4228, Application note, Migrating from
> STM32F1 Series to STM32F3 Series microcontrollers. Table 6 address every
> peripheral.
If we are looking at compatibility then yes, most periphera
>
> Analog: the STM32G474Cxt is heavy on analog features with much more
> ADC, DAC, COMP, and OPAMP peripherals and pins than the STM32F3. These
> features are obviously new IP as the ADC adds Hardware Oversampling,
> IO Voltage Booster, Gain Compensation, Bulb Sampling, Sampling Time
> Control Tri
> Most STM32's, certainly F4, have HRTIM.
That's not true. Only F3 and H7 have HRTIM. HRTIM is a timer dedicated
to power electronics applications. You've probably confused advanced
timers (TIM1/TIM8) with HRTIM, but these are completely different
peripherals.
> The F3 is not a good point of comp
> depends on IMXRT_DTCM > 0
This syntax does not work for older versions of kconfig-frontends.
Try to update your kconfig-frontends or build it yourself from source (eg
from here ttps://bitbucket.org/nuttx/tools/src/master/kconfig-frontends/)
pt., 3 kwi 2020 o 10:30 Pelle Windestam napisał(a):
62 matches
Mail list logo
