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/ctype
> > .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
> >
AMD64 arch
I am looking for a RTOS to replace the current RTOS we use. We are currently using FreeDOS, however since it is 16bit it have found it almost impossible to access a new device, PCIe mmio. While searching the web for a RTOS I found Nuttx. Does Nuttx support x86-64 processors? I thought it might however the more I read the less I am convinced of it. Basically I only need one application to run that will need network access and access to locally stored files along with PCIe MMIO. The PCIe device is a FPGA that has GPIO, Isolated GPIO, Quadrature decoders, 16bit AO, and 10 CTs. Am I barking up the wrong tree with Nuttx? If I am, no biggie. If not and Nuttx can do what I need can anyone point me in the right direction to get started? Thanks in advance. NOTICE: This e-mail message and all attachments transmitted with it may contain trade secrets and confidential information intended solely for the use of the addressee. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by telephone at 407-679-9716, and delete this message and all copies and backups thereof. Thank you
Re: AMD64 arch
Robert, I think the answer is yes x86_64 is supported. I haven't used it myself, but here's the NuttX x86_64 status blurb: https://cwiki.apache.org/confluence/display/NUTTX/About#80x86 -adam On Tue, Jul 28, 2020 at 8:32 AM Robert Faron wrote: > I am looking for a RTOS to replace the current RTOS we use. We are > currently using FreeDOS, however since it is 16bit it have found it almost > impossible to access a new device, PCIe mmio. While searching the web for > a RTOS I found Nuttx. > > Does Nuttx support x86-64 processors? I thought it might however the more > I read the less I am convinced of it. Basically I only need one > application to run that will need network access and access to locally > stored files along with PCIe MMIO. The PCIe device is a FPGA that has > GPIO, Isolated GPIO, Quadrature decoders, 16bit AO, and 10 CTs. > > Am I barking up the wrong tree with Nuttx? If I am, no biggie. If not and > Nuttx can do what I need can anyone point me in the right direction to get > started? > > Thanks in advance. > NOTICE: This e-mail message and all attachments transmitted with it may > contain trade secrets and confidential information intended solely for the > use of the addressee. If the reader of this message is not the intended > recipient, you are hereby notified that any reading, dissemination, > distribution, copying, or other use of this message or its attachments is > strictly prohibited. If you have received this message in error, please > notify the sender immediately by telephone at 407-679-9716, and delete this > message and all copies and backups thereof. Thank you > -- Adam Feuer
Re: AMD64 arch
I think the answer is yes x86_64 is supported. I haven't used it myself, but here's the NuttX x86_64 status blurb: https://cwiki.apache.org/confluence/display/NUTTX/About#80x86 Certainly it builds. Our CI builds the x86_64 configurations on every commit. There is also PCIe support on a feature branch: https://github.com/apache/incubator-nuttx/tree/pci I have no idea of the state of PCIe. It has not been touched in some time.
Re: AMD64 arch
On Tue, Jul 28, 2020 at 10:05 AM Gregory Nutt wrote > Certainly it builds. Our CI builds the x86_64 configurations on every > commit. There is also PCIe support on a feature branch: > https://github.com/apache/incubator-nuttx/tree/pci I have no idea of > the state of PCIe. It has not been touched in some time. I was working on it quite a bit for a while, but it has sat and I need to come back to it again after I finish up some other work. This PR against that branch works to resolve some of the issues and also implements some test drivers against the PCI interface. https://github.com/apache/incubator-nuttx/pull/1004 One thing that would be important would be to understand what processor you are using. The support right now requires some specific features, especially around ACPI. It would be great to get some more real usage of the port, so I am happy to help as much as I can, if there are specific features that need to be implemented. Yang Chung Fan is the one who really did the core work, I have just been trying to clean up and expand on the PCI support. He is actually giving a talk next month at our workshop on this. --Brennan
Re: AMD64 arch
One thing that would be important would be to understand what processor you are using. If there is some specific hardware, I would also be willing to buy a board and help out... although I am no x86_64 expert (I did do the i486 port some years ago, but that is about the extent of that).
Re: AMD64 arch
On Tue, Jul 28, 2020 at 11:32 AM Robert Faron wrote: > I am looking for a RTOS to replace the current RTOS we use. We are currently > using FreeDOS, however since it is 16bit it have found it almost impossible > to access a new device, PCIe mmio. While searching the web for a RTOS I > found Nuttx. Welcome to the NuttX community! There have been several responses to your question on our mailing list, but I'm not sure whether you're subscribed, so maybe you didn't receive them. But you can see the replies in the mailing list archive here: https://lists.apache.org/thread.html/r25431412be85df3ec5111d31360bc161b466a55567f8d6f924796a5a%40%3Cdev.nuttx.apache.org%3E Cheers, Nathan
RE: AMD64 arch
>>One thing that would be important would be to understand what >> processor you are using. >If there is some specific hardware, I would also be willing to buy a board and >help out... although I am no x86_64 expert (I did do the i486 port some years >ago, but that is about the extent of that). I have yet to determine what hardware we will use. While testing and developing I am currently using an ASUS 855M-E. Just because I have it laying around. Though if an Intel 9th gen board is easier to acquire I could also change boards. -Original Message- From: Gregory Nutt Sent: Tuesday, July 28, 2020 1:21 PM To: dev@nuttx.apache.org Subject: Re: AMD64 arch > One thing that would be important would be to understand what > processor you are using. If there is some specific hardware, I would also be willing to buy a board and help out... although I am no x86_64 expert (I did do the i486 port some years ago, but that is about the extent of that). NOTICE: This e-mail message and all attachments transmitted with it may contain trade secrets and confidential information intended solely for the use of the addressee. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by telephone at 407-679-9716, and delete this message and all copies and backups thereof. Thank you
deprecating old list?
Hi, wouldn't it be best to disable posting and subscription to the old google groups and add an auto-reply message which indicates that they should subscribe to the new group? Here are a few indications on how that can be done: auto-reply: https://support.google.com/groups/answer/9792589?hl=en&ref_topic=2458761 stop posts: https://support.google.com/groups/answer/2646833?hl=en There should also be a setting to disallow subscriptions, but I can't find that. Best, Matias
Re: deprecating old list?
On Tue, Jul 28, 2020 at 2:58 PM Matias N. wrote: > wouldn't it be best to disable posting and subscription to the old google > groups and add an auto-reply message which indicates that they should > subscribe to the new group? > > Here are a few indications on how that can be done: > auto-reply: > https://support.google.com/groups/answer/9792589?hl=en&ref_topic=2458761 > stop posts: https://support.google.com/groups/answer/2646833?hl=en > > There should also be a setting to disallow subscriptions, but I can't find > that. An alternative suggestion: Grow the community by having more presence on popular social media platforms, rather than shutting down the old forums? All technical discussions would be directed to please join the mailing list, but we could use the other platforms to make announcements, etc. In other words, to drum up new "business" for NuttX by being as visible as possible. As to the old Google Group, is it possible to set an auto-reply but not stop posts? The auto-reply would direct people to the mailing list, but remind them that the Google Group (and other venues) are kept for archival purposes. Nathan
Re: deprecating old list?
I agree that building presence on other platforms is desirable. But my suggestion is not mutually exclusive to that. The old list is simply deprecated and every new email from there is replied to "remember this list is deprecated". The auto-reply would at least solve that. Not allowing further subscribers also avoids sending users the wrong way. Not allowing further posts would enforce the use of the correct mailing list (I understand that is the goal). Anyway, this can be done in stages. Auto-reply and disallow subscribe first (to avoid growing the old list and encourage transitioning). Disallowing posts would be like disabling the group completely, so that would be the final step. Best, Matias On Tue, Jul 28, 2020, at 16:56, Nathan Hartman wrote: > On Tue, Jul 28, 2020 at 2:58 PM Matias N. wrote: > > wouldn't it be best to disable posting and subscription to the old google > > groups and add an auto-reply message which indicates that they should > > subscribe to the new group? > > > > Here are a few indications on how that can be done: > > auto-reply: > > https://support.google.com/groups/answer/9792589?hl=en&ref_topic=2458761 > > stop posts: https://support.google.com/groups/answer/2646833?hl=en > > > > There should also be a setting to disallow subscriptions, but I can't find > > that. > > An alternative suggestion: Grow the community by having more presence > on popular social media platforms, rather than shutting down the old > forums? All technical discussions would be directed to please join the > mailing list, but we could use the other platforms to make > announcements, etc. In other words, to drum up new "business" for > NuttX by being as visible as possible. > > As to the old Google Group, is it possible to set an auto-reply but > not stop posts? The auto-reply would direct people to the mailing > list, but remind them that the Google Group (and other venues) are > kept for archival purposes. > > Nathan >
Re: IP Clearance
A focused effort to do the IP clearing sounds good. If we can get funding to do it quicker, that would be great too. It's a good idea. I did the stats that are on the wiki page for the 9.0 release. I'll see if I can run this process on the rest of the project and post the numbers to the wiki. I'll update this thread when I have some results. I'll also see if I can make PR with the scripts Brennan and I were using so that the tools can be in the main repo and anyone can use them. -adam On Sun, Jul 26, 2020 at 8:39 PM 张铎(Duo Zhang) wrote: > OK, there is a sub page, about the status of a module at March > > https://cwiki.apache.org/confluence/display/NUTTX/Analysis+March+2020 > > Let's try to do this on the whole project to get some numbers? > > Thanks. > > 张铎(Duo Zhang) 于2020年7月27日周一 上午11:32写道： > > > IMO we should at least have some numbers about the current status first, > > i.e, how many files can be cleared directly, how many can not, etc. > > > > With the numbers in hand, then we can decide whether it is possible for > us > > to finish the work, and how to finish the work. Even if we want to reach > > out for help from a 3rd party, we still need these numbers so we can > decide > > how much money we should pay... > > > > What I can see on the wiki page > > > > https://cwiki.apache.org/confluence/display/NUTTX/License+Clearing > > > > is just a rough plan, there are no numbers about the current status yet. > > > > Thanks. > > > > Gregory Nutt 于2020年7月27日周一 上午10:43写道： > > > >> We have talked a little about IP clearance on the NuttX podling project > >> but I am not sure if anyone really appreciates the magnitude of this > >> effort: There is 13 years of commits, possibly 50,000 total commits, > >> many hundreds of contributors, 1000's of files, 1.5 million lines of > >> code, and transitions through 3 different configuration management > >> systems. There is no contact information for the majority of the > >> contributors and there is no reason to believe that all contributors > >> will be cooperative. > >> > >> I think that anyone who believes that this can be done properly with the > >> part time, now-and-then effort of a couple of people is sorely > >> mistaken. I think it will require a fully dedicated, team with some > >> specialized expertise and a substantial amount of time to do. > >> > >> The only way that I can conceive of this happening is if we were to > >> contract a 3rd party software CM/QA/IV&V house to to do the job. That > >> would, of course require a serious investment of money. I am wondering > >> if we could motivate some corporate sponsors to fund such an effort. I > >> appreciate that that is a long shot but we should consider it. In the > >> past, Xiaomi, for example, as committed to supporting the licensing/IP > >> clearance effort. But I don't think that anyone really appreciated the > >> effort required at that time. > >> > >> We do have to make this happen and I don't blame anyone on the PPMC for > >> not wanting to take this on. It would cost you the next year of your > >> life .. full time. I wouldn't make that commitment and I would not > >> expect any other individual to do so either. > >> > >> We some need a plan. With no plan, the project will not graduate. Even > >> with a plan in hand, I would not expect graduation to be possible within > >> the next year or more. > >> > >> Greg > >> > >> > >> > -- Adam Feuer
RE: Can we implement ctype functions through table?
The new option just make the situation worse. The same code works in
some configurations, but breaks in other configurations.
Since the standard confirmation is the most important principle for
NuttX, we have three options:
1.Implement ctype function with table and add 256 byte to ROM
2.Change macro to normal function and lose some performance
3.Change macro to inline function and some old compilers may generate
the bloat code
all 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
> > >
