> Am 24.03.2021 um 18:34 schrieb Tim:
>
> > I can also build in Bluetooth support and the demo app, but as far as
> > I can tell there are no actual Bluetooth host drivers in NuttX to
> > properly support a detected Bluetooth device. My custom board actually
> > has a SiLabs Bluetooth module on it
Hi Tim,
It depends on what you refers to Bluetooth: is it Bluetooth Classic or BLE ?
If you want BT BLE maybe it is better to use a MCU with BLE.
BR,
Alan
On 3/25/21, Tim wrote:
>> Am 24.03.2021 um 18:34 schrieb Tim:
>>
>> > I can also build in Bluetooth support and the demo app, but as far a
> Hi Tim,
>
> It depends on what you refers to Bluetooth: is it Bluetooth Classic or BLE ?
>
> If you want BT BLE maybe it is better to use a MCU with BLE.
>
Thanks Alan
Bluetooth LE, which is why I put a SiLabs module on the board and have it
working, but thought "hey, I might be able to offl
Why not use msec & usec delays?
Because the need is nsec delays
My question is:
Why not add a portable, general purpose nsec delay function to Nuttx?
El mié, 24 mar 2021 a las 22:34, Xiang Xiao ()
escribió:
> Another way to avoid the calibration is to reuse the hardware timer in the
> busy loo
Hi Tim,
On 3/25/21, Tim wrote:
>> Hi Tim,
>>
>> It depends on what you refers to Bluetooth: is it Bluetooth Classic or BLE
>> ?
>>
>> If you want BT BLE maybe it is better to use a MCU with BLE.
>>
>
> Thanks Alan
> Bluetooth LE, which is why I put a SiLabs module on the board and have it
> worki
> >> Hi Tim,
> >>
> >> It depends on what you refers to Bluetooth: is it Bluetooth Classic
> >> or BLE ?
> >>
> >> If you want BT BLE maybe it is better to use a MCU with BLE.
> >>
> >
> > Thanks Alan
> > Bluetooth LE, which is why I put a SiLabs module on the board and have
> > it working, but tho
Hi,
I was wondering if anyone is already using some MQTT library on NuttX. I see
many options some of which look like potential candidates for easy porting, but
if anyone already went through this process I would appreciate some feedback.
Thanks,
Matias
Hi Matias,
Yes, some people here are using mqtt-c on NuttX and it is working fine.
It needs some clean-up to be submitted to apps/
BR,
Alan
On 3/25/21, Matias N. wrote:
> Hi,
> I was wondering if anyone is already using some MQTT library on NuttX. I see
> many options some of which look like
BTW we need to have this PR integrated first:
https://github.com/apache/incubator-nuttx-apps/pull/566
On 3/25/21, Alan Carvalho de Assis wrote:
> Hi Matias,
>
> Yes, some people here are using mqtt-c on NuttX and it is working fine.
>
> It needs some clean-up to be submitted to apps/
>
> BR,
>
>
Great, maybe some draft PR could be submitted?
Regarding SSL, is it required to build? Maybe it can be initially integrated
without
SSL support?
Best,
Matias
On Thu, Mar 25, 2021, at 14:13, Alan Carvalho de Assis wrote:
> Hi Matias,
>
> Yes, some people here are using mqtt-c on NuttX and it is
Someone was asking the other day on Linkedin, so I pushed this:
https://github.com/Ouss4/MQTTC_NuttX
> Regarding SSL, is it required to build? Maybe it can be initially integrated
> without
SSL support?
You can use it with no SSL support. But MQTT-C supports multiple
crypto libraries, mbedTLS b
On Thu, Mar 25, 2021 at 5:25 AM Grr wrote:
> Why not use msec & usec delays?
>
> Because the need is nsec delays
>
>
Ok, I understand.
> My question is:
>
> Why not add a portable, general purpose nsec delay function to Nuttx?
>
>
1nsec means 1GHz, it is very hard to achieve the required accura
On Thu, Mar 25, 2021, at 15:02, Abdelatif Guettouche wrote:
> Someone was asking the other day on Linkedin, so I pushed this:
> https://github.com/Ouss4/MQTTC_NuttX
Great, thanks! I see the wrapper app is quite simple. Could we submit it
to nuttx apps repo?
>
> > Regarding SSL, is it required
Hi Matias,
On 3/25/21, Matias N. wrote:
>
>
> On Thu, Mar 25, 2021, at 15:02, Abdelatif Guettouche wrote:
>> Someone was asking the other day on Linkedin, so I pushed this:
>> https://github.com/Ouss4/MQTTC_NuttX
>
> Great, thanks! I see the wrapper app is quite simple. Could we submit it
> to nu
> 1nsec means 1GHz, it is very hard to achieve the required accuracy even
> with the high end CPU. But since the standard defines nano_sleep, up_ndelay
> looks not so unreasonable.
>
I don't mean 1 ns
I mean delays in the order of _dozens_ of ns
100 MHz (a very reasonable frequency nowadays) mea
On Thu, Mar 25, 2021 at 2:22 PM Grr wrote:
> > 1nsec means 1GHz, it is very hard to achieve the required accuracy even
> > with the high end CPU. But since the standard defines nano_sleep,
> up_ndelay
> > looks not so unreasonable.
> >
>
> I don't mean 1 ns
>
> I mean delays in the order of _doze
A trick I often used was writing to the volatile (!) CS pin control
register twice (or more).
The extra writes change nothing, but provide the tiny delay.
The compilers never optimized the extra writes away.
An obj file dumper and scope are handy to check the actual generated
code and delay.
A
On Thu, Mar 25, 2021, at 15:21, Alan Carvalho de Assis wrote:
> Hi Matias,
>
> On 3/25/21, Matias N. mailto:matias%40imap.cc>> wrote:
> >
> >
> > On Thu, Mar 25, 2021, at 15:02, Abdelatif Guettouche wrote:
> >> Someone was asking the other day on Linkedin, so I pushed this:
> >> https://github.c
On 3/25/21, Matias N. wrote:
>
>
> On Thu, Mar 25, 2021, at 15:21, Alan Carvalho de Assis wrote:
>> Hi Matias,
>>
>> On 3/25/21, Matias N. mailto:matias%40imap.cc>> wrote:
>> >
>> >
>> > On Thu, Mar 25, 2021, at 15:02, Abdelatif Guettouche wrote:
>> >> Someone was asking the other day on Linkedin,
Espressif has already signed an SGA, licensing shouldn't be an issue.
That said, I can submit it later if you guys want.
One question: where do we put the library?
A new "mqtt" folder?
On Thu, Mar 25, 2021 at 10:59 PM Alan Carvalho de Assis
wrote:
>
> On 3/25/21, Matias N. wrote:
> >
> >
> > On
I think it is better to put it at apps/netutils/mqttc
On 3/25/21, Abdelatif Guettouche wrote:
> Espressif has already signed an SGA, licensing shouldn't be an issue.
> That said, I can submit it later if you guys want.
> One question: where do we put the library?
> A new "mqtt" folder?
>
> On Thu
tl;dr: How do I statically allocate DMA buffers and prevent the heap
from overlapping them?
Details: On STM32H7, BDMA can only reach SRAM4 (64 KB starting at
0x3800:). The armv7m DCache line size means the buffers must be
allocated on a cache line boundary. So a DMA buffer must meet 2
requirem
Just don't add it to the primary heap: Add the region below and the
region above the DMA buffers with two calls to mm_addregion().
addregion (DMABUF_END, SRAM4_END - DMABUF_END, "SRAM4-A");
addregion (SRAM4_START, DMABUF_START- SRAM4_START, "SRAM4-B");
You can also create a different heap for
On Thu, Mar 25, 2021 at 7:54 PM Gregory Nutt wrote:
>
> Just don't add it to the primary heap: Add the region below and the
> region above the DMA buffers with two calls to mm_addregion().
>
> addregion (DMABUF_END, SRAM4_END - DMABUF_END, "SRAM4-A");
>
> addregion (SRAM4_START, DMABUF_START- SRA
Hi,
We are planning to port Nuttx on 'Nucleo-H743ZI2' development board. We need
support for the below peripherals configuration.
* USB OTG FS Host (Mass storage)
* Ethernet
* SD Card interface via both SPI and SDIO
The config file with the above peripherals support would speed our
Just don't add it to the primary heap: Add the region below and the
region above the DMA buffers with two calls to mm_addregion().
addregion (DMABUF_END, SRAM4_END - DMABUF_END, "SRAM4-A");
addregion (SRAM4_START, DMABUF_START- SRAM4_START, "SRAM4-B");
Where should I call mm_addregion() fro
This mostly exists under the H743ZI configuration. I made probably the
wrong choice and combined the both rev1 and rev2 in that config and there
is a board config to select which rev since they have subtle but important
pinout difference. The rev2 is like the other H7xx nuclei board while the
rev1
27 matches
Mail list logo
