Re: Builtin app with its own command processor on stdin

[spudaneco]

My guess would be stack corruption.  Crashes and hangs often don't happen until 
the app exits,  I would try increasing the app stack size.Sent from my Galaxy
 Original message From: Jernej Turnsek 
 Date: 1/24/24  1:12 AM  (GMT-06:00) To: 
dev@nuttx.apache.org Subject: Re: Builtin app with its own command processor on 
stdin Hi Alan,I have meant my app is processing its own commands as long as the 
quitcommand is entered or CTRL-C is pressed.BR,JernejOn Tue, Jan 23, 2024 at 
9:15 PM Alan C. Assis  wrote:> Hi Jernej,> by not returning 
to NSH do you mean after pressing Ctrl+C ?>> Maybe this tutorial will help:> 
https://www.youtube.com/watch?v=hszt15lTsnA>> BR,>> Alan>> On Tue, Jan 23, 2024 
at 4:56 PM Jernej Turnsek > wrote:>> > I am running 
an app in the foreground. I didn't have waitpid enabled.> Now I> > have and it 
works as it should.> > BTW, my app is not exiting to nsh. Thanks.> >> > On Tue, 
Jan 23, 2024 at 7:38 PM Gregory Nutt > wrote:> >> > > Are 
you running app in foreground or background from NSH, i.e.,> > >> > > nsh> app> 
> > nsh> app &> > >> > > The second should show this kind of interleaved 
behavior.  In the> first,> > > nsh should block until the app exits.> > >> > > 
Do you have waitpid() enabled?  The first behavior depends on the> > > 
availability of waitpid()> > >> > > Does you app exit and return to nsh after 
each command?> > >> > > On 1/23/2024 11:19 AM, Jernej Turnsek wrote:> > > > 
Hi,> > > > I would like to develop my own builtin application to process some> 
> custom> > > > commands. This app is started from nsh over the serial console. 
I> have> > > > duplicated the code from ftpc example and when application is 
started> > it> > > > start to process stdin for commands. But this 
functionality is mixed> > with> > > > nsh own processing of commands, thus when 
I hit Enter, I get app>> line,> > > > when hit Enter again I get nsh> command 
line. Entering commands like> > > > "help", I get hl on nsh and ep on my app 
command processor. I am> > confused> > > > here. I did not test ftpc example, 
but I presume it is not working> > > either.> > > > Both apps are using 
readline_stream API for getting the commands.> > > >> > > > Regards,> > > > 
Jernej> > > >> > >> > >> >>

Re:Re: debugging user app crashes

[spudaneco]

You should be able to set breakpoints properly, but only after the correct MMU 
mapping is in place.
 Original message From: yfliu2008  
Date: 1/9/24  8:06 PM  (GMT-06:00) To: dev  Subject: 
Re:Re: debugging user app crashes Yes, in kernel mode each user space program 
has similar but isolated virtual address spaces. So it seems that we can't set 
break points to them like FLAT or PROTECTED build.Not sure if we need some sort 
of debug agent in KERNEL build so that it can help debugging user space 
tasks. When use of kernel build araises, this need will increase I 
guess.Regards,yf   Original     
   From:"Alan C. Assis"< acas...@gmail.com ;Date:2024/1/10 
9:47To:"dev"< dev@nuttx.apache.org ;Subject:Re: debugging user app 
crashesYes! For kernel mode each program has its own main() implementation, 
notthe definition.BR,AlanOn Tue, Jan 9, 2024 at 10:34 PM Gregory Nutt  
wrote: On 1/9/2024 7:28 PM, Alan C. Assis wrote:  Hi Yf, 
 Just look at your System.map and you will see that all those main() 
became  _main.   It isn't possible to have a unique 
main() symbol, otherwise we will have a  duplicated symbol, also 
even if the compiler accepted that, how could NuttX  know you want 
to call the main from Hello instead of the main from Alarm?   
BR,   Alan This is not true in the kernel build mode.  All 
applications run at exactly the same virtual address and the entry point is 
main() for all of them.  In the kernel build, all applications are loadable 
modules. None of the symbols in the loadable modules will appear in 
System.map since each application module is separately compiled and linked.

Re: C++ Support

[spudaneco]

UCLibc++ is very old.  Most people use libxx from LLVMSent from my Galaxy
 Original message From: Mark Stevens  
Date: 6/25/23  1:50 AM  (GMT-06:00) To: dev@nuttx.apache.org Subject: Re: C++ 
Support So a little more progress on this one.Turning on C++ Exception support 
for the PicoW:nsh build configuration generates errors:CC:  
pthread/pthread_testcancel.c machine/arm/gnu_unwind_find_exidx.c:32:8: error: 
unknown type name '__EIT_entry'   32 | static __EIT_entry *__exidx_start_elf;   
   |    ^~~Configuration is:- C++ enabled- uCLib++ library- GNU low 
level support- Exceptions enabled.Turning exceptions off gives me missing 
symbols, guess that is going to be a missing library in the link 
phase.Regards,Mark_Blog: 
blog.thepcsite.co.ukTwitter: @nevynuk> On 24 Jun 2023, at 18:59, Mark Stevens 
 wrote:> > I’m currently working on a home project with 
NuttX and my preferred language is really C++ for what I am doing.  I can work 
in C if necessary but I’d like to use some C++ features.> > So far I have 
managed to get the framework of what is needed configured and the next step is 
to start some application implementation.  So I’m thinking core logic unit 
tested using the simulator and basic C++ application on the laptop.> > So I 
have started a fairly basic test scenario and hit a problem with the C++ 
support in NuttX.> > My application is going to be using some of the STL, at 
the moment I’m hitting issues with string and vector, two fairly basic and 
simple classes.  I’m not getting any application to compile successfully.  I 
have tried:> > - Basic C++ support> - LLVM with both the LLVM and GNU low level 
libraries> - uCLib++ with both LLVM and GNU libraries> > I have tried this with 
both the sim:nsh and the raspberrypi-pico-w:nsh configurations.> > The classes 
I am using are fairly basic so I could implement them myself, I would prefer to 
use a library version though.> > Has anyone managed to use the C++ libraries 
with NuttX ?> > Regards,> Mark> _> Blog: 
blog.thepcsite.co.uk> Twitter: @nevynuk> > > > > 

Re: sched_lock() should be completely removed

[spudaneco]

Thanks.  I remember this now.  We talked about this back in 2019!GregSent from 
my Galaxy
 Original message From: Xiang Xiao  
Date: 4/23/23  10:09 PM  (GMT-06:00) To: dev@nuttx.apache.org Subject: Re: 
sched_lock() should be completely removed On Sun, Apr 23, 2023 at 10:42 PM 
Gregory Nutt  wrote:>> > Let's focus on the first two 
item:> >> > 1. Add sched_lock()'s ability to the enter_critical_section()>> 
Some will need to explain what this means.  What is this?If someone wakes up a 
high priority thread inside the critical section(notprocess interrupt), the 
high priority thread will run immediately. Thesuggestion is disabling the 
schedule preempt too until the caller waitssomething proactively or leaves the 
critical section.>   Why is it> needed?  There is not sufficient information in 
this statement to> understand it.>Here is an example which replace sched lock 
with the critical section tofix a SMP 
bug:https://github.com/apache/nuttx/pull/3597/files#diff-2319a97549d1e962ba4aa93ef2de6fafe077a454637afb3b5d1d5a6c9ba65ab2R212-R221But,
 since the critical section isn't a superset of the schedule lock, itfails to 
achieve the requirement highlighted in the comment: /* Make sure that 
pre-emption is disabled to that we signal all of the   * members of the group 
before any of them actually run. (This does   * nothing if were were called 
from an interrupt handler).   */Since many people don't understand this special 
behaviour, we found severaltiming(very hard to reproduce) issues related to 
this behaviour in themainline before, that's why Jun made this proposal.

Re: [Breaking change] Move nxmutex to sched

[spudaneco]

Perhaps you could use accessor functions to read/write 8, 16 32, 64 bit values. 
 Each scalar value will be properly aligned and, hence, will lie within a 
page.Sent from my Galaxy
 Original message From: Ville Juven  
