Re: [nuttx] nuttx.org going away
On 2020-08-30 10:36:25, patacongo wrote: > > For many years, the NuttX website was at nuttx.org. However, when NuttX > joined the Apache Software Foundation (ASF) as an incubating project, the > website was redesigned and is now at nuttx.apache.org. The nuttx.org > currently just redirects to nuttx.apache.org. > > I will be ending that re-direction primarily do to certificate issues that > are just not worth bothering with. So within the next 24 hours, nuttx.org > will no longer take you to the nuttx.apache.org website. Please update > your links. Wouldn't it be better to at least simply write "project moved to nuttx.apache.org" and maybe some usefull links like wiki, mailing list, git repo etc? Right now someone might think project is dead or something if one visits that site from an old resource. Crossposting to dev@nuttx.apache.org -- .-.---.-----.--. | Michal Lyszczek | Embedded C, Linux | Company Address | .-. open source | | +48 727 564 419 | Software Engineer | Leszczynskiego 4/29 | oo| supporter | | https://bofc.pl `.--: 50-078 Wroclaw, Pol | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^-^--' signature.asc Description: PGP signature
Re: [nuttx] nuttx.org going away
On 2020-09-16 06:34:04, patacongo wrote: > > > Wouldn't it be better to at least simply write "project moved to > > nuttx.apache.org <http://nuttx.apache.org>" and maybe some usefull links > like wiki, mailing > > list, git repo etc? Right now someone might think project is dead > > or something if one visits that site from an old resource. > > Sure, but the problem is that nuttx.org is not a website. It is just a > domain name that I own that is parked at GoDaddy.com. It could re-direct, > but it cannot serve up any pages. Well, someone could host such simple site on his own webserwer. It would be best if that was someone trustworthy so he doesn't replace links with malicious ones somewhere in the future. I could host it on my server if you wish. -- .-----.---.-.--. | Michal Lyszczek | Embedded C, Linux | Company Address | .-. open source | | +48 727 564 419 | Software Engineer | Leszczynskiego 4/29 | oo| supporter | | https://bofc.pl `.--: 50-078 Wroclaw, Pol | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^-^--' signature.asc Description: PGP signature
Re: [nuttx] nuttx.org going away
On 2020-09-16 07:52:48, patacongo wrote: > > I could host it on my server if you wish. > > I can't transfer the name to anyone else. The name now belongs to the > Apache Software Foundation (or it will if/when the project graduates). No, no. I would never suggest to tranfer domain rights to me. You either (1) specify DNS server for the domain (that will point to my dns server) or (2) you manage your own DNS zone and only add "A" record and point it to my server. (2) is definately a way to go, since (1) allows me to setup subdomains and even mail addresses with nuttx.org domain, while (2) will allow me to control contents of single "http://nuttx.com"; domain - which of course you can revoke by removing "A" record in your DNS zone. Mind that (2) will also allow me to, for example do 'ssh nuttx.org', which I will be able to redirect anywhere. So yeah, you really need to ask yourself the question if you can afford to give such power to some random dude on the net. I'm not saying I will do any of it. But how can you know? -- .-.---.-.--. | Michal Lyszczek | Embedded C, Linux | Company Address | .-. open source | | +48 727 564 419 | Software Engineer | Leszczynskiego 4/29 | oo| supporter | | https://bofc.pl `.--: 50-078 Wroclaw, Pol | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^-^--' signature.asc Description: PGP signature
Re: Problems Flashing
On 2024-06-12 07:35:27, Felix Leonbacher wrote: > Hey Guys, > > I am an embedded systems Student in Germany and wanted to use ur apache > nuttx in my project. Sadly I am unable to flash it. I have a STM32F207 > nucleo-144 and when I come to > openocd -f interface/stlink-v2.cfg -f target/stm32f2x.cfg -c 'init' \ > -c 'program > nuttx/nuttx.bin verify reset' -c 'shutdown', > it says checksum mismatch Hmm... just a guess, could be that you are missing flashing address? For STM it should be 0x0800, so maybe try doing openocd -f interface/stlink.cfg -f target/stm32f2x.cfg -c 'program nuttx.bin 0x0800' Also, it may be wise to paste whole log from openocd, there may be information you think is useless but could be vital. Second guess, try omitting 'verify', I flash without it in debug sessions and never had any problem with program. -- .-----.---.--.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: How to demystify some myths about NuttX
On 2024-07-09 09:49:16, Alan C. Assis wrote:
> I think many people outside our community have a misconception about NuttX:
> They think it is a Linux/Unix RTOS that needs to have a shell integrated
> into it.
>
> Note that all boards are required to have a "nsh" board profile, it was a
> suggestion/requirement to confirm that the system works correctly. There is
> not wrong with it, but it sends a message that NuttX needs it to exist.
>
> How to fix it?
I think I would be good if nuttx had something like /sbin/init that would
do some very simple service management. Then you could just tick
"Start NSH after boot up". Programs would probably be had to added via
some compile-time header file that would look like that:
| struct program
| {
| const char *name;
| int priority;
| int stack_size;
| main_t entry_point;
| int pid;
| };
|
| struct program programs[] =
| {
| #ifdef CONFIG_EXAMPLES_NSH
| { "console", 50, 2048, nsh_consolemain },
| #endif
| #ifdef CONFIG_SOME_DAEMON
| { "some-custom-daemon", 50, 2048, daemon_function },
| #endif
| { NULL, 0, 0, NULL }
| };
And program in its simplest form would do:
| #include
| int main(int argc, char *argv[]) {
| for (int i = 0; programs[i].name != NULL; ++i) {
| struct program *p = &programs[i];
| printf("starting: %s\n", p->name);
| p->pid = task_create(p->name, p->priority, p->stack_size,
| p->entry_point, NULL);
| }
| for (;;) sleep(UINT_MAX);
| }
I think such init could also handle all initialization code (so not only
starting up daemons). It could be more clear than current board initialization
routines which are a little bit confusing (for me at least).
That would solve 2 problems. It would be very clear that NSH is not needed, and
user would have an easy way to start it's own daemons/applications.
> Suggestions about how to proceed to archive it are welcome.
> Probably we will need collective help to archive it for all boards.
Other problem I've seen is bad (or rather lack thereof) press. Each time
I propose nuttx for some project it's a lot of hesitance and ultimately
decision to go with zephyr becuase it "supports more things". Which is
a lie, because with my experience zephyr has a lot of demos just to show
off "how many things they support". But it's all demo and nor production
quality. Nevertheless - this sells. And later when it's clear that zephyr
was lying - it's too late to go with anything else because months of work
was already put into zephyr, so noone will start over.
So nuttx definiately lacks press and exposure. Basically noone I worked with
heard about nuttx until I mentioned that. A lot of programmers are hyped
when I explain what and how it does things - but it all ends up with zephyr
because of "all the supported hardware it has".
For ppl to consider nuttx, they first need to hear about it. People (especially
useless managers) will need benchmarks - like how much flash/ram it uses.
How it performs. Will their hardware be supported.
It would not hurt for things to be more user friendly. I admit, initializing
zephyr is easy. Unpack SDK, west init, compile, flash and you are done.
And nuttx? Download and put compiler in path. Clone nuttx AND apps in same
directory. Configure. Compile. Learn your debugger to flash. On zephyr you
do 'west flash' and it knowns which discovery board is used and it uses
apropriate tool and arguments. This is good, I will admit it.
So nuttx would need some SDK in my opinion. Package with binary compilers and
flash utilities. "make flash" should just perform flash on specific board
without user knowing what tools is needed. "make debug" should start GDB
session.
A lot of beginners will be put off becuase of things like that. If they could
just do "./install-sdk.sh && ./init-nuttx && cd nuttx &&
./tools/configure.sh nucleo-whatever && make && make flash" and start playing
around - this would definiately help getting beginners.
Anegdotal (but still) proof. 10 years ago I was researching RTOSes. I really
wanted to use nuttx on stm32 back then. But I had a lot of problems just
compiling and running anything on discovery board. I was kinda put off, team
leader decided to screw it and go with another solution. I finally learnt it
at home and love it ever since, but damage was already done and nuttx in that
project was forgotten.
Sorry for long post, here's a potato: 🥔
--
.-.---.--.-.
| Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource |
| +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter |
| https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & |
| GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer |
`--^--^--^-'
signature.asc
Description: PGP signature
Re: How to improve/simplify NuttX initialization processes?
On 2024-07-09 10:06:53, Alan C. Assis wrote:
> How can we improve things?
>
> How can we simplify this?
I am just copy pasting my message from other thread, as I did not see
that one in time :) So my proposition is:
I think I would be good if nuttx had something like /sbin/init that would
do some very simple service management. Then you could just tick
"Start NSH after boot up". Programs would probably be had to added via
some compile-time header file that could look like that:
| struct program
| {
| const char *name;
| int priority;
| int stack_size;
| main_t entry_point;
| int pid;
| };
|
| struct program programs[] =
| {
| #ifdef CONFIG_EXAMPLES_NSH
| { "console", 50, 2048, nsh_consolemain },
| #endif
| #ifdef CONFIG_SOME_DAEMON
| { "some-custom-daemon", 50, 2048, daemon_function },
| #endif
| { NULL, 0, 0, NULL }
| };
And program in its simplest form would do:
| #include
| int main(int argc, char *argv[]) {
| for (int i = 0; programs[i].name != NULL; ++i) {
| struct program *p = &programs[i];
| printf("starting: %s\n", p->name);
| p->pid = task_create(p->name, p->priority, p->stack_size,
| p->entry_point, NULL);
| }
| for (;;) sleep(UINT_MAX);
| }
I think such init could also handle all initialization code (so not only
starting up daemons). It could be more clear than current board initialization
routines which are a little bit confusing (for me at least).
That would solve 2 problems. It would be very clear that NSH is not needed, and
user would have an easy way to start it's own daemons/applications.
--
.-----.---.--.-.
| Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource |
| +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter |
| https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & |
| GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer |
`--^--^--^-'
signature.asc
Description: PGP signature
Re: How to demystify some myths about NuttX
On 2024-07-09 17:20:26, Sebastien Lorquet wrote: > On 09/07/2024 17:06, michal.lyszc...@bofc.pl wrote: > > I think I would be good if nuttx had something like /sbin/init that would > > do some very simple service management. Then you could just tick > > "Start NSH after boot up". > > I think you can already do this by writing an init app and using that to > spawn a shell. > > Which is wasteful on small systems since you can start the shell directly > and save memory. > > Also, nsh can execute startup scripts, which are more flexible than your > suggestion. > > A few months ago, these scripts were linked to a rigid romfs automount > system which made the whole thing very cumbersome. > > But it's more flexible now, it was improved and the romfs can be customized. > > Sebastien Yes, I agree that nsh is more flexible. But the problem is that to run these scripts you need nsh. And whole discussion is to make nsh more optional. I suppose it could be enough to move init stuff from nsh to separate program. -- .-.---.--.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: How to improve/simplify NuttX initialization processes?
On 2024-07-09 09:21:32, Gregory Nutt wrote: > On 7/9/2024 9:10 AM, michal.lyszc...@bofc.pl wrote: > > I am just copy pasting my message from other thread, as I did not see > > that one in time :) So my proposition is: > > > > I think I would be good if nuttx had something like /sbin/init that would > > do some very simple service management. Then you could just tick > > "Start NSH after boot up". Programs would probably be had to added via > > some compile-time header file that could look like that: [snip] > > Starting any initialization task implies that you have already initialized > the operating system. This is fine for application level initialization but > OS level initialization must already be complete. > > The only complex thing about initialization are the chicken'n'egg problems. > For example, on DRAM-based platforms you can't execute any "normal" C code > until memory resources are initialized. Any initialization sequence must > account for the initialization and ordering requirements of all supported > platforms but must do so in a platform-independent way. > > Sweeping generalizations generally don't work for all initialization cases. I only meant to use init to replace boardctl initializations but I see your point. Well, my point still stands for most of it. Init should be a separate program that would start nsh (and other user daemons), not the other way around. -- .-.---.--.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: Improving NuttX Awareness
On 2024-07-09 20:12:49, Gábor Kiss-Vámosi wrote: > Hi, > > There are two more points that I'd add: > 1. Easy to get started: have example projects that can be set up by reading > a few lines from the README. Exactly. THE most important thing in project such as this is user friendly. Once the simple program is running, you can slowly built on that in incremental fashion. If you struggle to even run "Hello World!", user will just go. People want to PROGRAM (I know, shocker, right?:)) not fiddle with environment, toolchains and flashing tools. Why is stm32cube so popular even tough it's trash? Because you just click few things and programs do work. And then you can build on that. There must be a way for people (especially beginners) to setup environment with 0 knowledge about Linux. ./tools/configure.sh script should download and install whole toolchain and setup the environment. In kconfig there should be option to select "SDK Toolchain" that would use that internal toolchain, and it should be enabled by default. Buildroot can do that. Then "make flash" should know how to flash specific board and just do it without the need of user to know flash address. Just look at buildroot. You just clone it. make defconfig, call make, and you are done. You have nice working baseline on which you can work. Nuttx is just too much hassle to setup on fresh environment. Competition is strong. Nuttx is for strong power users. But that will only invite power users. Most important thing to understand is - that people want to program, and not play around with environment -- .-.-------.--.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: Please recommend NuttX
On 2024-07-11 06:19:55, Alan C. Assis wrote: > I wasn't expecting anything different from ARM: > > https://forums.mbed.com/t/important-update-on-mbed-end-of-life/23644/3 > > This is why I think RISC-V will win! That's right Alan, you tell them! And yeah, I agree with you. It would take him less time to edit his post than to reply to you. -- .-.---.------.-----. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: Using const in function arguments.
On 2024-07-11 23:36:22, Saurav Pal wrote: > Hi all, > > Suppose I have a pointer that I want to pass through function parameters. > In the function, neither is the pointer reassigned, nor is the thing it > points to modified in any form. > > So, I would assume its function argument signature to be like FAR const > struct my_struct * const ptr (The second "const" is my focus here). > Similarly for things like const uint8_t my_num, etc. as well. > > However, I have not really seen much use of specifying constants using > const (in the way I have mentioned above). Most of the examples I see are > of FAR const struct my_struct * ptr. I have heard the compiler can make > better optimizations for const, and because of this, I try to spam const > anywhere and everywhere I can. But I don't see too many such usages across > the codebase, so I was wondering why that is (or I just maybe reading the > code wrong, in which case, forgive me 🙏). Because it doesn't really make much sense to do so. *EVERYTHING* in C is passed as copy. Yes. Even pointers. Consider this | void foo(const void * const ptr); | ... | const void *mem = 0x123; | foo(mem); It means that you won't change the memory at address 0x123. It's clear. But second const actually only affects the function body itself. Even without "const ptr", you won't be able to change users "mem" variable. Even if you modify "ptr" inside "foo" you have only modified your local ptr variable - same way as if you declared variable in body. So it adds basically nothing. And ptr in fact IS NOT constant, it's just an integer (simplifying) on functions call stack. It belongs to you. Second const just bloats declaration and gives almost nothing in return. First const is very important, you know to expect function modifying (or not) what is rightfully yours. And those consts are promises anyway. Nothing stops me from modifying your const if I wanted to (well... maybe except for some hardware exception if data is really on RO medium ;)). And compiler can easily determine if something is const or not without the const keyword. | int foo = 6; | return foo * 4; Will be reduced to "24" anyway, even without "const int foo". -- .-.---.--.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: Help us to create a distributed board testing farm
Hi On 2024-07-18 16:14:20, Alan C. Assis wrote: > We are creating a testing farm for NuttX to be integrated on our CI. How is this going to work? Since, this seems like, tests will be conducted on real hardware, I assume I would have to install some daemon at my home so that CI could send commands to it to perform tests? This poses serious security risks. The only way I see it working is to have raspberry pi (or any other mini computer) in isolated network and vlan. What CI software are you going to use? I remember using Buildbot in the past, which may be good candidate, since I remember it being build just for cases like that. That is you host Master, and anyone that wants to participate in testing their arch/platform would set up a slave, which would connect to master and listen for build commands. Might be worth investigating it. I think it would be beneficial if anyone could just setup slave on his own, and then just connect to the master without any real authorization to participate in testing. I think there is a risk of such slave feeding false positives/negatives tho and someone who does not like nuttx could sabotage tests ;) -- .-.---.--.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: aarch64 boot crash when printing non-static string
On 2024-07-31 21:15:53, Matteo Golin wrote: > I cannot wrap my head around why I would be able to print a static string, > but not a non-static one. Both strings appear in the `.rodata` section of > the image when I inspect it with `objdump` as well. Even the assembly > `PRINT` macro in the arm64_head.S startup code declares the strings as > rodata. I'm not sure what the difference is here, but it's preventing me > from continuing to debug the boot process. I'm by no means very > experienced, so I feel a bit stuck with this issue. I thought I would check > if anyone here has encountered something similar. > > Any tips or pointers of what else I can check would be really appreciated! Can you maybe post stack trace from GDB after crash? Also check what address is dereferenced. Static will probably have different address than non static. aarch64 has some security and atf, maybe that is causing the problem? This is just a wild guess. Check failing instruction, dump info from it like addresses, and then do the same for working static data. Maybe this will shed some light onto this problem. It's good to know which instruction is failing and what arguments it takes. -- .-.---.--.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: ESP32 - How use SPI Slave
On 2024-08-28 15:48:10, Felipe Moura Oliveira wrote: > Hello All, > > Following Gustavo instructions I was able to see it working several commits > before master. > I will open a github issue, maybe more people can look it and help us to > solve. If you have working hash, then please do "git bisect" to pinpoint offending commit. "git bisect" will hold your hand throughout the whole process. It's easy and mostly automatic. Just needs some time to rebuild and reflash. -- .-.---.------.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: RP2350 port part 2
On 2024-08-29 11:17:06, Marco Casaroli wrote: > I have some more questions for you. I start a new email thread to not > generate noise in the previous discussion. > > 1. The RP port needs some hardware (include) files from pico-sdk. Should I: Nuttx does not include nor use any of the OEM SDK. This is double edge sword. It takes longer to implement driver, but those drivers are usually better fitted, better quality and less buggy than OEM drivers. If these are only register definitions than you may be able to get away with this (if license permits it and by doing some reformating). Including code is probably a no go. > 2. (if answer to Q1 is option a, then), should I reformat the imported code > to match NuttX or I can just drop the files there without any > modifications? (they are BSD-licensed) Usually reformat won't cut it as you need to follow Nuttx specifi API. Second thing is maintaning that code. OEM code tries to handle all possible cases, so there are a lot of code. And drivers usually need only a small subset of features that is required for it to work. Not going for corner cases make code so much smaller and easier to maintaing. If you reformat OEM code, someone has to maintain it - and just copying updated file from OEM will not work. > > 3. Should I aim to make this port work on rp2040 (and rename it to rp2xxx) > - the drivers are very similar, or should I keep it separated and target > rp23xx only? Code deduplication is always good thing. Problem is that it's a lot of work to kickstart it. Because of that there are tons of duplicated code - especially for stm32, stm32wl5 and stm32wb. They are mostly the same, but are still duplicated. > > 4. How should I test the peripherals? I don't have all the LCD displays and > the other accessories supported by RP2040 port. Should I: > > a. keep the peripherals code for LCD, etc and hope that it will work > (explain in the documentation that it is not tested) > b. just add the minimum code without those peripherals support > c. buy the missing stuff or find other people to test it before I open the > PR Best is C of course :) but noone will expect from you to buy stuff to write the drivers - you do it only if you want to support project using not only your time but also money. So go B. It's better to not have things than have them half cooked in buggy state (I'm looking at you zephyr). -- .-----.---.--.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: RP2350 port part 2
On 2024-08-29 11:57:49, Marco Casaroli wrote: > > > 4. How should I test the peripherals? I don't have all the LCD displays > > and > > > the other accessories supported by RP2040 port. Should I: > > > > > > a. keep the peripherals code for LCD, etc and hope that it will work > > > (explain in the documentation that it is not tested) > > > b. just add the minimum code without those peripherals support > > > c. buy the missing stuff or find other people to test it before I open > > the > > > PR > > Best is C of course :) but noone will expect from you to buy stuff to write > > the drivers - you do it only if you want to support project using not only > > your time but also money. So go B. It's better to not have things than have > > them half cooked in buggy state (I'm looking at you zephyr). > > > > I will remove the code for stuff I cannot test right now. Not sure if full removal is good approach here. You did put some work into it. It would be shame to waste it. I think I would just go on and create separate pull request for them. You can also semi test things with logic analyzer. SPI can be tested that way. With SPI you can also connect MOSI to MISO and test communication that way. Once you confirm driver with bridging or logic analyzer you can create driver marked as EXPERIMENTAL. This will be a good indication that driver is somewhat working, but noone should expect production quality code in there. -- .-.---.--.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: NuttX "gadget": resolve its host name via CDC/NCM connection
On 2024-10-08 20:56:00, Tim Hardisty wrote: > My intention is to implement a simple web server on the device so as to be > able to plug in to it via usb, go to a browser, and go to “http://gadget” > rather than “http://10.0.0.10” (for example). > > This is DNS…but my embedded networking knowledge is limited and I am not > sure what NuttX tools/daemons/examples/whatever I need to use for this? > > I don’t think a hosts file on the gadget is right, as the PC can’t use > that to match hostname to IP (and editing a hosts file on the PC is not an > option in this case). So probably the gadget needs to also be a DNS > server? But I can’t find much information on how to use the NuttX > implementation of this. > > Have I got that right or am I missing something? The thing you want to do, while possible is not really feasable. Yes, you must host DNS server on nuttx. I don't think there is anything ready to go, embedded devices usually do not act as a DNS. Then you would have to push DNS server to the host via DHCP. Problem is, that now you will overwrite DNS address on your host pc and you won't be able to resolve anything else other than what your nuttx 'gadget' device can. You could forward requests to external DNS, but that again requires nuttx to have internet. So DHCP/DNS on nuttx is not really good option. Having it reversed (DHCP/DNS on host pc) could probably solve the problem with some upnp magic. But that will require user to have upnp or some kind of zeroconf enabled on host pc as well. To my knowledge it's not possible to do what you want in portable manner. You can try some hacks, but the will not work for anyone - hence I would not recommend them. I have never ever met a embedded device that would do what you describe. It's always via IP address. So do what others do, and allow access via IP address only. That's the only portable way that I know of. -- .-----.---.--.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: Change time_t to signed type
On 2024-11-05 08:13:19, Simon Filgis wrote: > Seems like a dump question, but why time needs to be signed? It doesn't. But you may want to go backwards to show date before 1970. This is usually implemented by using negative time. -- .-.---.--.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: Questions about STM32 support/programming
On 2024-09-26 21:58:38, Matteo Golin wrote: > Hello all, > We figured we should check here first if anyone who had > experimented with STM32 chips knows offhand whether or not it's > possible to program over a USB interface, how to do it with the > NuttX build environment, or if it requires additional hardware. Hi, you should be able to flash and debug board via onboard stlink. All nucleos should have built-in stlink I think. So just connect nucleo via usb and check in lsusb if you have any stlink device. It should be visible like "STMicroelectronics STLINK-V3" I flash my boards with openocd: openocd -f interface/stlink.cfg -f target/stm32f3x.cfg -c 'program nuttx.bin 0x0800' You will need to change your target, there is target/stm32f7x.cfg and target/stm32h7x.cfg already in the openocd. I am not sure if start of flash is 0x0800 on f7 and h7, but I suppose it should be. This command will leave openocd opened with gdb server so you can start debugging it anytime you want with: arm-none-eabi-gdb nuttx "target remote 127.0.0.1:" -- .-.---.--.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: Questions about STM32 support/programming
On 2024-09-27 09:14:33, Nathan Hartman wrote: > I just had an idea that it would be neat to write a utility, which could > live under 'tools' (to be run on a developer machine) that would analyze > the current configuration and automatically generate the correct openocd > and gdb incantations. I haven't thought this through yet, so I don't know > if it's feasible and what might be involved, but I thought I'd mention it > here as food for thought. I don't like zephyr, but 'west flash' is a good thing they did. I proposed this in the past when there was a discussion about how to make nuttx more popular. You could create phony target 'make flash', which could propagate it to make.def in board directory. I think something like that is mandatory if nuttx should be more popular. To be more popular it must get more user friendly. Not everyone wants to fight with bootloader/flashing. They just want to realize their idea - and not learn build system and flashing tools. I also hate to say that - but if you are commited to cmake (ugh) it might be good idea to drop raw Makefile support. This just makes things more complicated for both maintaners and end user - nuttx is giving kinda useless choice for the end user here I think ;) > Off the top of my head I don't remember whether the STMF7 family has a ROM > bootloader. If it does, you probably need to pay attention to a BOOT pin on > the chip. Nothing wrong in having 2 bootloaders. On chip bootloaders are often very limited and are more suited for recovery than final product usage. Custom bootloader can be relatively easily configure to - for example - fetch image from tftp and boot it - awesome for development. -- .-----.---.--.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: milk-V DUO s
On 2024-09-18 12:41:13, Alan C. Assis wrote: > This aic8800 driver is GPL license, we cannot use it. > Probably they released it as GPL to be used on Linux kernel. In theory it can be used in nuttx. But including it (enabling for compilation) will basically upgrade whole license for every file to GPL. This is not really a concert for nuttx but for end developers using RTOS. If they enable this single library, they will have to ship source code for their WHOLE project with their product. Drivers like could simply tick "select GPL" in kconfig, and a notification could be printed before compilation that this is no GPL licensed code. I don't know how is Apache foundation feeling about things like that, but GPL does not care. It's not ideal. But it's not a closed door either. -- .-.---.------.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: Problems with STM32F7 and STM32H7 boards
On 2024-10-01 10:52:18, Roberto Bucher wrote:
> Thanks Michal
>
> changing the arm-gcc version can probably change the size of the generated
> code.
No, stack size is per thread, and has nothing to do with code size.
Stack size refers to automatic storage variables like
int main(void) {
int a;
char c[32];
}
This will take about 36 bytes of stack memory. Each nested function also uses
some stack space for arguments, return pointers etc.
I don't know how you generate your app, if it's automatic from kconfig+makefile
then stacksize is determined by STACKSIZE makefile variable, which is usually
set by some Kconfig setting with similar name.
--
.-.---.--.-----.
| Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource |
| +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter |
| https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & |
| GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer |
`--^--^--^-'
signature.asc
Description: PGP signature
Re: Problems with STM32F7 and STM32H7 boards
On 2024-10-01 09:38:56, Roberto Bucher wrote: > By launching "main" I have this error: > > nsh> main > ERROR: Failed to wdump_assert_info: Current Version: NuttX 12.6.0-RC1 > d4968905c5 Oct 1 2024 08:53:59 arm > dump_assert_info: Assertion failed panic: at file: :0 task: 0x8000361 > up_dump_register: R0: R1: 38005bf0 R2: 1810 R3: 1800 > up_dump_register: R4: 080002e9 R5: R6:  FP: > up_dump_register: R8: SB: SL: R11: > up_dump_register: IP: SP: 38006318 LR: 08002807 PC: 0800a692 > up_dump_register: xPSR: 2100 PRIMASK: CONTROL: > up_dump_register: EXC_RETURN: ffe9 > dump_stack: User Stack: > dump_stack:  base: 0x38005cc0 > dump_stack:  size: 2024 > dump_stack: sp: 0x38006318 > Any ideas? Is this "main" your own app? First thing I would check is stack size for that thread. Also enable stack colorization, stack canaries and stack usage statistics. Overflowing stack on embedded is number 1 in amount of errors I've seen during early development. Sharing your main code might also be helpful in debuging it. -- .---------.---.--.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: UART based peripheral driver
On 2024-09-30 12:51:06, Matteo Golin wrote:
> Hello,
> I did find a function called `stm32_get_uart()` which returns the UART
> device; this is more what I am looking for. It doesn't seem like most
> other platforms implement a similar function though, and I'm not sure if
> it is good design to require that an architecture first implement
> something similar before being able to use this driver. I don't want to
> introduce this pattern to NuttX without first checking for other
> suggestions.
Whatever Greg said, plus from me: your lora chip is mcu agnostic, so do
not use anything from the arch/ to implement the driver. There should be
absolutely zero arch related code in that driver.
This will allow driver to be used with any MCU that has serial interface.
Also design your rn2483_init() funtion driver to accept struct to initialized
serial driver. It's not your drivers responsibility to initialize serial
device, it should be provided to you by code in boards/ directory. So
in pseudocode it would look like this
stm32_init_rn2483() {
struct serial *serial;
/* get serial device specific to the board, one board will use USART1
* other might user USART2. Decision which uart to use depends on board
* hardware wiring and may be different even for the very same mcu */
serial = stm32_get_serial_for_lora();
/* initialize rn2483 lora driver and give it handle to the serial device,
* rn2483 driver can immediately use it from on to initialize the rn2483
* chip driver */
rn2483_init(serial);
}
--
.-.---.------.-.
| Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource |
| +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter |
| https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & |
| GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer |
`--^--^--^-'
signature.asc
Description: PGP signature
Re: Problems with STM32F7 and STM32H7 boards
On 2024-10-03 14:16:40, Roberto Bucher wrote: > _assert: Assertion failed panic: at file: armv7-m/arm_hardfault.c:175 task: > 0x80002b9 > > and this is related to the call of the function > > exit(1); > > in my code, for example if a device is not defined. The call to this exit(1) > function leads to this assertion error. > Basically, what I have to do is only to stop my (generated) application and > I think that it was ok in the past... > > Any idea how to solve this? I don't understand? What do you wanna solve? Hardfault? Well, then don't call exit() function? I mean, if program cannot continue just add proper log before doing call to exit() so next person does not have to think hard what is going on. Better yet - if it's possible to do, use static_assert()/COMPILE_TIME_ASSERT() to issue error during compilation time that something is not defined. -- .-.-------.--.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: Problems with STM32F7 and STM32H7 boards
On 2024-10-03 17:02:09, Roberto Bucher wrote: > I developed a python application called "pysimCoder" similar to XCos and > Simulink, which is able to generate control code for different targets > (Linux, Linux RT, Raspberry PI, NuttX and others). We have about 175 blocks > for the different targets already defined for inputs, outputs, functions, > sensors, actuators etc. > > The into 3 functions, called from a main: > > initialization, termination and interrupt service routine > > The last one is called by a temporized thread. > > If the initialization fails, the program must stop: till now (also in > NuttX), this is realized by simply call the "exit(1)" function in the > initialization procedure! Now (new?) in NuttX, when we call the "exit(1)" > function we get the "Assertion failed panic" message, and no more the stop > of the running control program, instead of return into the nsh application. > > Of course, it is possible to exit from the main thread Using return) after > controlling if the initialization function of a block is failed: but to > implement this we, have to change the code of all the 175 blocks... Ok I see. So you expected exit() to work same as on, say, Linux. So that app just exits back to the shell. According to function documentation is should work like that > The exit() function causes normal process termination and the > least significant byte of status (i.e., status & 0xFF) is > returned to the parent (see wait(2)). Don't know why it asserts, maybe you miss some config? Your best bet to fix it is to put breakpoint at your exit() function, and step through the code. Nuttx is exceptionally well documented in its C files, you will have no problems following it. -- .-.---.--.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: Change time_t to signed type
On 2024-11-06 10:01:55, Nathan Hartman wrote: > I am +1 for a Kconfig. > > * or just make the default 64-bit on ALL systems, and if you are > trimming resources, you can make a judgment call whether to reduce it > to 32-bit I would say this. I believe defaults should be what works for majority of cases. Things to work is more important for things to be quick. People of different experience and knowledge uses this RTOS. A lot of people won't even notice performance hit from 64bit time, but they will surely notice weird time bugs. Having code we know is going to crap out in the near future is kinda strange design choice. I think you could have ignored it when there was 50 years left, but this will happen in 14 years which is not that far for embedded systems that can work for decades. -- .-.---.--.-----. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: Explanation request about a the merging of an unacceptable pull request
On 2025-02-03 22:45:29, Xiang Xiao wrote: > The ai bot is a soft suggestion, not a rule from Lup introduces it > initially. > Many PR already contain the useful information, like these: > https://github.com/apache/nuttx/pull/15749 > https://github.com/apache/nuttx/pull/15728 > But ai bot still complain the information isn't enough. > Even https://github.com/apache/nuttx/pull/15437 already contains the enough > information to explain why this change is made. Yep, especially this section of PR perfectly explains steps performed to not break anything: > Testing > > Update this section with details on how did you verify the change, > what Host was used for build (OS, CPU, compiler, ..), what Target was > used for verification (arch, board:config, ..), etc. Providing build > and runtime logs from before and after change is highly appreciated. That PR touched WHOLE cpu family, and yet not a single test was performed on real hardware it seems. -- .-.---.------.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: app/os sync creates many problems
On 2025-01-31 13:48:32, Tomek CEDRO wrote: > On Fri, Jan 31, 2025 at 1:41 PM Sebastien Lorquet > wrote: > > Of course I also tried with the commit before that one, and it didnt > > work either. > > Sebastien, did you try the release packages? Does the problem occur in > the release packages? > > Upstream master is for development purposes, things may get broken for > a while, I would never put my product on a master branch. This is offloading responsibility to end user. Sebastian is right here. Either apps are separated properly so that even 1 year old apps repo will work with current HEAD of rtos, or nuttx should have sync mechanism like submodules (don't go there) or tool like Zephyr's west to sync it (or it can also be done with make/cmake). Did you ever try to bisect problem in nuttx? Constant failures in apps and you have to manually guess which commit is going to at least compile - and then you still cannot be 100% sure soft does/doesn't work as indended. -- .-.---.--.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: app/os sync creates many problems
On 2025-01-31 16:20:51, Tomek CEDRO wrote: > On Fri, Jan 31, 2025 at 3:35 PM wrote: > > On 2025-01-31 13:48:32, Tomek CEDRO wrote: > > > On Fri, Jan 31, 2025 at 1:41 PM Sebastien Lorquet > > > wrote: > > > > Of course I also tried with the commit before that one, and it didnt > > > > work either. > > > > > > Sebastien, did you try the release packages? Does the problem occur in > > > the release packages? > > > > > > Upstream master is for development purposes, things may get broken for > > > a while, I would never put my product on a master branch. > > This is offloading responsibility to end user. Sebastian is right here. > > Either apps are separated properly so that even 1 year old apps repo will > > work > > with current HEAD of rtos, or nuttx should have sync mechanism like > > submodules > > (don't go there) or tool like Zephyr's west to sync it (or it can also be > > done with make/cmake). > > > > Did you ever try to bisect problem in nuttx? Constant failures in apps and > > you > > have to manually guess which commit is going to at least compile - and then > > you > > still cannot be 100% sure soft does/doesn't work as indended. > > Hmm, I get it. I saw that too. I thought it should be always in sync. > > I saw changes in either nuttx or nuttx-apps that depends on each > other. Not sure if that would allow apps to build / work on one year > old rtos code. > > So what are your solution propositions? There are 2 long term solution I see. 1) lower effort one - keep commit hash of apps in some file. Either check hash before doing `make all` or add new makefile command like `make appsync`. Either way, file .app-hash should always contain working app commit hash. app hash can also be hold as a Kconfig field. This will probably be enough - especially for bisecting. 2) Rewrite build system for apps. Use only absolute minimum and very stable API in rtos/apps. Really, apps should not have the need to know much about RTOS, few header files should be enough. When you build app for Linux you don't ingegrate with kernel source in any way - just use some header files provided by os/libc. Maybe there is 3) option I didn't thing about. > Usually OS has something called API and apps must adhere to that API. > If breaking change is introduced API number is bumped and so apps > needs an update. API/ABI to OS should not break apps, like ever. You can look up what Torvalds thinks about that. Internal API change is fine. But try to introduce ABI change for Apps, and be a part of immortalized in the internet as person Linus killed with words ;) > We should discuss and vote this kind of design decision and put inside > CONTRIBUTING and documentation f anything changes. > > Also I welcome everyone to help in PR review if changes are impacting > you, catch them first before merge :-) I'd love to, but can't get any company to choose Nuttx over Zephyr ^^ And privately I am currently doing projects that don't really involve RTOS at all. So I am kinda out of the loop these days. -- .-.---.--.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: app/os sync creates many problems
On 2025-01-31 17:34:48, raiden00pl wrote: > 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. Same way as app/kernel compatibility is maintained in othes Unices like Linux or BSD. > It would be possible if we assumed that the API in NuttX is perfect > and will not require changes, which is not true. There are many custom > solutions in NuttX that require improvements and these improvements > will break compatibility. There are many custom interfaces that need > improvement, such as PWM or sensors, and these changes will > definitely break apps. No, just be super careful designing API to "userspace" and once commited it stays. Forever. Bad APIs will remain. Posix does not remove bad APIs as well. That's why we still have "creat" instead of "create". Or we have 3 poll APIs in Linux (select/poll/epoll). You really want to change API, you build another one, and mark old one as deprecated, but you don't delete it. That would be ok if Nuttx was <1.0.0, version, but it's >=1.0.0 so it should care about API/ABI. Especially that it does not have to come up with API and just use what Posix been using for decades now. > On the other hand, any standardized interface like POSIX must be stable, > which is obvious. But POSIX doesn't define everything, especially when > it comes to embedded systems. So you carefully define it, keep it as EXPERIMENTAL for some time, which allows for breaking changes, but once API is marked as stable - it is set in stone. Period. -- .-.---.--.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: NuttX Code Quality Improvement 2025Q1
On 2025-02-06 18:48:18, Tomek CEDRO wrote: > On Thu, Feb 6, 2025 at 4:51 PM wrote: > > On 2025-02-06 08:43:34, Michal Lenc wrote: > > > > Also it will be nice to have monthly online meetings just to talk > > > > things over and stay connected and synchronized. It should bring > > > > community closer together :-) > > > > > > Yes! We have to find a proper channel for this though. I think there > > > were efforts to have meetings on our Discord channel, but many people > > > don't like the platform (for understandable reasons) so it didn't last > > > for long. > > Well, there is always IRC. And folks from libera.chat is very friendly. > > It's a goto server for basically all projects that want to have an IRC > > channel now. > > Yes I still use IRC sometimes.. but its better to see each other live > talks and make jokes :-) > > What is wrong with Discord? I thought this is kind of modern IRC with > audio and videocalls.. it has chat with rooms just like IRC :-) One word answer: electron. And mandatory link because IRC was mentioned: https://xkcd.com/1254/ -- .-.---.--.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: NuttX Code Quality Improvement 2025Q1
On 2025-02-06 19:47:28, michal.lyszc...@bofc.pl wrote: > On 2025-02-06 18:48:18, Tomek CEDRO wrote: > > On Thu, Feb 6, 2025 at 4:51 PM wrote: > > > On 2025-02-06 08:43:34, Michal Lenc wrote: > > > > > Also it will be nice to have monthly online meetings just to talk > > > > > things over and stay connected and synchronized. It should bring > > > > > community closer together :-) > > > > > > > > Yes! We have to find a proper channel for this though. I think there > > > > were efforts to have meetings on our Discord channel, but many people > > > > don't like the platform (for understandable reasons) so it didn't last > > > > for long. > > > Well, there is always IRC. And folks from libera.chat is very friendly. > > > It's a goto server for basically all projects that want to have an IRC > > > channel now. > > > > Yes I still use IRC sometimes.. but its better to see each other live > > talks and make jokes :-) > > > > What is wrong with Discord? I thought this is kind of modern IRC with > > audio and videocalls.. it has chat with rooms just like IRC :-) > One word answer: electron. > > And mandatory link because IRC was mentioned: https://xkcd.com/1254/ I made a mistake, it was supposed to be this one :P https://xkcd.com/1782/ -- .-.---.--.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: [DRUNX] Distributed Runtime and bUild for NuttX
On 2025-02-06 16:02:18, Matteo Golin wrote: > I've got: > - Raspberry Pi Pico > - Raspberry Pi Pico W > - XIAO RP2040 > - XIAO SAMD21 > - Raspberry Pi 4B > > And would also be willing to help test, provided it's easy enough for me to > automate. Just looked into my lost and forgotten drawer. As of today I have: - nucleo wl55jc1 - nucleo f091rc - nucleo f303re - nucleo f429zi - stm32h735g - stm32butterfly2 (stm32f107) - mimxrt1050-evkb - mimxrt1060-evkb - mimxrt1062(teensy 4.2) - rpi pico - samc21 xplained Most of them have on board debugger. If not I also have few swd/jtag debuggers that I am not really using anymore. If you make this project so I can just put rasbian + your script to init.d I can donate these, rpi4, some USB hub and some space in my lab for testing. Scripts must not be running as root. I could also create some DMZ for boards with networking capability to test those as well. -- .-.---.------.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: NuttX Code Quality Improvement 2025Q1
On 2025-02-06 08:43:34, Michal Lenc wrote: > > Also it will be nice to have monthly online meetings just to talk > > things over and stay connected and synchronized. It should bring > > community closer together :-) > > Yes! We have to find a proper channel for this though. I think there > were efforts to have meetings on our Discord channel, but many people > don't like the platform (for understandable reasons) so it didn't last > for long. Well, there is always IRC. And folks from libera.chat is very friendly. It's a goto server for basically all projects that want to have an IRC channel now. -- .-.---.------.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: app/os sync creates many problems
On 2025-01-31 21:14:23, raiden00pl wrote: > > No, just be super careful designing API to "userspace" and once commited > it > stays. Forever. Bad APIs will remain. Posix does not remove bad APIs as > well. > That's why we still have "creat" instead of "create". Or we have 3 poll > APIs in > Linux (select/poll/epoll). You really want to change API, you build another > one, > and mark old one as deprecated, but you don't delete it. That would be ok if > Nuttx was <1.0.0, version, but it's >=1.0.0 so it should care about API/ABI. > Especially that it does not have to come up with API and just use what Posix > been using for decades now. > > I can't agree with this. Stockpiling legacy code degrades code quality, the > code > is harder to maintain and is harder to use by users. > I think there are cases where it's justified to break compatibility. > Especially if > the breaking changes for the users are easy to fix and detect, and the > interface > that is being modified has obvious flaws. And of course, everything should > be well documented. That is not excuse. Maintaining old API is not hard. Usually it's just a simple call to new API, which will not require further maintenence. You can even kick it to separate file so it does not break code aesthetics ;) Inside nuttx repo you can break all the APIs you want. But outside of it this should not happen. NuttX it not crazy small project used by handful of people anymore. By publishing API now, you are making a contract with other developers. Break too many of such contracts and you have situation like with Sebastian. At least he was kind enough to share his thoughts with you so you can act. Probably many more people just quietly quit. Take expamles from other projects. I can update my openbsd with 0 issues. And if some breaking changes in configs are introduced you always get great documentation what has changed and how to prepare for that change. Creating something new is always fun and is easy. But you have to maintain it later thru the updates. There is a reason why I am not getting even close to ruby. I'd rather use clunky PHP which has some problems on its own, but it never broke my software/installation with updates, while with ruby based apps there was always struggle. Change just for the sake of change never worked out well for anyone. -- .-.---.--.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: Request for being member
On 2024-12-12 09:09:43, Kriti. D wrote: > Hello, > I am new to Nuttx and wanted to learn about it more. This email was found > in response to my trying to join the Nuttx community. Is this the right > place to subscribe? > > if it is i would like to request to join the community. Thank you so much You don't really "join" an open source community. You just start contributing to it. Be that code, documentation, helping others via this mailing list or simply testing code. After some time you get recognition, more respect, people are starting to depend on you. Then you may get some more responsibility (if you wish) like accepting pull requests. So just go, write code, fix bugs, improve documentation in any way (be that even a typo) and have fun while doing so ;) That's all there is to it really. Also there is no right or wrong amount of contribution. Any contribution is appreciated. -- .-.---.------.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: Kconfig: select vs depends on
On 2024-12-17 13:27:48, Tomek CEDRO wrote: > Hello world :-) > > Recent PR #2893 [1] proposed using "select" statement for "PIPES" as > dependency of "LIBUV" option. There is a preference to use "depends > on" in that case [2]. What are your preferences and experiences in > this area? Is there a policy / preference in this area for NuttX? :-) > > What are dangers of using "select"? Why "depends on" is preferred? Select gonna fail for "nested dependencies". CONFIG_A depends on CONFIG_B which depends on CONFIG_C If you select A, A will select B, but it will not select C automatically, A will have to have both "select B" and "select C". This can lead to bugs I - personally - prefer depends for visible (user selectable) entries. While select can be used to select invisible entries like | config CHIP_X | bool "select chip X" | select HAVE_UART | select HAVE_SPI If you don't want for user to miss on some features I also include reversed config like: | comment "psmq requires SYSTEM_EMBEDLOG and !DISABLE_MQUEUE" | depends on DISABLE_MQUEUE || !SYSTEM_EMBEDLOG | | menuconfig SYSTEM_PSMQ | bool "psmq" | default n | depends on !DISABLE_MQUEUE && SYSTEM_EMBEDLOG In this case if you have enabled mqueue and embedlog you will see selectable | [ ] psmq otherwise you will see comment | --- psmq requires SYSTEM_EMBEDLOG and !DISABLE_MQUEUE --- This has number of perks: - user see all potential features he can choose from, regardless of what is currently selected - end user will immediatelly and explicitly see what gets pulled for a config - no chance to break with nested dependencies - if embedlog suddenly starts to require new option, only embedlog kconfig will have to be modified (with new depends on option) - no illegal configurations are possible with depends (while it is possible with select) So, rule of thumb - use select only for non-visible (non-selectable anywhere) symbols - use depends everywhere else. -- .-.---.--.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: trust in nuttx gone
On 2025-01-29 12:12:58, 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 road map > for > the project is the biggest problem here. TBH we don't even know where > the project is headed. Probably if this large number of commits were > supported > by some kind of roadmap so that it would be known what the goal of these > changes is - it would make more sense. > > In the long run, without coordinated collaboration between teams working > separately on NuttX and without a commonly accepted roadmap, I think the > project > may fail spectacularly. > > This is where the advantage of BDFL projects comes in. One person has > authority over the project and manages it according to his/her vision. > Managing a project in a distributed manner is a difficult task, > and so far we are not succeeding at it. I think NuttX hasn't correctly > transitioned from being managed by Greg (BDFL model) to being managed by > distributed management yet. And this is the biggest problem here. 100% agree. Greg had good vision. Small and simple Posix RTOS. Things started to bloat uncontrollably after Apache had taken over. No wonder that Sebasian has problems with build system, when Nuttx has now 2 build system - for zero gain. Makefiles were working, they were also simple. Now we have 2 build systems, and CMake to this day does not support all apps. CMake should have been a replacement - not addition. Roadmap should also contain scope of project. Do you want to add support for rust/zig/python? Where is SDK? It's really hard for newbies to kickstart simplest hello world. Now it feel like mainters merge everything to not "discourage" people, or they merge what they personally like. With roadmap and scope there would be not issue with that. Someone pushes Rust thing? Roadmap says no - auto decline. Again - less is more. It's better to have less fature but well polished than have tons of half baked fatures that require hacks. Don't take Sebastian's message as personal attack. Yeah, he went ballistic there. But it's probablly because of years of frustrating moments. This should be treated as a waking call when such long-standing member decides to leave because project makes his life harder instead of easier. -- .-.---.--.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: trust in nuttx gone
On 2025-01-28 11:23:26, Sebastien Lorquet wrote: > my trust in nuttx is now hard to maintain. > > Every day a DELUGE of commits (from xiaomi, this is a fact) is added to the > repository. > > I am struggling to understand what happens in this project. > > so many fixes are pushed, how is that even possible? this is a quicksand > project! Project gets more popular. This is both good and bad. More commits/fixes are good, but it also increases chances of something bad slipping thru. Especially that Nuttx does not have that many core developers that can really sit and review the code. And reviews take tons of time and requires lot of knowledge. > > > Also, how are such commits (not from xiaomi!) allowed? No description except > "uf2" ? Where is the adult in charge? > > https://github.com/apache/nuttx/commit/dac3f315a11cead82a5f630d4ae1c3eb45a80377 Commit is awful, true. But then again, you cherry picked commit that supports your thesis. > I am announcing that after that many years my company has started to develop > a minimal rtos to replace our usage of nuttx, because it is just not stable > enough to be usable for stable long term projects. > > There are too many changes, we are loosing money every time we need an > update. there is no way to maintain the use of a nuttx custom board and > project over several years. What changes are you talking about? Nuttx is Posix, so no "userspace" app should get broken by any change - if it does, then there a problem in Nuttx that should be reported and fixed. Merge conflicts in kernel? Push your improvements to mainline, problem will solve itself for the most part. > Having control of our code will be a better investment. That will obviously > be closed source. Which is, after all, a better way of control on our > products. Good luck with that. Every custom RTOS I worked with was an attrocious. FreeRTOS + Vendor HAL is not good pair. You will be in world of pain. I'd rather use Zephyr than making own semi baked RTOS. Let's not even start on topic when you are going to change MCU vendor (like stm to microchip). Seriously buddy, if not Nuttx, then save yourself some pain and go with Zephyr. > No amount of my involvement in the github triage is going to help, the case > is desperate. I just have no time, no energy, no motivation, no spoons left > to deal with this. it's a deluge of commits, let it be, but without me. > > the warning from the apache foundation that you use too many ci credits > should have been a warning to slow down and reflect on the project > direction. nothing has happened except making it even faster. > > I will also discourage people to use this project, I cannot in good > conscience recommend it to anyone, it would be a trap. Being salty hepls noone. Point out what bothers you. If commits are constantly messing up with your projects it's either your problem or Nuttx problem. These things should be reported so they can be acted upon. Either Nuttx will be fixed or you will be told how to properly maintain your code within Nuttx. It's true that Nuttx does no quite know where it wants to go and be right now. Introducing CMake without removing Makefiles where very bad decision - as you have to maintain two build systems now - which takes time from other more important things. Introducing Zig and Rust feels also like a fashion move. Rust feels like it's being shoved down everyone's throat. And Nuttx has more cleaning up to do before adding even more gimmicky stuff. It really does feel like Nuttx wants to do much more then it was intended to do. Also there is simply not enough manpower to maintain so many things. Less is more, more is less. -- .-.---.--.-. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
Re: Problem with running nuttx on imxrt1020
On 2025-02-17 08:48:28, Simin Feng (CW) wrote: > dump_assert_info: Assertion failed panic: at file: :0 task: Idle_Task > process: Kernel 0x600031dd Seems like you need to enable debug as there is file and line missing from log. Enable debug symbols and more debug prints, also canaries for stack monitoring and try to rerun - maybe some more useful information will be revealed. -- .-.---.--.-----. | Michal Lyszczek | Embedded C, Linux | Company Address| .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^--^-' signature.asc Description: PGP signature
