Re: 答复: 答复: [External Mail]Re: defining a BLE GATT server

Let me clarify one thing: The approach we take is a pure userspace solution, it isn't related to NuttX kernel and no plan to upstream it. That is good to know. Thank you.  I will sleep better tonight. The major difference is where to put L2CAP/HCI code(userspace v.s. kernelspace) and it

Re: 答复: [External Mail]Re: defining a BLE GATT server

I'm agreeing with you Greg, anything that comes into Apps or the OS must use the socket API. Then we are in agreement.  I am a mother hen and will defend the OS architecture to the teeth (hmm.. hens.. teeth... sorry about the mixed metaphor). I don't get involved in most code changes.  I

Re: 答复: [External Mail]Re: defining a BLE GATT server

On 8/26/2020 10:56 AM, Gregory Nutt wrote: Lets bring this back to a constructive place. An Chao I really appreciate the detailed information that you wrote, while I don't think it will be appropriate to include directly upstream it is still valuable to know how you are trying to use

Re: 答复: [External Mail]Re: defining a BLE GATT server

Lets bring this back to a constructive place. An Chao I really appreciate the detailed information that you wrote, while I don't think it will be appropriate to include directly upstream it is still valuable to know how you are trying to use this and it helps us make an informed decision

Re: 答复: 答复: [External Mail]Re: defining a BLE GATT server

Mr.Greg, I really don't understand why you are so angry, and there are so many verbal attacks. I just share a feasibility. What I expect is discussion and respect, not devaluation. If you don't like it, just say it like others. Yes, I am angry.  I am very pissed off that you completely

Re: 答复: [External Mail]Re: defining a BLE GATT server

What you should do is to coordinate and and cooperate with the NuttX team to get help from the community.  If you chose to go your own way and not discussion or cooperation with the team, then you are on your own.  That code will not come into the repository. If you want to do things

Re: 答复: [External Mail]Re: defining a BLE GATT server

As mentioned in the title, this is just an experimental project that needs to discuss further the implementation of the bluetooth stack. The implementation of bt stack in userspace does not conflict with the current architecture, this is just a choice. On the contrary, the complete BLE+MESH

Re: defining a BLE GATT server

I fully agree with this. AF_BLUETOOTH is already in place, but it only implements "BTPROTO_L2CAP" all of the GATT and advertising/scanning related functionality is implemented over "BTPROTO_HCI" #define BTPROTO_L2CAP 0

Re: defining a BLE GATT server

it shouldn't invalidate the LL in principle. But for any change on the host layer I would like to know if there are plans or work in progress. On Mon, Aug 24, 2020, at 11:47, Gregory Nutt wrote: Also, I understand that Xiaomi intends to replace the entire Bluetooth stack with a newer BT 5.0 stack. I don't

Re: LVGL moving to Kconfig, how we could integrated better with them

If you can make LVGL optionally NOT generate its own config.h and .config we could indeed just include the Kconfig and Make.defs (as it is done now). I think generating the config file would be part of a "toplevel" LVGL build system which we would completely bypass. Couldn't it be done in

Re: LPWORK Queue and USB Host Serial

On 8/26/2020 7:28 AM, Gregory Nutt wrote: A short question concerning the use of LPWORK queue in FT232R and CDCACM USB Host drivers: Both block one LPWORK task per opened instance permanently. The FT232R rxdata_work USB transfer returns after each 16ms (USBHOST_FT232R_LATENCY) but since

Re: LPWORK Queue and USB Host Serial

A short question concerning the use of LPWORK queue in FT232R and CDCACM USB Host drivers: Both block one LPWORK task per opened instance permanently. The FT232R rxdata_work USB transfer returns after each 16ms (USBHOST_FT232R_LATENCY) but since there are always at least two status bytes

Re: 答复: [External Mail]Re: defining a BLE GATT server

I will add my two cents as well.  I have already responded in comments on PR #1651, but I will copy my reponse here form continuity: I am in 100% agreement with Brennan and Matias. I am very opposed to this change because it violates all of the architectural principles that have been