Date: 4/18/23  3:48 AM  (GMT-06:00) To: dev@nuttx.apache.org Subject: Re: 
[Breaking change] Move nxmutex to sched Hi,Sorry for the spamfest. Forget what 
I said about the alignment being asolution. It is not. Any object allocated 
from heap that contains a sem_tstructure cannot guarantee that the alignment of 
sem_t is correct.So I was just being dumb..Br,Ville JuvenOn Tue, Apr 18, 2023 
at 11:39 AM Jukka Laitinen wrote:> Hi,>> I like the 
alignment idea, thanks for bringing it up!>> I think forcing the alignment for 
the semaphore, and accessing it> directly via page pool from the kernel is the 
simplest and most trivial> thing. It implements what also Greg suggested + 
fixes the issue of> semaphore being on the page boundary.>> Since the 
semaphores in CONFIG_BUILD_KERNEL just don't work at all> currently, the best 
option for now, IMHO, is to implement this solution> and always align the 
semaphores as suggested in (and only in)> CONFIG_BUILD_KERNEL case. This just 
makes the semaphores work with> minimal code changes.>> I still wouldn't bury 
the idea of splitting the semaphore into user and> kernel parts entirely. To me 
it would make perfect sense to cleanly> separate things which belong to kernel 
from the things that belong to> user space. That solution just needs to 
maintain the real time> properties, as discussed before, and not break existing 
functionality or> increase memory consumption.>> Current semaphore solution, 
even with the page-pool access, still has> the problem that user side code has 
got access to structures belonging> to the kernel (lists which kernel loops 
through while scheduling &> managing priority inheritance). So a user side 
process corrupting it's> own semaphore structure can at least crash or jam the 
kernel.>> But, first things first, the solution which Ville suggested below 
would> fix the most burning issue for us for now.>> Thanks,>> Jukka>>> On 
18.4.2023 10.26, Sebastien Lorquet wrote:> > Hi all,> >> > As Tomek said, 
whatever you choose to do, please make sure everything> > of this is absolutely 
kept optional, at least during the merge and> > community validation phase.> >> 
> I dont think connecting these proposals to CONFIG_BUILD_KERNEL is> > granular 
enough.> >> > Thanks,> >> > Sebastien> >> > Le 18/04/2023 à 09:18, Ville Juven 
a écrit :> >> Hi all,> >>> >> Sorry, this is going a bit off topic.> >>> >> One 
wild solution specifically to solve my/our problem> >> (CONFIG_BUILD_KERNEL) 
might be to force a "next power-of-two> >> alignment" for> >> the semaphore. 
This would ensure that the semaphore ALWAYS fits within a> >> single page and 
remove the need for cross page checks / mappings in this> >> specific case.> 
>>> >> Although I will still implement a more generic map function (it's 
almost> >> done anyway), in the case of semaphores this would simply mean that 
no> >> semaphore will ever need to be explicitly mapped into kernel memory,> >> 
fetching the page pool mapping will be enough.> >>> >> For our case the size of 
sem_t is 32 or 40 bytes (depending on> >> configuration), this would be aligned 
to 32 ot 64-bytes which ensures> >> that> >> the entire structure fits in a 
single page. The alignment requirement> >> can> >> also be flagged behind 
CONFIG_BUILD_KERNEL, as such a requirement is not> >> necessary for the flat 
addressing modes.> >>> >> What do you think? Too wild, or something worth 
considering /> >> acceptable ?> >>> >> Br,> >> Ville Juven / pussuw on github> 
>>> >> On Mon, Apr 17, 2023 at 8:58 PM Tomek CEDRO  wrote:> 
>>> >>> if it possible to add new functionality as optional feature?>  >>> 
--> >>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info> 

RE: [Breaking change] Echo character by serial driver

[spudaneco]

How do you plan to handle incoming vt100 escape sequences.  I see you kludged 
around one, but there are hundreds.  TheY are used in BAS, pdcurses and other 
apps extensively.You are ruinking that critical vt100 capability and breaking a 
lot of thingsSent from my Galaxy
 Original message From: Qi3 Huang 黄齐 
 Date: 3/10/23  3:43 AM  (GMT-06:00) To: 
dev@nuttx.apache.org Subject: [Breaking change] Echo character by serial driver 
Hello everyone:    I had submit a PR in last week 
https://github.com/apache/nuttx/pull/8691, this change makes NuttX align with 
other posix compatible system like linux. This improved experience like telnet 
and WAMR's repl, but also introduced some issues:    1. Don't echo again in 
application layer since it's done by driver now, refer to 
https://github.com/apache/nuttx-apps/pull/1608    If any other issues found, 
please inform me, thanks!BR,Huang 
Qi#/**本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
 This e-mail and its attachments contain confidential information from XIAOMI, 
which is intended only for the person or entity whose address is listed above. 
Any use of the information contained herein in any way (including, but not 
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is prohibited. If you receive this 
e-mail in error, please notify the sender by phone or email immediately and 
delete it!**/#

Re: NuttX Hardware

[spudaneco]

I have 90-95% of those boards.Sent from my Galaxy
 Original message From: Brennan Ashton 
 Date: 3/8/23  7:29 PM  (GMT-06:00) To: 
dev@nuttx.apache.org Subject: Re: NuttX Hardware This is the sheet (a little 
old now) that I had shared 
out:https://docs.google.com/spreadsheets/d/1qMQV_CSN5Ka13_wr73QNo2Uh-NiSumjcwINuc0BkyIsMy
 goal had been to functional test as much as I could for that release,and I did 
find a bunch of little things to fix that I think made for abetter release in 
the end.--BrennanOn Wed, Mar 8, 2023, 4:53 PM Alan C. Assis  
wrote:> Agreed! Let's keep it in a separated thread.>> Sometime ago I was 
talking with Brennan about listing the board that I> have here and he surprised 
me showing this board listing spreadsheet> on google docs. Maybe we can 
organize a listing to see who has board> X, Y, or Z and to make it possible to 
test NuttX on all possible> boards.>> I have a special interested to find the 
launchxl-tms57004 because it> supports big-endian and I think there nobody 
testing NuttX on> big-endian (except maybe Zou/fft, he is using NuttX on Sparc 
arch that> is big-endian). So Greg, if you have this board I'm interest to get> 
it.>> Few days ago I found (and bought) on eBay from Australia the first> board 
that I tested NuttX in 2010:> 
https://acassis.wordpress.com/2010/08/01/getting-started-to-nuttx/>> It could 
be an interesting test also to see how big NuttX became 13 years> later.>> 
BR,>> Alan>> On 3/8/23, Sebastien Lorquet  wrote:> > This 
needs to be in its own thread.> >> > Your collection of boards probably got 
some historical value.> >> > Sebastien> >> > On 3/8/23 23:31, Gregory Nutt 
wrote:> >> Slightly different topic:  I have almost every board that ever ran> 
>> NuttX from about 2005 through 2020 or so.  That is probably several> >> 
hundred boards.  I don't use them any more and am thinking about just> >> 
dumping them to make space. Is there anyone willing to pay the> >> shipping 
from Costa Rica on a massive dump of older but interesting> >> hardware?> >>

Re: Byte to int32/big and little endian

[spudaneco]

 > I can find no references in the NuttX code base to changing 
endian-ness?Search for CONFIG_ENDIAN_BIG

Re: New names of repositories

[spudaneco]

As i said, i am not advocating breaking up repositories.  It would help 
modulartiy, but is not worth the price.Submodules refer to versioned code so 
changes to the submodule have no impact to the built code until until the 
version referenced by the submodule is updated.  I think that would alleviate 
most of the concerns that you expressed.However, submodules have their own 
issues I wouldn't ever attempt that again either.  They are a maintenance 
nightmare.Sent from my Galaxy
 Original message From: Nathan Hartman 
 Date: 11/19/22  8:52 PM  (GMT-06:00) To: 
dev@nuttx.apache.org Subject: Re: New names of repositories On Sat, Nov 19, 
2022 at 10:26 AM Gregory Nutt  wrote:> On 11/19/2022 9:02 
AM, Tomek CEDRO wrote:> > On Sat, Nov 19, 2022 at 3:53 PM Thiago Costa de Paiva 
wrote:> >>  From these, the valid argument is that it would be non-standard 
(not a> top level name) related to Appache rules, which I think is indeed not> 
acceptable. It would not imply any source code organization change nor> 
submodules:> >>> >> git clone /nuttx/core nuttx> >> git clone 
/nuttx/apps apps> > The use of submodules was also considered 
before (I also proposed> > that) and turned out to be a bad idea :-) :-)>> At 
one time, I was moving all major NuttX  components into sub-modules> in order 
to better modularize the system.  I had arch/ and> Documentation/ moved into 
their own repositories.>> But I got endless complaints from users.  Everyone 
hated this so I ended> up merging these back into nuttx/.  That was a tough job 
because of the> duplicated history in the nuttx/, arch/, and Documentation/> 
repositories.  I really wouldn't recommend going through that again.I strongly 
recommend AGAINST splitting the NuttX repo into multiple repos.There are many 
reasons for this but here is a big one: You'll lose atomicchangesets, which is 
a very important part of version control. One of thebiggest problems with CVS, 
which all modern version control systems aredesigned to avoid, is that changes 
that touched multiple files were notatomic; each file had its own version 
number, so you needed an out-of-bandway to keep track of which changes made up 
a given changeset. Compare how asingle git commit hash number re-creates an 
exact replica of the entiretree as it looked when that changeset was committed. 
Splitting up the repois a step in the wrong direction.That said, nuttx and 
nuttx-apps *should* remain separate for the followingreason: because the apps 
are, by their nature, separate and optional. It isimportant that users will 
always be able to supply their own appsrepository, while our apps repository 
can be seen as demonstration,testing, a baseline against which to build a 
custom apps, an example of howto build a custom apps, and even as documentation 
in the form of sourcecode of how to write programs that run on NuttX. But 
whatever happens,nuttx-apps should remain separate from nuttx.CheersNathan

