Re: PCF8575 driver for NuttX

>> >>> In a quick search I noticed that i2c_vbus_initialize() never was part >>> of NuttX, >> >> OK, that’s not good. What’s the best way to submit it now? >> > > No idea, I think this function is something you created for your project. > > How is i2c_vbus_initialize() defined in your source

Re: PCF8575 driver for NuttX

> In a quick search I noticed that i2c_vbus_initialize() never was part > of NuttX, OK, that’s not good. What’s the best way to submit it now?

Re: PCF8575 driver for NuttX

> > ... > > int stm32_pcf8575_initialize(void) > { > struct i2c_master_s *i2c = NULL; > struct ioexpander_dev_s *ioe = NULL; > int ret = OK; > > i2c = stm32_i2c_register(I2C_BUS); /* I2C_BUS is your I2Cx bus > number (0, 1, etc) */ &

Re: PCF8575 driver for NuttX

Hi, Gustavo, You might consider using the I2C IO expander driver I wrote some time ago to manage a multi-tiered tree of I2C bus expanders. The advantages are: * I2C sub buses are transparently available to application space through /dev/i2c* * transparently manages hierarch of I2C bus expan

Re: NuttX on FreeBSD survey

>> >> The target HW was STM32F407ZG. I built my own NuttX toolchain for it. > > How? Could you write a bit more? In the early days, Greg modified buildroot to build a GNU toolchain specifically for NuttX (include files included). I wanted a toolchain that used the hard-float ABI for Armv7E-

Re: NuttX on FreeBSD survey

>> I haven’t had the chance to use NuttX in some time, but the last >> project I worked on I compiled NuttX on FreeBSD and MacOS. >> > > Hi, > > what kind of hardware did you use? > > Regards, > Milan The target HW was STM32F407ZG. I built my own NuttX toolchain for it. Regards, -david

Re: NuttX on FreeBSD survey

Hi, Milan, I haven’t had the chance to use NuttX in some time, but the last project I worked on I compiled NuttX on FreeBSD and MacOS. Cheers, -david > On Jul 31, 2023, at 12:52 AM, Milan Obuch wrote: > > Hi, > > I'd like to know who else builds NuttX on FreeBSD - right now I know > just on

Re: [Breaking change] Move nxmutex to sched

> On Apr 1, 2023, at 12:54 PM, David S. Alessio > wrote: > > > >> On Mar 31, 2023, at 9:34 AM, Gregory Nutt > <mailto:spudan...@gmail.com>> wrote: >> >> On 3/31/2023 8:56 AM, Gregory Nutt wrote: >>> >>>> Even more. In my

Re: [Breaking change] Move nxmutex to sched

> On Mar 31, 2023, at 9:34 AM, Gregory Nutt wrote: > > On 3/31/2023 8:56 AM, Gregory Nutt wrote: >> >>> Even more. In my previous example if semaphore is posted from the interrupt >>> we do not know which of TaskA or TaskB is no longer a "holder l" of a >>> semaphore. >>> >> You are right. I

Re: [Breaking change] Move nxmutex to sched

> On Mar 30, 2023, at 3:23 PM, Gregory Nutt wrote: > > > In his Confluence paper on "Signaling Semaphores and Priority Inheritance”, > > Brennan Ashton’s analysis is both thorough and accurate; ... > > Minor fix. I wrote the paper, Brennan converted the Confluence page from an > older Docu

Re: [Breaking change] Move nxmutex to sched

All, In his Confluence paper on "Signaling Semaphores and Priority Inheritance”, Brennan Ashton’s analysis is both thorough and accurate; and his conclusion that There should then be no priority inheritance operations on this semaphore that is used for signalling. is unassailable. It’s impor

Re: RTC synchronization with system time

Hello, Michal, You might want to take a look at PTP (Precision Time Protocol) https://en.wikipedia.org/wiki/PTPd and PTPd, a BSD-licensed implementation: https://github.com/ptpd/ptpd PTP is designed to sync the

Re: ZeroMQ

All, ZeroMQ is/was quite popular, but its author redesigned it, created a much cleaner implementation called “nanomsg”, ref: https://nanomsg.org/documentation-zeromq.html ref: https://nanomsg.org/index.html

Re: Which control version software are you using? //was Re: Poll: Which OS are you using to compile NuttX?

    CONFIG_VERSION_STRING, CONFIG_VERSION_BUILD);#endifFinally, in a NuttX prompt: cat /proc/versionwill produce something like this:Blade-v1-2-gdf65129b4e+, master, topaz/dsa, Sat 25-Sep-2021 11:01:29 PDTCheers,-david gen_gitrev.sh Description: Binary data On Sep 25, 2021, at 12:02 AM, Simon Fil

Re: Which control version software are you using? //was Re: Poll: Which OS are you using to compile NuttX?

I’d like to see my git version script be brought back into mainstream. > On Sep 24, 2021, at 3:58 PM, Alan Carvalho de Assis wrote: > > Hi David, > > Nice you hear from you. > > I'm also using git: #1 > > BR, > > Alan > > On 9/24/21, David S.

Re: Poll: Which OS are you using to compile NuttX?

Hi, Alan, It’d be good to know how developers are managing their code: 1) git 2) mercurial 3) SVN 4) zip files on floppies 5) none My money is on #1 ;) Cheers, -david > On Sep 24, 2021, at 2:07 PM, Alan Carvalho de Assis wrote: > > Hi Flávio, > > That is good idea, but I think we need to hav

Re: [Discuss] Migrate the build system to CMake