Re: LVGL moving to Kconfig, how we could integrated better with them

Of course it would be cool if you could simply do "make menuconfig" on NuttX and have LVGL options appear there, but I believe that would couple LVGL and NuttX build systems which may not be the best idea. I'm not sure if that can be done cleanly (it would always produce one .config and

Re: defining a BLE GATT server

I have been puzzling through the Goobledegook GATT server (GGK, https://github.com/moovel/gatt-server fork). It uses the Bluez D-Bus interface. It is GPLv3 so not a candidate for porting. And also not much use for understanding APIs since the OS interface is hidden inside of the Bluez D-Bus

Re: defining a BLE GATT server

On 8/24/2020 2:20 PM, Brennan Ashton wrote: On Mon, Aug 24, 2020 at 12:34 PM Gregory Nutt wrote: Some of the things you have speculated about would be contrary to these principles. The basic wireless rules are: 1. Network sockets are used to communicate with complex wireless networks (like

Re: defining a BLE GATT server

Thanks for the heads up. Would be good to get Xiao Xiang's input on this then. Maybe he already encountered this issue. You should also be aware of the wireless architectural principles of https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629397 Some of the things you

Re: defining a BLE GATT server

Also, I understand that Xiaomi intends to replace the entire Bluetooth stack with a newer BT 5.0 stack.  I don't know if that is still a plan of record or not, but you probably should coordinate Bluetooth architectural changes with Xiao Xiang in any event.

Re: defining a BLE GATT server

You're right, maybe I'm caught on the callback interface because that is how it is implemented now, but in the end there's always a packet you process. I still wonder if also having L2CAP in kernel would be better since it deals with multiple connection handling, packet fragmentation and so

NuttX project on Hackaday

Matias' bike computer project is featured on Hackaday: https://hackaday.com/2020/08/20/bike-computer-powers-on-long-after-your-legs-give-out/ Also interesting, but off topic, ESP32 Altair Emulator: https://hackaday.com/2020/08/20/esp32-altair-emulator-gets-split-personality/

Keyboard FeatherWing

Adam, Are you still working a the Giant Board?  This would be a good companion board: https://www.tindie.com/products/arturo182/keyboard-featherwing-qwerty-keyboard-26-lcd/ There is a "Solder Party" channel forum on discord.com.  Groguard discusses using the Giant Boards with the keyboard

Re: Color ANSI support in nsh

A basic terminfo/termcaps  could be very trivial A more general solution would be handy but what is there really in the embedded world that doesn't support vt100? There more code there is, the more interesting ways it can go wrong :-) I have sometimes used cat /dev/ttyS0 on the host as a

Re: Color ANSI support in nsh

I would suggest that you look at how this is handled in standard terminals. This works in the form of escape sequence which give a code that the terminal can interpret as being a color. This would make it available to applications in a standard form. Good point.  The GNU part of GNU/Linux

Re: Color ANSI support in nsh

This is my suggestion, it should be enabled by default, but disabled by default if CONFIG_DEFAULT_SMALL is selected. What do you think? I would prefer to see it just disabled by default.

Trending

apache/incubator-nuttx is a GitHub trending project: https://github.com/trending/c

Re: 10.0 Release?

On 8/14/2020 3:39 PM, Abdelatif Guettouche wrote: We've already agreed on the version numbering. It's pretty much the same as it was + the patch number. So if there is incompatible change to the APIs, we need to bump the major number to 10. of course, there are degreses of incompatibility. 

Re: cpp cxx help - No thread API

Guys, I think we should move your bitbucket libcxx to github.com/nuttx to make it more official. What do you think? Other (better) option should including official support to NuttX on llvm libcxx. i would NEVER recommend github.com/nuttx for any significant use.  There are many people with

Re: 10.0 Release?

Nathan started this here: https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.2 I would say let's fill that out, we can change it to 10.0 later. I will kick off getting the tracking board and the PR changes going in next week, that I thought worked quite well for realtime and async

10.0 Release?

We finally released 9.1.0 on 2020-07-22.  I think the target date for that one was 2020-07-01, wasn't it.  The next release should then be sometime next month, right? 2020-09-01?  Or 2020-09-22? I don't know what the policy of the NuttX Incubator is, but prior to Apache, I used the major

Re: Roadmap?

We probably should also include all Github Issues that are listed as enhancements. If we use a Github Project Board like Brennan suggested this would be pretty easy to link them there. Jira will link to github issues as well, as I recall.  We went through all of this in the early days of

Re: Roadmap?

Jira is another option available to us.

Re: Roadmap?

I made a wiki page with the raw list of things that people are asking for in this thread: https://cwiki.apache.org/confluence/display/NUTTX/Roadmap Check it out, add anything I missed, and correct errors I made. Maybe the next step would be to try to complete this list, then maybe

Re: Roadmap?

I am interested in industrial devices communicating by fieldbuses. I use the NuttX port of FreeModbus stack and I would like to see more port of communication stacks like this. I prefer CANopen and Profinet, There are several open source communication stack for these protocols. Where would

Re: USB host mass storage class automount.

Would it be acceptable that the automount handler is called from usbhost_storage.c, from a modularity point of view? Because that way it would be only a notification towards the work queue, using a mechanism that is already in place. I don't like the idea to have another kthread that does

Re: USB host mass storage class automount.

Would it be acceptable that the automount handler is called from usbhost_storage.c, from a modularity point of view? Because that way it would be only a notification towards the work queue, using a mechanism that is already in place. I don't like the idea to have another kthread that does

Re: USB host mass storage class automount.

But: I haven't yet found a way to determine if I enumerated really a mass storage class device. So with only activating mass storage it seems rather clean, but if I have multiple class drivers active, it gets complicated. Can you give a hint how to retrieve the type of driver bound to the

Roadmap?

One of the things that I think we are missing is a Roadmap to guide and prioritize new feature development.  Other RTOS' (like Zephyr) do have such published roadmaps and are responsive to needs and requests of users and sponsors.  I have even seen web pages where the Zephyr team has laid out

Re: stm32f7 CONFIG_RAM understanding

External SRAM? On 8/4/2020 1:08 PM, Oleg Evseev wrote: Hi, I wonder why stm32f7 boards has such RAM parameters in defconfigs: CONFIG_RAM_SIZE=245760 CONFIG_RAM_START=0x2001 Where do these numbers come from while memory map is this? изображение.png --- With regards, Oleg

Re: Setting MAC address on STM32.

Also as Mr. Greg explained the application needs to setup the MAC address when the connection was lost and recovered. I didn't mean to imply that.  It simply has be bring the network down and then bring it back up again when the link is again detected by the PHY. The MAC address is just a

Re: Setting MAC address on STM32.

On the other hand, the MAC address is a hard-wired address, accessed in a hardware specific way. In my opinion the application shouldn't mess with it and it is best to be set once during the hardware initialization. The code follows the same model and uses the same IOCTL commands as does

Re: Setting MAC address on STM32.

Yes I saw this, but it does not seem a very good option to me. It requires you to set up the hardware in the application, and does not seem very efficient. Where do you initialize the IP address?  You should use the same socket descriptor to call the ioctl to set the MAC address at that

Re: Setting MAC address on STM32.

Thank you both. I followed the example of same70-xplained, and essentially I do the exact same thing. However, as I get it, the final step would be to call stm32_macaddress() to set the address to the MAC. This function takes as an argument a struct stm32_ethmac_s which is private to the

Re: Some questions related PR#1478

Before we change the coding standard, I suggest that we get more feedback from the dev community. My opinion: If a loop does not require a body, I suggest to use braces, rather than a semicolon, because it is less prone to programmer error. ... I should not be so opposed to coding standard

Re: Some questions related PR#1478

My opinion: If a loop does not require a body, I suggest to use braces, rather than a semicolon, because it is less prone to programmer error. I would be okay with either: while (condition) { } or while (condition) {} And of the two, I think the second one expresses the intent best.

Re: [GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1487: libc: Avoid ctype function to evaluate the argument more than once

On 7/31/2020 8:44 AM, Xiang Xiao wrote: Macro version still evaluate the argument more than once regardless you name it kisdigit or isdigit. I am fine with any following combination: 1.lookup table for both userspace and kernel 2.normal function for both userspace and kernel 3.lookup table for

Re: Some questions related PR#1478

Hmmm... I don't agree. The Coding Standard encourages empty "while loops": https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard#while Why should this not applicable for "for loops"? I think there are many already in the tree. Actually, I think that is an error in the coding

Re: [GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1487: libc: Avoid ctype function to evaluate the argument more than once

  My size concern is only in the PROTECTED build mode.  In that case, the ROM table would be duplicated:  Once in user-space and once in kernel space.  That is the wasteful part because the OS does NOT do any significant string processing and is a case where there would be an unnecessary

Re: [GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1487: libc: Avoid ctype function to evaluate the argument more than once

Yes, you are right: function version is still 20Bytes bigger than macro version. Do you have a better solution to fix this problem? Just to remind people that my original size concern was not with the table approach.  I think the size if about a wash. Applications that do a lot of string

Re: Nuttx Cortex-A/R SMP I-cache support

There have been numerous fixes for Cortex-A SMP since 7.31.  You might want to upgrade. On 7/29/2020 10:19 AM, Mansfield, Ryan wrote: Hi, We are trying to enable SMP for a dual core ARM Cortex-R8. We are using a kernel based on NuttX-7.31, with added proprietary support for our embedded

Re: STM32WB

while working on BLE stuff with nRF52 I looked around for similar platforms that could be supported in NuttX. I looked at STM32WB, which is based on a dual-CPU and supports BLE (as well as various other 2.4GHz protocols). While not as open as Nordic why publishes the details on the low

Re: [GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1487: libc: Avoid ctype function to evaluate the argument more than once

It is a simple matter to see the cost of a PR if we add bloaty (https://github.com/google/bloaty) to ci. Great please file the simple PR to add it. This is not trivial as we need to manage the artifacts from previous builds to do the comparison or double the build time. We heard you last

Re: [GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1487: libc: Avoid ctype function to evaluate the argument more than once

But how long does it take you, when the linker tell you, you have over flowed .text by 256 bytes? When you overflow memory due to a large number of modest size increases, there is no way to recover.  You are basically screwed because nothing can really be done.  The only way to prevent

Re: AMD64 arch

On ARM, I am using Zero Latency Interrupts for the really critical (and not time-consuming) stuff. That would be things like sampling inputs and updating outputs. I haven't used NuttX on amd64, so I don't know how to implement that there. The current implementation of zero latency

Re: Can we implement ctype functions through table?

Another negative thing about the table driven C type functions is that in the PROTECTED build, there will need to be two ctyle look-up tables:  One in user space and one in kernel space.  So the overhead will 512, not 256, bytes in that configuration. Perhaps we would use the macros inside

Re: Can we implement ctype functions through table?

Another negative thing about the table driven C type functions is that in the PROTECTED build, there will need to be two ctyle look-up tables:  One in user space and one in kernel space.  So the overhead will 512, not 256, bytes in that configuration. Also, a minor correction: The table

Re: Can we implement ctype functions through table?

And if the macro versions are employed a few times then they would quickly grow larger than the table anyways. The table access is not free.  There is overhead in both cases, depending primarily on the complexity of the ctype comparison. For is isdigit() the comparison is currently just:

Re: Can we implement ctype functions through table?

On 7/29/2020 7:41 AM, Gregory Nutt wrote: What about platforms like AVR?  That would not be a good decision for AVR since it is a harvard machine and cannot access data in ROM without special operations. This is not a show stopper, at least not for the AVR.  While a table-driven solution

Re: Can we implement ctype functions through table?

What about platforms like AVR?  That would not be a good decision for AVR since it is a harvard machine and cannot access data in ROM without special operations. This is not a show stopper, at least not for the AVR.  While a table-driven solution is not optimal for AVR, it will support

Re: AMD64 arch

One thing that would be important would be to understand what processor you are using. If there is some specific hardware, I would also be willing to buy a board and help out... although I am no x86_64 expert (I did do the i486 port some years ago, but that is about the extent of that).

Re: AMD64 arch

I think the answer is yes x86_64 is supported. I haven't used it myself, but here's the NuttX x86_64 status blurb: https://cwiki.apache.org/confluence/display/NUTTX/About#80x86 Certainly it builds.  Our CI builds the x86_64 configurations on every commit.  There is also PCIe support on a

IP Clearance

We have talked a little about IP clearance on the NuttX podling project but I am not sure if anyone really appreciates the magnitude of this effort:  There is 13 years of commits, possibly 50,000 total commits, many hundreds of contributors, 1000's of files, 1.5 million lines of code, and

Re: Integrating Nuttx to a firmware project.

a dumb script like that one Abdelatif demonstrated will multiple calls to kconfig-tweak can be used to turn on all of the configuration options that you need. Cool! I didn't know I could do this. Now that I know, I think I'll convert my configs to work this way. It will be much more

Re: Integrating Nuttx to a firmware project.

If no tool exists for this, Yes, kconfig-tweak. kconfig-tweak will enable or disable any setting configuration setting.  The full set of debug options to enable is project-specific, but a dumb script like that one Abdelatif demonstrated will multiple calls to kconfig-tweak can be used to

Re: Markdown READMEs?

For those really opposed to HTML, another option is to simply use the Confluence versions of the documents here: https://cwiki.apache.org/confluence/display/NUTTX/Documentation These are the same documents that are currently in nuttx/Documentation.  They are read-only now (since the master is

Re: Markdown READMEs?

I will do a PR to your branch and repo, but will you create a branch and put your changes on it? The branch should be called something like feature/sphinx-docs. If you do that, I can do PR directly to that branch. Having it on a branch other than master will make it easier to submit later,

Re: Markdown READMEs?

Hi guys. In the meantime, I carefully converted most of the readmes in the `apps` repository. Four folders left - [x] main readme - [x] netutils - [x] wireless - [x] examples - [x] modbus - [x] fsutils - [x] gpsutils - [ ] testing - [ ] system - [x] tools - [x] industry - [x] interpreters -

Re: oneshot or watchdog?

On 7/17/2020 1:48 PM, Matias N. wrote: To meet the BLE timing specification, we need a timer resolution in microseconds and support for BLE/RADIO events capture. There is no capture interface for RTC and maximum counter resolution is 30.5us which can be not sufficient. As far as I know, the main

Re: Markdown READMEs?

Please make sure the readmes are still easily readable in vim and other plain text editors. Plain text is good. underlined plain text interpreted by github is still readable (markdown?) anything that requires writing explicit tag in the readme text files should be avoided imho. also,

Re: Out of tree board definition

On 7/17/2020 7:52 AM, Pavel Ionut wrote: Hello, As i read in some posts and scrolled through configure.sh, it should be possible to have a board definition outside the nuttx/boards/** location. My current setup is: apps - (submodule) nuttx - (submodule) board - Makefile - Make.defs

Re: Integrating Nuttx to a firmware project.

When not yet creating a custom board, I simply copy the config file and put it somewhere inside the workspace. If you eventually create a custom board, you can then place it in the proper directory (board/configs/*/defconfig). Doing it this way also allows you to configure nuttx with my

Re: Integrating Nuttx to a firmware project.

On 7/13/2020 3:00 PM, Fotis Panagiotopoulos wrote: Hi everyone! I am new to Nuttx but I would like to use it for my next projects. For the moment I am porting one of my big projects to Nuttx (that was previously working with another RTOS). However, I am a bit confused on how I should set up our

Re: close() socket called in second thread combined with reconnect kills eth (stm32h743zi)

On 6/30/2020 2:58 AM, Reto Gähwiler wrote: Hello Everyone, I am facing the following problem working with nuttx and ethernet connections. A TCP socket is setup as blocking and connected to the server. The connection is handled in one thread which hangs in the recv call and processes the data if

Re: Interfacing with terminal device using termios in canonical mode.

You might want to try using apps/system/readline to read lines from serial.  It has some tricks that make it behave a little more like canonical mode. If you something more like a Bask command line, then you might also consider apps/system/cle which works like readline but provides for a

Re: Interfacing with terminal device using termios in canonical mode.

On 7/4/2020 9:48 AM, Gregory Nutt wrote: I am trying to communicate with sensor via UART. I want to use canonical input mode because my sensor sends its data line by line. For this purpose I set up terminal interface like below:    structtermios config;    tcgetattr(_fd, )    /* Canonical

Re: Interfacing with terminal device using termios in canonical mode.

I am trying to communicate with sensor via UART. I want to use canonical input mode because my sensor sends its data line by line. For this purpose I set up terminal interface like below:    structtermios config;    tcgetattr(_fd, )    /* Canonical Mode Selection */    config.c_lflag |=

Re: SVD -> header generator

I just looked at that header and looks like a "no warranty" disclaimer. Does not impose any restriction on generation code based on that file. I am not an attorney and not qualified to give a legal opinion. But that has never stopped me before. A copyright covers the presentation of a

Re: Scheduling work from a worker using the same work_s

I have a few spots in my code where I am doing something, and I'm just now realizing I'm not explicitly sure if it's supported or not. Here is my question: Can work_queue be called from within a worker function that uses the same work_s struct? Yes. The documentation only says that if there

Re: NXView

It's a reasonable function partitioning. How about we define an interface like syslog_channel_s between note and driver? So we can plug in the different transport like syslog. The correct way to redirect streams within the OS is to use NuttX stream interfaces.  Forget about systlog

Re: Help with Apache Github Invite

I still can't seem to get an invite from the Apache Github account, despite having 2FA enabled on Github, and linking my Github user name through the self-service portal. I have had this problem since we moved to Apache, but I haven't needed access until now. Who is the right person to ask

Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC1 release

Comparing with V9.0: NuttX 9.0 $ arm-none-eabi-size nuttx textdata bss dec hex filename 68624 1042496 71224 11638 nuttx NuttShell (NSH) NuttX-9.0.0 nsh> free total used freelargest Umem: 192976 7536 185440

Re: CAN driver and critical section use

I wonder if it is right to call nxsem_wait while in critical section? Yes, it is fine to do that.  The OS will exit the critical section while waiting.

Re: libcxx std::thread leaks 48 bytes due to missing implementation of pthread destructor

I have to get something out the door today, but I'll be back on this tomorrow and will contribute to your branch. In a pinch, you can use a pthread_cleanup() callback.

Re: libcxx std::thread leaks 48 bytes due to missing implementation of pthread destructor

Would userpace_s need to have an additional function pointer for pthread_cleanup? Similar to pthread_startup? Is the up_pthread_start/pthread_startup functions a good example to follow for how to call in user mode? If you look at Issue 1263, that is not what I am proposing:

Re: libcxx std::thread leaks 48 bytes due to missing implementation of pthread destructor

On 6/28/2020 12:41 PM, Gregory Nutt wrote: Would userpace_s need to have an additional function pointer for pthread_cleanup? Similar to pthread_startup? Is the up_pthread_start/pthread_startup functions a good example to follow for how to call in user mode? If you look at Issue 1263

Re: libcxx std::thread leaks 48 bytes due to missing implementation of pthread destructor

... one objective that I have is to move all of the pthread logic out of the kernel and into libs/libs/pthread.  The pthreads interfaces are not part of the kernel in other Unix-like implementations. The kernel does provide certain necessary hooks, but the majority of the implementation of

Re: libcxx std::thread leaks 48 bytes due to missing implementation of pthread destructor

Would userpace_s need to have an additional function pointer for pthread_cleanup? Similar to pthread_startup? Is the up_pthread_start/pthread_startup functions a good example to follow for how to call in user mode? If you look at Issue 1263, that is not what I am proposing:

Re: libcxx std::thread leaks 48 bytes due to missing implementation of pthread destructor

Hi, Anthony, I just found an issue with using libcxx std::thread library on NuttX. The std::thread implementation uses pthread_key_create and pthread_setspecific in order to setup a destructor that should be called to cleanup the memory. Of course, it became pretty obvious what was wrong once

Re: NuttX supported boards web page?

On 6/26/2020 3:43 PM, Adam Feuer wrote: Hi, There used to be a web page that listed NuttX supported boards– but I can't find it on the new nuttx.apache.org website. Does anyone know where that page is? cheers adam Got https://cwiki.apache.org/confluence/display/NUTTX/Nuttx Follow the link

Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

On 6/24/2020 9:20 AM, Alan Carvalho de Assis wrote: Hi Greg, On 6/24/20, Gregory Nutt wrote: Changing the default is not the problem. The problem is when the default configuration value is changed, the all configurations effected by that change in the default setting should be updated so

Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

Yes, it should be nice to have bloaty integrated on CI system to ring an alarm when something like this happen. If it works as advertised, then this would be a good idea.  Some gradual code growth is natural natural due to the nature of the NuttX roadmap -- to be a complete, small POSIX OS

Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

Started looking and there are some changes in the diff in the generated config.h as can be seen here One change is the date command is no longer disabled by default. This accounts for 2304 bytes, leaving only 800 byte change. I'm not sure if changing the default was expected, but I dont think

Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

On 6/23/2020 6:59 PM, Gregory Nutt wrote: I compared it to release 9.0 and noticed it increased about 3 KiB of Flash usage, but I didn't check further to see what happened. NuttX 9.0 $ arm-none-eabi-size nuttx     text   data    bss    dec    hex    filename    68624

Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

I compared it to release 9.0 and noticed it increased about 3 KiB of Flash usage, but I didn't check further to see what happened. NuttX 9.0 $ arm-none-eabi-size nuttx text data bss dec hex filename 686241042496 71224 11638 nuttx NuttShell

Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

On 6/23/2020 12:36 AM, Brennan Ashton wrote: Hello all, Apache NuttX (Incubating) 9.1.0 has been staged under [1] and it's time to vote on accepting it for release. If approved we will seek final release approval from the IPMC. Voting will be open for 72hr. Because this project targets embedded

Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

On 6/23/2020 12:36 AM, Brennan Ashton wrote: Hello all, Apache NuttX (Incubating) 9.1.0 has been staged under [1] and it's time to vote on accepting it for release. If approved we will seek final release approval from the IPMC. Voting will be open for 72hr. Because this project targets embedded

Re: ftw/fts

The core of these functions should be the same as the logic in apps/insulin in cmd_ls() that handles the 'lsd _R' command. Of course, I meant 'ls -R'.  I don't know what I was on. I am referring specifically to the function nsh_foreach_direntry() which is actually in nsh_fsutils.c.  It

Re: ftw/fts

The core of these functions should be the same as the logic in apps/insulin in cmd_ls() that handles the 'lsd _R' command. Of course, I meant 'ls -R'.  I don't know what I was on. I am referring specifically to the function nsh_foreach_direntry() which is actually in nsh_fsutils.c.  It is

Re: Creating 9.1.0-RC0

With regards to bringing the release notes to the repo, that needs to go to master then backported to the release branch. Are we all on the same page with this? +1 We also need to update a couple of documentation files to add any new board, chip or architecture. Yes, there is the

Re: MCU only booting from reset via SWD when compiled without optimizations?

On 6/21/2020 4:36 PM, Gregory Nutt wrote: I will consider this possibilities, thanks. What is driving me crazy is that it actually seems to be triggered by the binary being bigger than 256KB (MCU has 512KB, dual bank). I already had to use openocd from git since it would not flash

Re: MCU only booting from reset via SWD when compiled without optimizations?

I will consider this possibilities, thanks. What is driving me crazy is that it actually seems to be triggered by the binary being bigger than 256KB (MCU has 512KB, dual bank). I already had to use openocd from git since it would not flash the image in that case. Now openocd flashes

<    3   4   5   6   7   8   9   10   11   12   >