RE: NuttX International Workshop 2022: will start in less than 14h

[spudaneco]

Hi, Alan,Question... Are there instruction anywhere for connecting to the 
presentations?GregSent from my Galaxy
 Original message From: "Alan C. Assis"  
Date: 9/23/22  3:07 PM  (GMT-06:00) To: dev  Subject: 
NuttX International Workshop 2022: will start in less than 14h Hi Everyone,We 
are looking forward to see you tomorrow in the NuttX Workshop.The schedule with 
all the presentations is already available:https://nuttx.events/BR,Alan

Re: NuttX Monthly Meetup

[spudaneco]

This is not "helping users",  These are all project management topics.  These 
kinds of discussions are not appropriate outside of ASF provided communication 
mechanism.  You cannot create your own private project management team that 
excludes everyone else.Sent from my Galaxy
 Original message From: Alin Jerpelea  
Date: 9/25/21  1:11 AM  (GMT-06:00) To: dev@nuttx.apache.org Subject: Re: NuttX 
Monthly Meetup MOM jitsi meet 24.09.2021License updatesAlin asked for contact 
ideas forHaltian and Omni Hooverboardswaiting for Adam Dunkels to answerhave an 
progress update regarding the license statusAlin is planing to create the next 
releasewe will start the release process for NuttX 10.2 with mixed licensesAim 
to release NuttX 11.0 with Apache licensesTodo:ping Bernan to create the 
release notes for NuttX 10.2New features/suggestionstoochain base on Clang. we 
should try to suport itimprove build time on non linux systemsexplore AI - 
tensorflow, NNabla interationexplore MicroROS integrationquestionaire to 
understand what OS are people usingwindows native / windows cygwin / linux / 
MacTopic for the next meetingCmake - should we switch or not?October 22 next 
online MeetingOn Thu, Sep 23, 2021 at 5:35 AM Alin Jerpelea 
 wrote:> It is a an open meet and the plan is to discuss 
any topics (open issues,> plans, wishes)>> I will talk about license issues and 
next NuttX release>> On Wed, Sep 22, 2021, 21:41 Tim Hardisty 
 wrote:>>> What sort of agenda, or purpose, Alan? 
Sounds like a good idea but some suggestion of what to expect would be>> good 
:) On 22/09/2021, 18:20, "Alan Carvalho de Assis" 
>> wrote: Dear NuttXers, We want to do 
monthly meets with our developers and users. The first online meet will 
be this Friday (2021/09/24) at 18:00 GMT. Everybody can join using this 
link: https://meet.jit.si/NuttXMeetup BR, Alan>>

RE: where is the variable __KERNEL__

[spudaneco]

tools/Config.mkSent from my Galaxy

Re: avoiding pitfal of reuse of globals in FLAT mode?

[spudaneco]

One option is to replace the globals with accessor functions and use TLS to 
hold the actua. data.Sent from my Galaxy
 Original message From: "Matias N."  Date: 
3/23/21  7:18 PM  (GMT-06:00) To: dev@nuttx.apache.org Subject: Re: avoiding 
pitfal of reuse of globals in FLAT mode? On Tue, Mar 23, 2021, at 22:09, Nathan 
Hartman wrote:> On Tue, Mar 23, 2021 at 8:39 PM Matias N. mailto:matias%40imap.cc>> wrote:> > > Hi,> > while using getopt() from a task 
started from NSH I realized subsequent> > calls reused the global optind and 
similar variables resulting in different> > results each time. I'm aware this 
is expected in FLAT mode and is related> > to the issue of static C++ 
constructors (they would only be called once,> > not every time the task is 
started).> >> > What I wonder is what could we do to avoid this common 
pitfall:> > - document it somewhere (a common issues/troubleshooting section in 
the> > docs would be good to have anyways) and just accept the issue> > - 
religiously initialize globals myself before being used (a pain, error> > 
prone, and a bit adhoc, working only for FLAT mode)> > > When using globals, 
best practice is to make it really clear that the> variables are global. Many 
programmers do this by prefixing global variable> names with g_*.> > I take a 
different approach: A long time ago, I started grouping all> globals in a 
struct, which has one global instance called Global. It makes> it easy to find 
all globals, and furthermore at the start of the program as> a matter of policy 
the first thing I do is memset() the Global struct to 0.> Yes, I know that is 
often redundant to the startup code, but in some> situations the startup code 
doesn't initialize globals. The FLAT model is> one example of this (from the 
2nd invocation onwards). I've seen other> examples of this over the years. By 
memset()ing your globals at the start> of main() you can rest assured that the 
globals are in fact zeroed,> regardless of whatever else happened before 
main(). It has another side> benefit: with globals grouped this way, it becomes 
trivial to take a> standalone program and turn it into a component of a larger 
program.> tl;dr, this> approach has worked great for me for a long time.That 
sounds like a good approach.> > Caveat: It won't help if your program (or any 
API called by it) uses> globals that are outside your control, and therefore, 
not initialized by> you. :-/Yes, my concern is about functions such as 
getopt(). If you just follow thedescription of the API and use it as normal you 
reach this pitfall. I was lookingfor some approach to avoid this as much as 
possible. For getopt() I see there'seven no standard getopt_r(), so we would 
have to provide our own, which may notbe a bad idea.Still, this issue will 
probably present in many other places.> > Nathan> Best,Matias

Re: Problem with SmartFS access

[spudaneco]

Brute force testing is not a solution unless the testing is very complete and 
extensive.  Testing is not required for the case of m9dified default 
configuration settings.  A simple inspection of the Kconf files will detect the 
problem in all cases,Sent from my Galaxy
 Original message From: Alan Carvalho de Assis 
 Date: 3/21/21  11:03 AM  (GMT-06:00) To: 
dev@nuttx.apache.org Subject: Re: Problem with SmartFS access Hi Greg and 
Anthony,On 3/21/21, Gregory Nutt  wrote:>>> ... what we 
can>> do to prevent these types of "side-effects" when people are touching 
the>> config system.>> The use of defconfig files implies that we never change 
default values> of configuration.  If someone does change the default value of 
a> configuration setting, then it effects ALL configurations that depend on> 
that default.  We need to catch this is the review step.   During> review, if 
we notice that there is a change to the default value of the> configuration 
setting, then we must insist that all defconfig files be> modified so that the 
previous configuration is not changed due to the> side-effect.>> CI cannot 
catch this.  As noted, the error does not occur until run> time.  A proper 
regression test would catch this but we do not do any> automated regression 
testing.  That is a major hole in the testing.>Yes, the CI cannot catch it, but 
using some QA Unit Tests running inthe Linux simulator or QEMU we could catch 
it. Abdelatif tested thesmartfs example in the "sim" board and the issue also 
happened.Of course it cannot catch all the issues, but at least most of 
theissues could be avoided using some basic tests.BR,Alan

RE: strdup & free in protected build

[spudaneco]

You could use lib_free()Sent from my Galaxy

Re: Problem with USB CDC initialization on board based on STM32F4DISCO

[spudaneco]

This probably explains why you get no USB log.  How could you?  It is 
configured to go to the console (i.e., /dev/console) but there is no console 
device.Sent from my Galaxy
 Original message From: Flavio Castro Alves Filho 
 Date: 1/17/21  3:50 PM  (GMT-06:00) To: 