> On Jun 9, 2021, at 12:20 PM, Brennan Ashton wrote: > > On Wed, Jun 9, 2021, 11:04 AM Fotis Panagiotopoulos > wrote: > >> For me, cmake would be a no. >> The reasons are greatly outlined by Sebastien. >> >> However, I am not very experienced with it. (I just never liked it...) >> Are there

Re: Undefined reference to longjmp/setjmp

Makefile and a few patches. The Makefile would fetched the Lua tarball, applied the patches, and built it. We can recreate this if interested… Cheers, -david > On Jun 9, 2021, at 11:51 AM, David S. Alessio > wrote: > > Hello, Foti, > > I wrote setjmp/longjmp for armv7-m s

Re: Undefined reference to longjmp/setjmp

Hello, Foti,I wrote setjmp/longjmp for armv7-m some time ago.  The code should be in file: arch/arm/src/armv7-m/gnu/up_setjmp.SIf not, it’s attached here.Cheers,-david up_setjmp.S.gz Description: GNU Zip compressed data On Jun 9, 2021, at 11:10 AM, Fotis Panagiotopoulos wrote

Re: NuttX system load

> On May 11, 2021, at 11:22 PM, James Dougherty wrote: > > Hi Folks, > > What is an easy way to compute the system load on Nutt-X? > I don't need the procinfo (Unix LA) just current CPU load and > optimally, I would like a measure 0-1000 where I can get 4 digits of > precision ... > The simp

Re: How to use small I2C EEPROMs the NuttX way?

On Apr 29, 2021, at 10:12 AM, Frank-Christian Kruegel wrote: > > Am 29.04.2021 um 15:23 schrieb Gregory Nutt: >> There are several Microchip/Atmel boards that come with an Atmel MAC in >> AT24MAC402 EEPROM. You should be able to clone that logic (including >> setting the MAC address). See: >>

Re: libcxx and buildroot toolchain

Slightly off topic, but related: Is NuttX’ buildroot been adopted into Apache along with NuttX? I looked for it, but couldn’t find it. I have a few updates to push (gcc 8.4, 9, 10). I’d really like to share these… Regards, -david > On Jan 9, 2021, at 8:57 AM, Xiang Xiao wrote: > > On Sat

Re: [DISCUSS] Remove Windows Native support?

> On Jan 18, 2020, at 3:48 PM, Gregory Nutt wrote: > > >> This is not to say that this is a 100% stable development platform. There >> are still a few dangling, loose ends that I am aware and most likely more >> that I am not aware of. ... So basic functionality is there, but any real >

Re: Apache Code Relese (Was Re: Side-effects of removing (void))

> On Jan 13, 2020, at 11:35 AM, Nathan Hartman wrote: > > On Mon, Jan 13, 2020 at 2:12 PM David S. Alessio > wrote: > >> >> >>> On Jan 13, 2020, at 5:14 AM, Gregory Nutt wrote: >>> >>> >>>> I think once the workflow is

Re: Apache Code Relese (Was Re: Side-effects of removing (void))

> On Jan 13, 2020, at 5:14 AM, Gregory Nutt wrote: > > >> I think once the workflow is complete we should froze the master and >> keep accepting patch into dev branch. This is my point of view, I >> don't know if we will implement it. > > I think we should create a release branch and freeze

Re: problem booting NuttX on SAMA5D3-Xplained

Hello Adam, Make sure you compile with debug info enabled and no optimization. Then, since you mentioned you have a Segger J-Link JTAG probe, I highly recommend you use Segger’s debugger Ozone (free J-Link probes) — you’ll be able to easily single-step and determine what’s going wrong… Regard

Re: Testing the new repository

> >>> There is no workflow definition. DavidS started a thread, but so far it >>> has only general principles, no work flow. >>> >> I for one struggle to “define a workflow” without using the vernacular of >> the underlying tool (git + githug/gitlab/bitbucket). Best practices SW >> developme

Re: Testing the new repository

> > There is no workflow definition. DavidS started a thread, but so far it has > only general principles, no work flow. > I for one struggle to “define a workflow” without using the vernacular of the underlying tool (git + githug/gitlab/bitbucket). Best practices SW development workflows,

Re: Testing the new repository

> > If we adopt the naming conventions of using pr in the branch name then the > fact it is a PR is self referential in nay context command line/web/tablet > >> These random named and created branches just confuse people who clone the >> repo. > > I agree with is in part, naming as in the OS i

Re: New Apache NuttX Repositories

Greg, On a tangental note, what will become of our remaining repos: buildroot I’m preparing a PR to upgrade binutils and gcc! Can you still accept updates on Bitbucket? tools nxwidgets Regards, -david > On Dec 20, 2019, at 2:24 PM, Gregory Nutt wrote: > > [Cross posting to both the (depr

Re: [DISCUSS - NuttX Workflow]

We’ve digressed a bit on this thread. Let’s see if we can reboot DavidS’ Workflow thread and keep the thread on topic. Let me start by stating a few [obvious] objectives: Keep things simple for those NuttX users who prefer to work with a zip’d release. provide best-practice tools and workflow t

Re: Wiki Backup

> On Dec 17, 2019, at 12:21 PM, Justin Mclean wrote: > > Hi, > >> When things are ready and stable, I will disable nutt.org and redirect that >> to the Apache Confluence website. Just let me know when nuttx.org is no >> longer needed. nuttx.com will also be be redirected. Will that be at

Re: Wiki Backup

Brennan, Great work. It looks great; and you made it look easy ;) Cheers, -david > On Dec 17, 2019, at 6:43 AM, Xiang Xiao wrote: > > The new wiki look great, thanks your hard work, Brennan! > > -Original Message- > From: David Sidrane > Sent: 2019年12月17日 17:53 > To: dev@nuttx.apa

[TEST]

Testing… I’ve joined.