The option to disable syslog was added in this PR
https://github.com/apache/nuttx/pull/16090
so it's quite new.
Tim, I recently wrote a blog post series on optimizing the size of NuttX
binary, so if one day you
want to optimize image size even more, I recommend you take a look at
www.railab.me :)
+1 for compatibility with Linux.
śr., 16 kwi 2025 o 10:04 Xiang Xiao napisał(a):
> On Wed, Apr 16, 2025 at 3:53 PM Peter van der Perk <
> peter.vanderp...@nxp.com>
> wrote:
>
> > can_ioctl_data_s is in a 32-bit union.
> >
> >
> https://github.com/apache/nuttx/blob/40c6af6dec0d769ac57f69e89709f9d
+1
pon., 7 kwi 2025 o 16:12 Alan C. Assis napisał(a):
> +1
>
> On Mon, Apr 7, 2025 at 6:13 AM chao an wrote:
>
>> Hi community,
>>
>> Some green hand and individual developer who are not familiar with nuttx
>> may be confused by the naming of modlib, in currect implement, modlib as an
>> elf lo
hi, PR is here: https://github.com/apache/nuttx/pull/16103
pon., 24 mar 2025 o 15:37 Lwazi Dube napisał(a):
> 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 t
Changing the code style for new files only is the worst possible idea.
Maintaining two
styles is so bad that I'm surprised that someone even suggested it.
The best decision would be to not change anything in the code style, but if
we
decide to change the style, the entire codebase should be updated
K&R is ugly and unreadable. It will also mess up git history a lot, so I'll
definitely vote against it.
Allman is much more acceptable, but style change is a significant change
for the project,
and there's been a lot of complaining here lately about "big changes".
śr., 19 mar 2025 o 02:03 Michał Ł
octl as it currently is
> will have any head scratching and long debugging session. Thoughts?
>
> Nathan
>
> On Thu, Mar 13, 2025 at 4:50 PM Kevin Witteveen
> wrote:
>
> > Hi Nuttx,
> >
> > This is a follow-up to GitHub issue #15856
> > <https://gi
I also don't understand this practice of separating documentation from
code.
When changes in the code have to be reflected in the documentation, what's
the point of splitting it into separate commits? If, for example, I do a
`git revert`,
it may happen that the documentation and code are out of syn
hen we can
think about LTS.
śr., 26 lut 2025 o 10:50 Alin Jerpelea napisał(a):
> On Wed, 26 Feb 2025, 10:32 raiden00pl, wrote:
>
> > -1 from me.
> >
> > 1. It's a waste of already limited resources in this project.
> >
> > 2. It makes life harder for con
-1 from me.
1. It's a waste of already limited resources in this project.
2. It makes life harder for contributors, by for example requiring
separation of PRs on arch/boards/doc. Extra work for contributors to
compensate for the project's limited resources is not okay.
3. Regarding the above poi
Hi Sebastian, it's a pity that your radio framework didn't go upstream.
The lack of a standardized interface for radios is a problem now.
Network interface for small radios, especially for LORA radios is overkill.
I think Greg later admitted that because he accepted sx127x as a character
driver. Th
I
> > > contributed in a "legacy" style and I recall at the time it being
> > > suggested I did them in the uorb-way...but I didn't, and haven't looked
> > > in detail.
> > >
> > > The hijack of this thread (by me!) has at least clarifie
What is missing in mcp9600_uorb.c is the `mcp9600_fetch()` interface. With
it supported,
this driver can behave the same like the legacy implementation, so all
sampling is controlled
by user-space logic, not kernel thread.
czw., 13 lut 2025 o 18:02 raiden00pl napisał(a):
> Yes, mcp9600_uor
gt; Using mcp9600_uorb.c on the other hand (since we don't have mcp9600.c
> anymore), even if the user is not using the uORB app, it needs to follow
> other approach, i.e. using ioctls for it.
>
> BR,
>
> Alan
>
>
>
> On Thu, Feb 13, 2025 at 1:26 PM raiden00pl w
rb` to use it.
czw., 13 lut 2025 o 17:11 Alan C. Assis napisał(a):
> Hi Mateusz,
>
> I think this is not the case with the MCP9600.
>
> Matteo, is it possible to keep the original driver and the new one?
>
> BR,
>
> Alan
>
> On Thu, Feb 13, 2025 at 1:02 PM raiden00p
`uORB sensors` is a misleading term. All new sensors are character drivers,
but with
a standardized and portable interface. `uORB` is an optional feature.
Legacy sensors in NuttX are the perfect example of a broken solution in
NuttX.
With old sensors it's not possible to create portable application
be backported to the
> stable, LTS releases.
>
> On Tue, Feb 11, 2025 at 12:46 PM raiden00pl wrote:
>
> > I personally don't care about LTS releases and it seems to me that Nuttx
> > doesn't
> > have the resources for it. But if there are people willing to wo
I personally don't care about LTS releases and it seems to me that Nuttx
doesn't
have the resources for it. But if there are people willing to work on this
this,
I wish them good luck. What I don't like is the fact that the new PR
requirements
for LTS will make life as difficult as possible for con
1. +1
2. +1
3. +1
4. +1
5. +1
6. +1
7. +1
8. +1
9. +1
10. -1
Broken API, broken features and any other broken code should be removed
even if
it breaks some users code. Legacy code means more work for maintainers,
worse
code quality and inconvenience for users. It's always been like this in
NuttX,
Support for peripherals in QEMU is very limited, and some peripherals
supported by QEMU are not available in new hardware. So the same
tests for qemu and real HW are just not possible for some targets.
Also configurations with all peripherals/features enabled are not possible
for many chips - we a
x27;t even
find.
Email for discussion and decision-making - OK, email as a knowledge base
and
an organized place with content - not really.
czw., 6 lut 2025 o 04:09 Tomek CEDRO napisał(a):
> On Wed, Feb 5, 2025 at 8:25 AM raiden00pl wrote:
> > But first we should determine what things
> Perhaps I would limit this to larger commits only (and all affecting
Build / Kernel / common arch code of course). GitHub bot tells you the
size of the pull request, so we can draw some line according to that.
And maybe it could also automatically set the mandatory number of
reviewers. This way s
As mentioned earlier, testing all boards is pointless, especially since the
project
has very limited resources. Choosing a few boards that will allow us to
test as many
things as possible is the most optimal approach.
But first we should determine what things we want to test, not what boards.
Know
I can only guess that this change was verified on QEMU. And here is another
problem that introduces many bugs from Xiaomi: testing changes only on QEMU.
This approach has no chance of detecting all bugs and is inherently wrong.
Meaningful tests on QEMU are not possible. Even in cases where
virtual
happy is, in my opinion, a great example of "bad engineering" or at least
"people pleaser" syndrome. But I understand that we can disagree here :)
pt., 31 sty 2025 o 23:43 Tomek CEDRO napisał(a):
> On Fri, Jan 31, 2025 at 10:09 PM wrote:
> >
> > On 2025-01-31 21:14:
Apart from the tool issue, what we miss the most are processes, in the
sense of
project management, not osdev ;). We have distributed teams and individuals
that
work towards their established goals. The problem is that the community
doesn't
know these goals. It may even be the case that the company
ow they
are causing problems. Most likely because it was sufficient at the time of
implementation and the author didn't take into consideration any other
applications or use cases. Which isn't surprising, it's hard to imagine all
the potential applications and design a good portable AP
How do you want to maintain compatibility between nuttx-apps and
nuttx while both are active development projects, and what's more
one of them is optional? It's not possible.
It would be possible if we assumed that the API in NuttX is perfect
and will not require changes, which is not true. There
Does Apache Foundation provide any project management tools?
I don't see anything interesting on https://infra.apache.org/services.html
If not, I guess we need to try with Github Projects.
pt., 31 sty 2025 o 14:22 Tomek CEDRO napisał(a):
> Hello world :-)
>
> As we discussed before we need a Roa
ss to detect issues early and report to us.
> >
> > BR,
> >
> > Alan
> >
> > On Wednesday, January 29, 2025, Simon Filgis<
> si...@ingenieurbuero-filgis.de>
> > wrote:
> >
> >> Just for my understanding, could I vote -1 for a re
> >
> > Best regards
> > Alin
> >
> > On Wed, 29 Jan 2025, 12:14 raiden00pl, wrote:
> >
> > > I completely agree that project management in NuttX is either lacking
> or
> > > completely non-existent. I think the lack of a generally accepted
t
napisał(a):
> hi
>
>
> On 29/01/2025 10:21, raiden00pl wrote:
> > Sebastian, so you're saying that you and your company have the resources
> to
> > develop
> > and maintain your own RTOS, but you lack the resources to help maintain
> > NuttX (e.g., co
Sebastian, so you're saying that you and your company have the resources to
develop
and maintain your own RTOS, but you lack the resources to help maintain
NuttX (e.g., code review, release testing.)?
This either doesn't make sense or you just don't want to participate in
this project.
Cherry-pick
> To be honest I didn't hear about this LWL (Lightweight Link) before,
what a great discovery, nsh directly over JTAG/SWD with no UART!!
Thank you Alan!! :-)
There is also RTT console support in NuttX, so you can use JLink debuggers
without any UART.
Also there are more powerful tools for Segger d
Can we just rename `SENSOR_TYPE_AMBIENT_TEMPERATURE` to
`SENSOR_TYPE_TEMPERATURE`
and update the comments that this type is "a general temperature sensor"?
The current definition is taken from Android, but NuttX is a more general
OS, used in various embedded
scenarios that go far beyond those of An
garbage.
>
>
> Thats how it should be done here, imho.
>
> The solution is not more resources (you will never get them), it's less
> depletion of available resources.
>
>
> Sebastien
>
>
> On 23/10/2024 10:35, raiden00pl wrote:
> > Sebastian, the practice of
Sebastian, the practice of recent days shows something completely
different. Without CI coverage,
compilation errors become common. Building all the configurations locally
to verify the changes will take
ages on most machines, and building for different host OSes is often not
possible for users.
W
+1
We need to pay more attention to the license of the code that is added. GPL
can destroy this project :(
śr., 16 paź 2024 o 07:33 Jukka Laitinen napisał(a):
> Hi,
>
> A kind reminder to everyone contributing code to NuttX;
>
> Please keep in mind that it is NOT allowed to copy code snippets f
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):
100 matches
Mail list logo