dev@nuttx.apache.org Subject: Re: Problem with USB CDC initialization on board 
based on STM32F4DISCO Em dom, 17 de jan de 2021 13:52, Gregory Nutt 
escreveu:> I don't think that this combination will 
work:>> CONFIG_CDCACM_CONSOLE=y> CONFIG_CONSOLE_SYSLOG=y>> I think that the 
syslog console device would have to be available at> bootup. Normally a RAM log 
is is used to hold syslog data if a USB> console is used.>In my case, I am 
following the implementation from discovery board, wheresyslog is pointing to 
the uart and console on the USB.I will review if it was done correctly.Thank 
you for your remark.Best regardsFlavio> I might be wrong about that and this 
should not prevent the USB device> connecting.>> On 1/17/2021 9:10 AM, Flavio 
Castro Alves Filho wrote:> > Thank you very much for your fast response.> >> > 
I checked the boot calls and they are the same, regarding USB> initialization.> 
>> > I compared the include/nuttx/config.h files too ... at least regarding> > 
USB, I couldn't see anything critical.> >> > The development approach that I am 
working was exactly starting with> > stm32discovery board and increasing 
features. Maybe I have to restart,> > checking first the USB.> >> > Best 
regards,> >> > Flavio> >> > Em dom., 17 de jan. de 2021 às 11:39, Grr 
 escreveu:> >> What you can do is compare .config generated 
from that defconfig to> .config> >> generated from "./tools/configure.sh -l 
stm32f4discovery:usbnsh" and see> >> the differences. You can also compare 
include/nuttx/config.h from both> >> configs> >>> >> Another approach is to 
start from discovery config and do the> modifications> >> for your board. After 
you have it working, clone the config to a> different> >> board name. With 
"make savedefconfig" you can save your working> defconfig> >>> >> El dom, 17 
ene 2021 a las 7:51, Flavio Castro Alves Filho (<> >> flavio.al...@gmail.com>) 
escribió:> >>> >>> As an additional information, if I load the STM32F4DISCO on 
my board,> USB> >>> works.>  >>> Em dom., 17 de jan. de 2021 às 10:43, 
Flavio Castro Alves Filho> >>>  escreveu:>  Hello,> 
>  I am working to port NuttX on a board based on STM32F4DISCOVERY. 
The>  microcontroller is the STM32F407VET6.> >  USB CDC support is 
not initializing.> >  When I plug the USB on the board, I have the 
following dmesg response> in> >>> Linux:>  [517062.075048] usb usb1-port2: 
attempt power cycle>  [517062.726922] usb 1-2: new full-speed USB device 
number 47 using> >>> xhci_hcd>  [517062.727170] usb 1-2: Device not 
responding to setup address.>  [517062.935148] usb 1-2: Device not 
responding to setup address.>  [517063.142906] usb 1-2: device not 
accepting address 47, error -71>  [517063.270916] usb 1-2: new full-speed 
USB device number 48 using> >>> xhci_hcd>  [517063.271141] usb 1-2: Device 
not responding to setup address.>  [517063.479134] usb 1-2: Device not 
responding to setup address.> >  When I run stm32f4discovery:usbnsh on 
my discovery board, it works.> >  I compared the defconfig from the 
base project and from mine and I>  believe I have initialized everything 
that is related to the USB.> >  Here is the defconfig for my board:> 
>  #>  # This file is autogenerated: PLEASE DO NOT EDIT IT.>  
#>  # You can use "make menuconfig" to make any modifications to the>  
installed .config file.>  # You can then do "make savedefconfig" to 
generate a new defconfig>  file that includes your>  # modifications.> 
 #>  # CONFIG_ARCH_FPU is not set>  # CONFIG_MMCSD_MMCSUPPORT is 
not set>  # CONFIG_MMCSD_SPI is not set>  # CONFIG_NSH_ARGCAT is not 
set>  # CONFIG_NSH_CMDOPT_HEXDUMP is not set>  # CONFIG_NSH_CMDPARMS is 
not set>  CONFIG_ADC=y>  CONFIG_ANALOG=y>  CONFIG_ARCH="arm">  
CONFIG_ARCH_BOARD="phi-innovations">  
CONFIG_ARCH_BOARD_STM32F4_PHI_IOT_GATEWAY=y>  CONFIG_ARCH_CHIP="stm32"> 
 CONFIG_ARCH_CHIP_STM32=y>  CONFIG_ARCH_CHIP_STM32F407VG=y>  
CONFIG_ARCH_STACKDUMP=y>  CONFIG_ARMV7M_MEMCPY=y>  
CONFIG_BOARDCTL_RESET=y>  CONFIG_BOARDCTL_UNIQUEID=y>  
CONFIG_BOARDCTL_USBDEVCTRL=y>  CONFIG_BOARD_LOOPSPERMSEC=16717>  
CONFIG_BUILTIN=y>  CONFIG_CDCACM=y>  CONFIG_CDCACM_CONSOLE=y>  
CONFIG_CDCACM_RXBUFSIZE=256>  CONFIG_CDCACM_TXBUFSIZE=256>  
CONFIG_CLOCK_MONOTONIC=y>  CONFIG_CONSOLE_SYSLOG=y>  
CONFIG_DEBUG_ASSERTIONS=y>  CONFIG_DEBUG_DMA=y>  
CONFIG_DEBUG_DMA_ERROR=y>  CONFIG_DEBUG_DMA_INFO=y>  
CONFIG_DEBUG_DMA_WARN=y>  CONFIG_DEBUG_ERROR=y>  
CONFIG_DEBUG_FEATURES=y>  

Re: Error in sninfo with argument

[spudaneco]

You really need to analyze the hard fault to have any understanding.  My guess 
would be something unrelated like a stack overrun.Sent from my Galaxy
 Original message From: Alan Carvalho de Assis 
 Date: 1/7/21  6:15 AM  (GMT-06:00) To: 
dev@nuttx.apache.org, thiha_...@yahoo.com Subject: Re: Error in sninfo with 
argument Hi Thiha,Well, if this is a configuration issue, then it is better to 
use apre-defined board configuration, in this case you can look 
at:boards/arm/stm32/stm32f103-minimum/configs/rfid-rc522I never saw this type 
of crash on "syslog" before.Also save the current .config that is crashing, 
later you will able tocompare it with the working config to understand why it 
was crashing.Maybe the crash it not related to "syslog", but it is in some 
linejust below the syslog() line.BR,AlanOn 1/7/21, Thiha Kyaw 
 wrote:> Dear Nuttx,>> I did a bit more debugging in 
NuttX-10.0.1 on STM32F4Discovery.>> I add a below line in stm32_bringup.c to 
make sure that syslog function> with argument.>> syslog(LOG_INFO, "INFO: 
stm32_mfrc522initialize() : %d \n", 10);>> Error is as follow.>> NuttShell 
(NSH) NuttX-10.0.1> nsh> ABCDF> INFO: stm32_mfrc522initialize() : 
arm_hardfault: PANIC!!! Hard fault: ABCDF>> I believe I need to set some 
settings in menuconfig. Please guide me how to> solve the syslog issue.>> 
syslog is important to do the debugging.>> Thanks.>> Regards,> Thiha Kyaw> 
On Sat, Jan 2, 2021 at 11:52 PM Thiha Kyaw  wrote:>>> Dear 
Alan, I use NuttShell (NSH) NuttX-10.0.0. Board is STM32F4Discovery 
(STM32F407G-DISC1). Regards,>> Thiha Kyaw On Sat, Jan 2, 2021 at 11:15 
PM Alan Carvalho de Assis>> >> wrote:> Hi Thiha,>> 
Thank you for reporting this issue.>> Could you please supply more 
information?>> What NuttX version are you using? Is it from mainline? If 
so, did you>>> get this same issue using NuttX 10.0 or 9.1 ?>> BR,>> 
Alan>> On 1/2/21, Thiha Kyaw  wrote:>>> > Dear 
Nuttx,>>>  > I am facing the problem in sensor debugging.>>>  > Simple 
debug print using sninfo is working well.>>>  > But sninfo with argument 
throws *arm_hardfault: PANIC!!!*>>>  > For example,>>> > 
sninfo("ADXL372_FIFO_CTL = 0x%02x\n", reg_content);>>>  > Is there any 
missing configuration?>>>  > [image: image.png]>>>  > Please guide 
me.>>>  > Thanks.>>> > -->>> > Yours Sincerely,>>> > Thiha Kyaw>>> 
>> -->> Yours Sincerely,>> Thiha Kyaw> --> Yours Sincerely,> Thiha 
Kyaw>

Re: interrupt priorities on nRF52

[spudaneco]

There is a Confluence page describing how to implement nested interrupts if you 
want them (see also the TizenRT implementation)Sent from Samsung tablet.
 Original message From: David Sidrane  
Date: 10/25/20  4:35 PM  (GMT-06:00) To: dev@nuttx.apache.org Subject: Re: 
interrupt priorities on nRF52 Nuttx does not support nested iteruups. In fact 
if you enableprioritization, you will get random crashes due to the reentrace 
to thecommon isr.On Sun, Oct 25, 2020, 1:52 PM Matias N.  
wrote:> Hi,> while working on nRF52 BLE link-layer I experienced some problems 
due to> delayed ISRs. This can be quite problematic> for handling all the tight 
timings required by the standard. I eventually> reached an implementation that 
can deal with this relatively well (BLE> standard gives some leeway for some 
small number of dropped packets and> also retransmits missing ones). However, 
as other peripherals start> generating more interrupts, this could actually 
become a problem. Also, I> think it would be good to know BLE ISRs will always 
have priority.>> I've been looking into how ISRs can be prioritized but I don't 
have much> experience with this, so I have some questions:> * Does nRF52 need 
explicit support for handling interrupts with different> priorities or is the 
support supposed to be taken care of at the ARM level> code?> * How well 
supported is this in nRF52/ARM?> * Do interrupt priorities imply nested 
interrupts? It isn't clear to me if> priorities only mean which ISR will get 
served first when they are pending> together or if it also implies that a low 
priority interrupt can be> interrupted to handle a higher priority one (I 
believe the latter is what> is usually refered to as "nested interrupts")> * 
How does enter_critical_section() deal with priorities? How do I know> which 
priority is masked and which one isn't?> * Which configs should I enable to try 
this?>> Thanks,> Matias

RE: 68k?

[spudaneco]

Mike Smith was working on this years ago.  But it never came  upstream.Sent 
from Samsung tablet.

RE: Can we implement ctype functions through table?

[spudaneco]

I would consider option 3 to be the worst choice.  That could bloat can be 
enormous and unacceptable as I have seen in the past.  I saw growth by many 
kbyte in such cases. Not a good compromise.Sent from Samsung tablet.
 Original message From: Xiang Xiao  
Date: 7/29/20  12:54 AM  (GMT-06:00) To: dev@nuttx.apache.org Subject: RE: Can 
we implement ctype functions through table? The new option just make the 
situation worse. The same code works insome configurations, but breaks in other 
configurations.Since the standard confirmation is the most important principle 
forNuttX, we have three options:1.Implement ctype function with table and add 
256 byte to ROM2.Change macro to normal function and lose some 
performance3.Change macro to inline function and some old compilers may 
generatethe bloat codeall ctype functions are one line code, so option 3 may be 
a good compromise.> -Original Message-> From: David Sidrane 
> Sent: Tuesday, July 28, 2020 8:23 PM> To: 
dev@nuttx.apache.org> Subject: RE: Can we implement ctype functions through 
table?>> Xiang,>> If there is a small usage do you think flash will grow by 256 
bytes? I> would be surprised.>> Should you uses a config option?>> David>>> 
-Original Message-> From: Xiang Xiao 
[mailto:xiaoxiang781...@gmail.com]> Sent: Monday, July 27, 2020 10:40 PM> To: 
dev@nuttx.apache.org> Subject: RE: Can we implement ctype functions through 
table?>> Decorate the table with IPTR and access the element through 
up_romgetc,> just like printf series function.>> > -Original Message-> 
> From: Gregory Nutt > > Sent: Tuesday, July 28, 2020 
12:44 PM> > To: dev@nuttx.apache.org> > Subject: 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.> >> >> > On 7/27/2020 9:55 PM, Xiang 
Xiao wrote:> > > Hi all,> > > For example, here is isspace implementation:> > > 
#  define isspace(c) \> > >  ((c) == ' '  || (c) == '\t' || (c) == '\n' || 
(c) == '\r' || \> > >   (c) == '\f' || (c) == '\v')> > > The argument of c 
will evaluate 6 times, which make the following> > > code suddenly fail:> > > 
while (end != begin)> > >    {> > >  If (!isspace(*--end))> > >    {> > 
>   break;> > >    }> > >    }> > > But it work well with other 
libc implementation, because all other> > > libc utilize a table to classify  
the char type:> > > 
https://github.com/bminor/newlib/blob/master/newlib/libc/include/cty> > > pe> > 
> .h#L97> > > https://github.com/bminor/glibc/blob/master/ctype/ctype.h#L197> > 
> and the argument only need evaluate once.> > > So my question is: can we 
implement ctype functions through table to> > > improve the compatibility?> > > 
Yes, the table need take more 256 bytes ROM space, but the complex> > > 
expression used in NuttX also bloat the code size, especially> > > considering 
ctype function is used very frequently.> > >> > > Thanks> > > Xiang> > >

Re: Markdown READMEs?

[spudaneco]

Versioning is important but I think that the most important reason to keep the 
docs in the repositories is because we have a visible, manageable process to 
update critical documents via PRs.  For example,changes to the coding standard 
need careful review and approval.Sent from Samsung tablet.
null

RE: driver question about memory and calloc

[spudaneco]

I don't know anything about the DMA, but you should not call calloc() from 
within the OS.  That does not work in all configurations.Instead  include 
nuttx/kmalloc,h and call kmm_malloc().  If you want aligned memory, call 
kmm_memalgn().Sent from Samsung tablet.
 Original message From: Adam Feuer  Date: 
7/7/20  9:40 PM  (GMT-06:00) To: dev@nuttx.apache.org Subject: driver question 
about memory and calloc Hi,I am getting the SAMA5D27 SDMMC SD Card driver pull 
request ready. There'sone small issue I'm working on, though. There's a place 
in the driverinitialization where I calloc() some memory– 466 bytes. DMA data 
transferswhile reading from files times out if I don't have the calloc() in 
there.With the memory allocated, everything works fine. Nothing writes to 
thisblock of memory– I memset it and examined it before, during, and 
aftertransfers using GDB. It's just an unused block of memory.I'm trying to 
find out if other amounts of memory work– smaller than about100 bytes doesn't 
work, and I know it works reliably at 466 bytes. I'lltrack the exact number 
down tomorrow.But my question is, why does this work? The driver 
datasheetsdon'tmention
 that the chip needs aligned memory for its buffers, and the Atmeland U-Boot 
drivers don't use aligned memory. And since nothing isoverwriting the memory, 
what is the calloc() doing to prevent the SDMMC DMAengine from completing the 
transfer?If anyone has seen behavior like this, I'd love to know it. I'd like 
totake this otherwise useless code out, or at least know why I need it.Link to 
the specific line of code in 
sam_sdmmc.ccheersadam--
 Adam Feuer 

Re: ftw/fts

[spudaneco]

The core of these functions should be the same as the logic in apps/insulin in 
cmd_ls() that handles the 'lsd _R' command.Sent from Samsung tablet.
 Original message From: Alan Carvalho de Assis 
 Date: 6/23/20  5:22 AM  (GMT-06:00) To: 
dev@nuttx.apache.org Subject: Re: ftw/fts Hi Yamamoto-san,I didn't find an 
implementation for NuttX, but it should be nice tohave it because it is part of 
POSIX standard.BR,AlanOn 6/23/20, Takashi Yamamoto 
 wrote:> hi,>> does anyone know ftw/nftw, fts, 
or similar libraries for nuttx?> 
https://pubs.opengroup.org/onlinepubs/9699919799/functions/nftw.html> 
https://netbsd.gw.com/cgi-bin/man-cgi?fts++NetBSD-current>

RE: nrf51822 and BLE

[spudaneco]

Why not use the BLE provided by NuttX?Sent from Samsung tablet.
 Original message From: "Matias N."  Date: 
6/16/20  6:42 PM  (GMT-06:00) To: dev@nuttx.apache.org Subject: nrf51822 and 
BLE Hi,I'm picking up a project based on a NRF51822 module and I'm currently 
trying out Zephyr due to the available BLE support. However, I'm having some 
issues with it and, while I guess it is a matter of learning more about Zephyr 
to solve them, I was wondering about what is the state now for NuttX and 
support for BLE on NRF5. I revisited old NuttX e-mail threads and at the time 
it was mentioned that Alan asked Nordic about the BLE stack which is on Zephyr 
to be released as BSD to be included in NuttX [1] (to which there was no 
response). From my understanding this code is part of Zephyr which is licensed 
under Apache 2.0. Since NuttX is also licensed the same way, maybe now there's 
a better chance of integrating support for this?I really don't know much about 
Bluetooth Classic/BLE internals but in case someone with more knowledge is able 
to work on that part I think i could try to get basic support for NRF51822 into 
NuttX. In any case, I see there's already NRF52x support so that is not really 
an issue. But at least I could help test it.What do you think? Would this be 
possible now? Was it just the licensing issue or were there other technical 
impediments? Or maybe now there's still a licensing issue (I hope 
not).Best,Matias[1] 
https://groups.google.com/d/msg/nuttx/pmIJEOLWfHA/a4HWcxMEAwAJ

RE: [EXT] Re: NuttX Wiki Porting Guide SocketCAN addition

[spudaneco]

That document is in the repository at 
incubator-nuttx/Documents/NuttxPrtingGuide.html.  You change via PR.  After the 
PR checks complete, the massaged document will be available as build artifacts 
and can be placed in Confluence.Sent from Samsung tablet.
 Original message From: Peter Van Der Perk 
 Date: 6/16/20  12:40 AM  (GMT-06:00) To: 
dev@nuttx.apache.org Subject: RE: [EXT] Re: NuttX Wiki Porting Guide SocketCAN 
addition I've now got an approved account however it seems that the NuttX 
porting guide page is a read-only html page. Can this page be converted to 
Confluence/Wiki markup or is there a way for me to access this html file?Yours 
sincerely,Peter van der perkpeter.vanderp...@nxp.com -Original 
Message-From: Brennan Ashton  Sent: 15 June, 
2020 20:15To: dev@nuttx.apache.orgSubject: [EXT] Re: NuttX Wiki Porting Guide 
SocketCAN additionCaution: EXT EmailOn Mon, Jun 15, 2020 at 10:40 AM Peter Van 
Der Perk  wrote:>> Thanks to the feedback of Gregory 
Nutt and Alan Carvalho de Assis today we finally merged the SocketCAN code into 
NuttX. I've already made a porting guide in the past 
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpetervanderperk.nl%2Fnuttx_socketcan_porting_guide.pdfdata=02%7C01%7Cpeter.vanderperk%40nxp.com%7C900955770b694ac507e908d81158122d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637278417237452545sdata=mxeyU2FjpP91XeHrd4JIBv4iidok%2B31aCfPZOLvn%2BO0%3Dreserved=0
 what's the procedure to get this documentation into the NuttX wiki Porting 
guide?Peter,Thanks for all the work getting this feature in.  As for the 
porting guide/wiki if you can send me your apache ID from registering on the 
wiki, I will happily approve your account for write access to the wiki.  The 
extra step is just to keep the spam under 
control.https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Flogin.action%3Fos_destination%3D%252Fdisplay%252FNUTTX%252FNuttxdata=02%7C01%7Cpeter.vanderperk%40nxp.com%7C900955770b694ac507e908d81158122d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637278417237452545sdata=scc9iY%2B7MwXR1fzsMjmMkCXQvU41WWyV9zQsze0vdbY%3Dreserved=0--Brennan

Hold off merging PRs

[spudaneco]

I see a few new PRs coming in.  I want to remind everyone that tomorrow we plan 
the branch for release/9.1.  If committers could hold off merging until that 
branch is in place, the I think we have a chance for a good release 
candidate!Thanks! Then, after the branch , if any merges cause issues, we will 
have another two months to find and fix them.GregSent from Samsung tablet.

Re: NuttX config browser

[spudaneco]

The configuration document he is referring to is not in the repository.  I used 
to create it only for releases using a custom tool at 
tools/mkconfigvars.shMaciej's tool is much easier to use.Maciej has several 
other cool NuttX tools.  In a meritocracy, I think contributing these to the 
project would score pretty high (hint, hint, hint)Sent from Samsung tablet.
 Original message From: Brennan Ashton 
 Date: 5/31/20  11:04 AM  (GMT-06:00) To: 
dev@nuttx.apache.org Subject: Re: NuttX config browser On Sun, May 31, 2020, 
9:17 AM Maciej Wójcik  wrote:> That document is old, from 
NuttX 8.2 and needs to be updated.>>> Yes, now I remember that there was some 
page with configuration options. I> think it serves the purpose. It could be 
auto generated using CI, then it> wouldn't be outdated. Still I thought it 
could be a bit more interactive>It is built via CI on every build, but only 
hosts the latest releaseversion not master.Maybe there is a regeneration step 
that's actually missing... I will needto look at that, right now we just issue 
the inlining in the docs build.--Brennan>

Re: MSYS2 build slow

[spudaneco]

Build performance has not been a priority for us yet.  Johannes' 30 minute 
build rocked us into some stopgap action.  If and when it becomes a priority 
there is probably more we can do in the future.Sent from Samsung tablet.
 Original message From: Nathan Hartman 
 Date: 5/31/20  10:46 AM  (GMT-06:00) To: 
dev@nuttx.apache.org Subject: Re: MSYS2 build slow On Sun, May 31, 2020 at 
12:44 PM Gregory Nutt  wrote:>> > FWIW the build has 
become noticeably faster for me with latest master:> > 1m21s now. Before, the 
build consistently took about 1m50s. So that's> > 30 seconds saved. I build on 
Linux.> yes I have seen improvements of 25-30% on all platforms, and more on> 
some Window's platforms that are more sensitive to forking shells. That> should 
make a really bit difference if you are building several hundred> 
configurations.>That's fantastic! I'm sure everyone will appreciate faster 
builds!Nathan

Re: kconfig (Re: mbedtls)

[spudaneco]

Don't forget, you are not a user anymore.  You are a maintainer and you are 
responsible for keeping a stable environment for all users.Sent from Samsung 
tablet.
 Original message From: Takashi Yamamoto 
 Date: 5/25/20  6:41 PM  (GMT-06:00) To: 
dev@nuttx.apache.org Subject: Re: kconfig (Re: mbedtls) On Tue, May 26, 2020 at 
12:48 AM Gregory Nutt  wrote:>> We should all be using a 
consistent, common version of> kconfig-frontends.  A snapshot was taken and has 
never disappeared from> internet contrary to other statements it is always been 
here and will> always be here: https://bitbucket.org/nuttx/tools/src/master/>> 
We do not accept any  Python-based tools in the critical build path.> There are 
some secondary Python scripts under tools/ but we cannot> permit the 
introduction of any new user tool requirements in the basic> build.  That is 
simply off-limits.>> Think of the NuttX user first! Technologies and tools are 
much further> down the list.i can understand you don't like to have python 
dependency.but i don't think the "user first" argument is not a good reason.for 
some users (like me) python is definitely easier to deal withthan the current 
state of kconfig-frontends.>> Greg>> On 5/25/2020 9:38 AM, Nathan Hartman 
wrote:> > On Mon, May 25, 2020 at 12:36 AM Takashi Yamamoto> > 
 wrote:> >> On Mon, May 25, 2020 at 1:00 AM 
Nathan Hartman  wrote:> >>> We do have to solve the 
issue of Kconfig. That has disappeared from> >>> the Internet and we depend on 
it. We were told, before we joined> >> do we have some reasons not to switch to 
kconfiglib?> > Does kconfiglib depend on Python? Currently we do not have a> > 
dependency on Python. That would introduce Python as a pretty big> > 
dependency, which I would rather avoid.> >> > Also, that project could 
disappear from the Internet, just like> > Kconfig, and we'd be back at square 
one.> >> > I think we should solve the kconfig licensing / hosting question.> > 
Early in our ASF efforts we were told that exceptions are sometimes> > made so 
that a project can host "well-known" third party tools that it> > depends on. 
We depend on kconfig as a central piece of our build> > system, just as we 
depend on 3rd party compiler toolchains etc. It> > runs on the developer's host 
machine. It does NOT get compiled into> > the user's NuttX build. Kconfig as a 
project has come and gone from> > the Internet so for the time being Greg is 
hosting a mirror at his> > BitBucket along with other build tools.> >> > We 
need some guidance from our mentors on how to ensure the longevity> > of the 
tools, like Kconfig, that are needed for NuttX, at Apache> > NuttX, not at some 
third party location that can disappear suddenly.> >> > Thanks,> > Nathan>>

RE: enter/leave_critical_section() calls in the user space library

[spudaneco]

I don't understand why you need to do that.But for the SMP case there is a 
better, lighter weight critical section called spinlock_irqsave.  It is 
intended to protect very short code sequences with a spin lock.  Very 
efficient.enter_critical_section is a big, fat pig in SMP and the lighter 
spinlock should be used instead.The only thing is that the protected code 
segment must not suspend itself while holding the spinlock.GregSent from 
Samsung tablet.
 Original message From: "Nakamura, Yuuichi (Sony)" 
 Date: 5/11/20  10:34 PM  (GMT-06:00) To: 
dev@nuttx.apache.org Cc: "Nakamura, Yuuichi (Sony)" 
 Subject: RE: enter/leave_critical_section() calls 
in the user space library Thanks for accepting my PR.Now it's ok for protected 
build with uniprocessor case, but not sufficient in SMP case.The following 
files included in the user mode library contain enter/leave_critical_section() 
only when CONFIG_SMP=y.libs/libc/misc/lib_filesem.cmm/mm_heap/mm_sem.cThese may 
have to be moved into the kernel space.Thanks,Yuuichi Nakamura> -Original 
Message-> From: Xiang Xiao > Sent: Monday, May 
11, 2020 3:20 PM> To: dev@nuttx.apache.org> Subject: RE: 
enter/leave_critical_section() calls in the user space library> > But we need 
to consider syslog call from interrupt context too. So I think the> simple 
modification is:> 1.Drop the critical section> 2.Keep the global variable> In 
FLAT/PROTECTED build, all user space applications have to share the same> 
variable.> > -Original Message-> From: Gregory Nutt 
> Sent: Monday, May 11, 2020 12:35 PM> To: 
dev@nuttx.apache.org> Subject: Re: enter/leave_critical_section() calls in the 
user space library> > > >  From this link:> > 
https://linux.die.net/man/3/setlogmask> > logmask has per task scope not per 
thread scope. So we still suffer the> concurrent issue if we change to 
group-specific logmask.> > The same text appears in the more authoritative 
Opengroup.org web page:> 
https://pubs.opengroup.org/onlinepubs/7908799/xsh/closelog.html> > We meet that 
requirement in the KERNEL mode, but not in the FLAT or> PROTECTED modes.> > So 
the logmask must be in the group structure and setlogmask must become a> system 
call at least in the FLAT and PROTECTED build.  In the KERNEL build,> a plain 
global variable as it is now is just fine.  There will be one instance of the> 
global variable in each process address space.> > pthread APIs are not 
appropriate for use across processes (groups), so we> must avoid pthread 
mutexes.  This will not work in the KERNEL build mode> because each mutex lies 
in a different address space.   A usable mutex would> have to use something 
like sem_open() which creates a semaphore can be> used across process 
boundaries.> > Note that setlogmask is classified as NOT thread safe: 
Preliminary: |> MT-Unsafe race:LogMask | AS-Unsafe | AC-Safe | See POSIX Safety 
Concepts>  
cepts.html#POSIX-Safety-Concepts>.> See 
https://www.gnu.org/software/libc/manual/html_node/setlogmask.html> > So we 
should have no concern about thread safety.  No re-entrancy protection> is 
required.  We can just remove the critical section. We do not need to use a> 
semaphore or mutex.> > Greg> 

Re: Build errors with inline functions

[spudaneco]

> Another example, we use MPU to protect the code section for NOXIP casein the 
> flat mode.Some have used the MPU to catch runtime NULL pointer accesses.  
> There is a HowTo for this case in the Wiki.Sent from Samsung tablet.
null

Re: Should we relax precheck a little bit?

[spudaneco]

I am oppose to modyfing source files to support the tool.  I don't think we 
should go that direction.Sent from Samsung tablet.
 Original message From: "Schock, Johannes - NIVUS GmbH" 
 Date: 3/15/20  5:47 AM  (GMT-06:00) To: 
dev@nuttx.apache.org Subject: Re: Should we relax precheck a little bit? 
Hello,I filed a pull request that introduces an idea of controlling the 
behaviour of nxstyle from inside the file under 
test.https://github.com/apache/incubator-nuttx/pull/569This would allow to 
address some special requirements that are needed in cornercases (e.g. 
whitelisting), and, by using the ignore feature, to switch of testing for 
ranges of the file that are correct but nxstyle isn't happy about it (yet 
unaddressed cornercases).This would give a contributor/commiter the possibility 
to explicitly pass the PR through the style check, and perhaps file an nxstyle 
issue.From time to time we could grep for the ignore command and remove it if 
the issue had been resolved.Please share your thoughts.JohannesP.S.: if some 
aren't happy with the xml-like syntax, we can change this for sure

RE: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up buffer problems

[spudaneco]

This sounds like a data cache problem.  One difference between the i.MXRT and 
the LPC43 is that it has a data cache.  So you must flush the cache before 
starting any DMA operation and invalidate the cache before reading any 
DMAdata.GregSent from Samsung tablet.
 Original message From: Thomas Axelsson 
 Date: 2/20/20  5:24 AM  (GMT-06:00) To: 
dev@nuttx.apache.org Subject: IMXRT 1060 USB Device (copy of LPC43/LPC31 
driver) - Set-up buffer problems 

Hi,
 
I’m trying to get the IMXRT1060-EVK working as a USB device using the USB OTG1 
peripheral.
 
By comparing reference manuals, I’ve figured that the USB peripheral seems to 
be identical to the one found in NXP LPC43xx (and LPC31xx). As such, I’ve 
copied lpc43_usb0dev.c, replaced all the registers with the IMX RT
 registers and tweaked the initialization. I have made some ugly copies 
(throwing in the PLL init in the driver) that will need to be cleaned up, once 
the driver is working. Also, it is currently full of small hacks, trying to get 
it to work. I have included
 the almost unmodified, copied LPC43 driver, in the patch as well, for 
comparison.
 
The driver is almost working, but I’ve stumbled on a problem with reading the 
Set-up buffer in the EP0 Queue Head (g_qh[0].setup) (struct that resides in 
RAM).
 
What I’ve found is that

The host sends Get Descriptor and the device responds correctly. (Green line in 
USB trace image)The host sends Set Address (not visible in Linux usbmon trace!) 
but the device reads the old Get Descriptor packet from g_qh[0].setup and 
responds as if Get Descriptor
 was sent. (Blue line and following red text in USB trace image)
 
When playing around with the code I have sometimes found .setup to be all 
zeroes, when the host does  Get Descriptor, Reset, . Meaning that 
the zeroes written by imxrt_usbreset() has not been overwritten by
 the USB controller.
 
I have also at one time managed to read .setup repeatedly, after the 
ENDPTSETUPSTAT has been set, until the value changed and gotten the Set 
Address. However, I’m having a hard time to reproduce it.
 
So it seems that the data in g_qh[0].setup is only filled correctly for the 
first setup package and not updated again, or sometimes updated with a large 
delay.
 
I have tried sprinkling some volatile, in case the imxrt_readsetup() code would 
skip the memory access, without success.
 
 
Any ideas on what might be going wrong or where to dig?
 
I have included the current state of the driver (imxrt_usbdev.c) and a 
patch+defconfig if someone wants to play on an IMXRT EVK. The patch was 
generated against NuttX master branch.
 
 
Here is a snippet from the console output on the device, showing how the device 
reacts to Get Descriptor followed by Set Address.
Please note that ENTRY and EP0SETUP is doubly traced since I’ve duplicated the 
trace lines in the code.
 
Interrupt decode    8: IMXRT_TRACEINTID_EP0SETUP    0001
Interrupt decode    8: IMXRT_TRACEINTID_EP0SETUP    0001
Interrupt decode   18: IMXRT_TRACEINTID_GETSETDESC  
Interrupt decode    5: IMXRT_TRACEINTID_DISPATCH    
...
Interrupt entry 1: ENTRY    
Interrupt entry 1: ENTRY    0081
Interrupt decode    8: IMXRT_TRACEINTID_EP0SETUP    0001
Interrupt decode    8: IMXRT_TRACEINTID_EP0SETUP    0001
Interrupt decode   18: IMXRT_TRACEINTID_GETSETDESC   <<--- This 
should have been SETADDRESS!
Interrupt decode    5: IMXRT_TRACEINTID_DISPATCH    
 
 
Testing the patch:
git checkout 90839b41f92aa01f1b0b24d18ee62e6efa4077d5  # or current master
apply the patch
tools/configure.sh imxrt1060-evk:nsh
cp downloads/defconfig defconfig
make olddefconfig
make
 
Flash board
Connect USBOTG1 (connector J9) to host.
Press  in nsh to see the usbtrace (I did not manage to use the USB 
Monitor with NSH).
 
(I've found that I have to toggle the boot config to  on SW7 and reset, to 
be able to flash with J-Link after starting this NuttX config. It does not 
happen in my dev code, so I'm ignoring that
 issue.)
 
 
Thomas Axelsson
SW Developer
ACTIA Nordic AB
(part of ACTIA Group)
 
Mail:
thomas.axels...@actia.se

Web:
www.actia.se

 

 

RE: Re: NuttX SocketCAN implementation

[spudaneco]

The requirements from Pavel are inconsistent with the current character driver. 
 Certainly it could be possible to use a common backend, but I suspect it would 
be simpler not to.Sent from my Samsung Galaxy smartphone.
 Original message From: Peter Van Der Perk 
 Date: 2/11/20  9:48 AM  (GMT-06:00) To: 
dev@nuttx.apache.org Subject: RE: Re: NuttX SocketCAN implementation >I believe 
that both sides would be the same.  Both would use BSD sockets, SocketCAN would 
be added to the network stacks, and the CAN drivers would be a network 
drivers.>>Your picture shows the existing implementation using character 
drivers.>SocketCAN is intended to be integrated into the network.Thanks for the 
quick response, indeed you're right the CAN drivers would become network 
drivers and in the BSD sockets layer we can add the PF_CAN protocol. However my 
question is then, would there still be a need for need for CAN using character 
drivers (and userspace api)? If so, do we have to make 2 separate HW drivers, 
one for CAN using character devices and one for CAN using SocketCAN? Or does 
the current infrastructure support both? The reason why I'm asking this is to 
think about trade-offs between compatibility, realtime performance and 
maintainability.>I amn't familiar with CAN, but is it possible to implement a 
general CAN MAC driver on top of CAN CHAR driver like 
this?>+---+>| NuttX Network driver  |>| 
++ ++ |>| |Syscall glue| |BSD Socket  | |>| |   
 | |glue    | |>| ++ ++ 
|>+---+>+---+ file_*    
+---+>| Hardware MAC driver   |-->| 
  NuttX CAN Driver (can.c)    |>+---+   | 
++ >+---+ ++ |> 
   | |Syscall glue| |Char driver | |>   
 | |    | |glue    | |> 
   | ++ ++ |>   
 +---+> 
   +---+>   
 | Hardware CAN driver   |> 
   +---+ So we just need write one 
CAN driver, but the user can select socket or char as they want.From 
ease-of-implementation perspective that would be the way to go. However this 
would mean that a CAN frame would go through the CAN driver -> Char driver -> 
VFS -> Socket -> user space. This would add unnecessary delay and jitter which 
would be certainly worse. Ideally I would implement it as shown below. The 
question is though then how do deal with existing CAN character device 
implementation?   NuttX SocketCAN implementation   
Proposal+---+|  Application  
|+---++---+|    
POSIX Interface    |+---++-+   
+-+|System calls |   |BSD socket   || |   |net/sockets  
|+-+   +-++---+| NuttX 
Network driver  || ++ ++ || |Syscall glue| |BSD 
Socket  | || |    | |glue  PF_CAN| || ++ ++ 
|+---++---+|   NEW 
Hardware CAN driver 
|+---++---+|OS 
(sched/), memory manager    ||(mm/), common libraries 
(libs/)|+---++---+| 
  Hardware    |+---+

Lost Repository History

[spudaneco]

It appears we have lost the first 6 year of history in the NuttX repository.  
The oldest commit looks like it is from 2013.  The oldest should be from 
february 2007.If i look at the statistics, it says I have 19 thousand commits.  
That should be 36 thousand,Is the repository permanently broken? Or can we 
recover the history.GregSent from Samsung tablet.

Re: ILI9341 port to STM32F4

[spudaneco]

Sent from Samsung tablet.
It seems strange that by not selecting CONFIG_NX_KBD it stil is trying 
tocompile stuff that has relations with this config?src/cnxwidget.cxx:691:65: 
error: 'class NXWidgets::CWidgetControl' has nomember named 'doubleClick'   if 
(m_flags.doubleClickable && hasFocus() 
&_widgetControl->doubleClick())DoubleClick has nothing to do with the 
ketboard.  That is mouse codeAnd other problems. It seems I have to make 
changes in the NX side of Nuttxto get this going..?I don't understand that.

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[spudaneco]

+1Singin' to choir!Sent from my Samsung Galaxy smartphone.
null

Re: 404 on site (Project status Nuttx)

[spudaneco]

How does this effect ongoing Confuence development on Brennan's old site?  This 
needs to move to a new URL. What is the URL? Will additional changes to 
Brennan's site be lost?Thanks,GregSent from Samsung tablet.
 Original message From: Hans  Date: 
12/27/19  4:16 AM  (GMT-06:00) To: dev@nuttx.apache.org Subject: Re: 404 on 
site (Project status Nuttx) Hi mentors,Xiang has already imported the project 
website Brennan created into theofficial Apache NuttX Website 
repository.https://github.com/apache/incubator-nuttx-websiteHow can it be 
published to https://nuttx.apache.org/?Thanks,Huahang-- 刘华航 (Hans)行走, 思考, 在路上

RE: Workflow Development

[spudaneco]

We should get a quick read from Justin: is developing substantial code outside 
of incubator acceptable? And how do we get a proper review againet the workflow 
requirements before merging upstream?You really should wait for the workflow 
requirements first or be completely open to rework.Will we get an SGA for the 
PX4 code that will come in? If not, it cannot beome Apache.Sent from Samsung 
tablet.
null

Re: User Email Account

[spudaneco]

I may grumble a bit bur I always follow Justin's advice.I do think that NuttX 
is diferent from other new podlings because  began with a huge user base and 
has a few different needs on day 1 as a mature project.I don't believe that 
finding new committers will be a problem.Sent from Samsung tablet.
 Original message From: Adam Feuer  Date: 
12/26/19  1:23 AM  (GMT-06:00) To: dev@nuttx.apache.org Subject: Re: User Email 
Account I think what Justin is saying is that it's going to seem like 
uncomfortablechaos for a bit, but will eventually settle down into a better 
state.From what I know about well-functioning teams, that seems right. 
Form,storm, norm, 
perform. 
:)cheersadamOn Wed, Dec 25, 2019 at 8:28 PM Justin Mclean 
wrote:> Hi,>> Most of those are not current 
incubating projects. Some of them did not> become to level projects. Just about 
all did not start with user lists.> Creating a seperate user list this early in 
previous incubating projects> has slowed or hindered their community growth. 
You want users involved so> that they become committers. At no point have I 
said you can't do this but> the PPMC needs to carefully consider it. My 
Internet access is limited> right now but if you search on the incubator 
general list you'll see> several discussions on this.>> Thanks,> Justin>-- Adam 
Feuer 

Re: Community

[spudaneco]

It is too early to be digging holes.  Let's agree where the whole should be dug 
before we start digging.  Then there will be no one looking over your 
shoulder.Sent from Samsung tablet.
 Original message From: David Sidrane  
Date: 12/23/19  4:10 AM  (GMT-06:00) To: dev@nuttx.apache.org Subject: Re: 
Community On 2019/12/22 19:29:38, Gregory Nutt  wrote: > > 
> Don't feel bad if there is haggling. Any document, no matter who writes it> > 
or how well, will need more work to fill in missing pieces, edit, etc., to> > 
bring it to "shipping quality." I will try to help as much as I can in the> > 
coming days, but as I said I'm really swamped right now.> > But there are 
issues of trust related here.   I would not trust DavidS > to write objective 
work flow requirements now.  And I have no reason to > believe that he would 
trust me to do so either. Although I can say that > it would be my intention to 
produce a fair representation of the overall > discussion, my references would 
also be reflected in certain areas.> > > Greg - please realize  that anything I 
(or you) suggest are just suggestion and examples. We are all going have to 
AGREE on what we will implement. Nothing bad is going to happen. None of it is 
in stone.I would ask you to not couch thing in trust. It is not about trust. It 
is about experience.  You have created a wonderful gift to the world, in Nuttx. 
Using a "single commiter" model, a set of tools that you manage, and your own 
way of working.  You referred  to yourself as a Github  N00B. Other members on 
this team use github everyday. Their experience is what is of value here. I 
have not doubt that after you are a seasoned GH user of you would be able to 
craft the perfect GH work flow. My dad shared this with me once: If you can not 
dig a hole, do not stand over someone who is digging and tell them how to dig. 
Get the hell out of the way, let them do their job and bring them water.Another 
pearl from him is: "You can't push a string"

Re: Project Emails

[spudaneco]

Sent from Samsung tablet.
I think we should use release branches, unless we want to lock downthe repo 
against all changes for the duration of the release prep ->release candidate -> 
testing -> debating -> voting cycle, which couldtake a non trivial amount of 
time.You could carry on business as usual on a temporary branch, but that feels 
awkward.