Re: Simulator loop task.
On Fri, Jul 22, 2022 at 12:12 AM Fotis Panagiotopoulos
wrote:
> Here is the actual issue:
>
> The timer g_system_timer is updated in the IDLE task.
> This causes problems, because time is not advancing if the system does not
> have any idle time.
>
>
Ok, you don't enable tickless mode. If you enable it like us, the
timestamp will reflect the real value even if some thread is busy.
The timer behaves erratically, or just gets stuck.
> For example, a spin-lock-like structure, as is the following snippet, works
> correctly on a hardware target, but locks-up in sim:
>
> while ((clock() - start) < TIMEOUT)
> {
> if (foo())
> break;
> }
>
> I thought that I should move g_system_timer in the loop task, but then I
> realized that it also runs at SCHED_PRIORITY_MIN.
>
> I expect similar problems on other parts of the simulator, in such
> spin-lock like codes.
> For example while waiting for serial input, without any sleep.
> (Practically all cases that are normally served by interrupts).
>
>
> My proposition is to:
> * Set the loop task to SCHED_PRIORITY_MAX. (I tested it, it works and I
> don't expect side effects).
> * Move the remaining logic within the idle task to the loop task.
>
>
> What do you think?
>
>
I think it's fine or better to use the highest priority thread to simulate
the interrupt.
>
> On Thu, Jul 21, 2022 at 6:56 PM Xiang Xiao
> wrote:
>
> > On Thu, Jul 21, 2022 at 11:27 PM Fotis Panagiotopoulos <
> > f.j.pa...@gmail.com>
> > wrote:
> >
> > > Hello,
> > >
> > > I am having some issues with scheduling in simulator.
> > > I noticed that there is a "loop task", that performs various
> > house-keeping
> > > tasks.
> > >
> > > This task is started with a priority of SCHED_PRIORITY_MIN.
> > > Is this correct / on-purpose?
> > >
> > >
> > The house keeping work ran in the idle loop before, but since some work
> may
> > sleep/wait internally, we have to move them to the "loop task". That's
> why
> > we select SCHED_PRIORITY_MIN.
> >
> >
> > > I would expect this task to run on maximum priority, simulating various
> > > interrupt or timer events that an MCU would normally have.
> > >
> >
> > It should be fine to increase the priority of the "loop task".
> >
>
Re: Simulator loop task.
Here is the actual issue:
The timer g_system_timer is updated in the IDLE task.
This causes problems, because time is not advancing if the system does not
have any idle time.
The timer behaves erratically, or just gets stuck.
For example, a spin-lock-like structure, as is the following snippet, works
correctly on a hardware target, but locks-up in sim:
while ((clock() - start) < TIMEOUT)
{
if (foo())
break;
}
I thought that I should move g_system_timer in the loop task, but then I
realized that it also runs at SCHED_PRIORITY_MIN.
I expect similar problems on other parts of the simulator, in such
spin-lock like codes.
For example while waiting for serial input, without any sleep.
(Practically all cases that are normally served by interrupts).
My proposition is to:
* Set the loop task to SCHED_PRIORITY_MAX. (I tested it, it works and I
don't expect side effects).
* Move the remaining logic within the idle task to the loop task.
What do you think?
On Thu, Jul 21, 2022 at 6:56 PM Xiang Xiao
wrote:
> On Thu, Jul 21, 2022 at 11:27 PM Fotis Panagiotopoulos <
> f.j.pa...@gmail.com>
> wrote:
>
> > Hello,
> >
> > I am having some issues with scheduling in simulator.
> > I noticed that there is a "loop task", that performs various
> house-keeping
> > tasks.
> >
> > This task is started with a priority of SCHED_PRIORITY_MIN.
> > Is this correct / on-purpose?
> >
> >
> The house keeping work ran in the idle loop before, but since some work may
> sleep/wait internally, we have to move them to the "loop task". That's why
> we select SCHED_PRIORITY_MIN.
>
>
> > I would expect this task to run on maximum priority, simulating various
> > interrupt or timer events that an MCU would normally have.
> >
>
> It should be fine to increase the priority of the "loop task".
>
Re: Simulator loop task.
On Thu, Jul 21, 2022 at 11:27 PM Fotis Panagiotopoulos wrote: > Hello, > > I am having some issues with scheduling in simulator. > I noticed that there is a "loop task", that performs various house-keeping > tasks. > > This task is started with a priority of SCHED_PRIORITY_MIN. > Is this correct / on-purpose? > > The house keeping work ran in the idle loop before, but since some work may sleep/wait internally, we have to move them to the "loop task". That's why we select SCHED_PRIORITY_MIN. > I would expect this task to run on maximum priority, simulating various > interrupt or timer events that an MCU would normally have. > It should be fine to increase the priority of the "loop task".
Re: Wikipedia: "Proposal deletion of NuttX"
Hi, The NuttX page should obviously not be deleted by it is not exactly written in an encyclopedic style I see text like (because Mr Greg did something and something) - you should try to edit that so that it sounds more formal and neutral This is not biased opinions, but is clearly not academic enough. Also I can understand how the endless list of features looks like and excerpt of the website and promotes too much. It should be shorter and contain more explanations as paragraphs of text than lists. This list sounds like bragging. Inspiration could be obtained on other RTOS pages... https://en.wikipedia.org/wiki/FreeRTOS Sebastien Le 21/07/2022 à 16:19, Tomek CEDRO a écrit : On Thu, Jul 21, 2022 at 3:56 PM Alan Carvalho de Assis wrote: Hi Tomek, Thank you for your support on it. I don't know how we could avoid it, if someone decided that NuttX is not relevant they can go on and try to suggest to remove the article. Hmm looking at the activities from the IP address (USA/California?) that stated bias there were also some good commits for NuttX page. This may be someone from our community? Maybe a FitBit developer? :-P https://en.wikipedia.org/wiki/Special:Contributions/96.46.149.166 Fortunately I was on my computer today and saw it, but imagine if I was in vacation? Yup, exactly, people not familiar with the subject are deciding on knowledge removal, quite frightening. Maybe others here need to setup some notification to receive case someone edit the NuttX page, I think wikipedia support it. I did some small update (stated FOSS directly after NuttX and before RTOS should be clear enough what kind of project this is) and thus subscribed to the page, I should get notifications too :-) In the other hand, the only way we could get more awareness and making NuttX more popular. Unfortunately nobody here replied to Alin emails asking for help to NuttX Workshop, seems like nobody really cares about NuttX and it is really sad. I would be more that glad to attend this kind of workshop but have nothing to offer to present yet sorry :-( World now seems a bit messy, probably on purpose by some groups of interests, people often have problems with basic life conditions now like food and accommodation, struggling to fulfill the Edison's vision of paying the bills, a time is most precious now and this is really sad I we cannot focus on important creative tasks as we would really wanted, its not always matter of "care" but "can" I guess.
Simulator loop task.
Hello, I am having some issues with scheduling in simulator. I noticed that there is a "loop task", that performs various house-keeping tasks. This task is started with a priority of SCHED_PRIORITY_MIN. Is this correct / on-purpose? I would expect this task to run on maximum priority, simulating various interrupt or timer events that an MCU would normally have.
Re: Wikipedia: "Proposal deletion of NuttX"
On Thu, Jul 21, 2022 at 3:56 PM Alan Carvalho de Assis wrote: > Hi Tomek, > Thank you for your support on it. > I don't know how we could avoid it, if someone decided that NuttX is > not relevant they can go on and try to suggest to remove the article. Hmm looking at the activities from the IP address (USA/California?) that stated bias there were also some good commits for NuttX page. This may be someone from our community? Maybe a FitBit developer? :-P https://en.wikipedia.org/wiki/Special:Contributions/96.46.149.166 > Fortunately I was on my computer today and saw it, but imagine if I > was in vacation? Yup, exactly, people not familiar with the subject are deciding on knowledge removal, quite frightening. > Maybe others here need to setup some notification to receive case > someone edit the NuttX page, I think wikipedia support it. I did some small update (stated FOSS directly after NuttX and before RTOS should be clear enough what kind of project this is) and thus subscribed to the page, I should get notifications too :-) > In the other hand, the only way we could get more awareness and making > NuttX more popular. Unfortunately nobody here replied to Alin emails > asking for help to NuttX Workshop, seems like nobody really cares > about NuttX and it is really sad. I would be more that glad to attend this kind of workshop but have nothing to offer to present yet sorry :-( World now seems a bit messy, probably on purpose by some groups of interests, people often have problems with basic life conditions now like food and accommodation, struggling to fulfill the Edison's vision of paying the bills, a time is most precious now and this is really sad I we cannot focus on important creative tasks as we would really wanted, its not always matter of "care" but "can" I guess. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Wikipedia: "Proposal deletion of NuttX"
Hi Tomek, Thank you for your support on it. I don't know how we could avoid it, if someone decided that NuttX is not relevant they can go on and try to suggest to remove the article. Fortunately I was on my computer today and saw it, but imagine if I was in vacation? Maybe others here need to setup some notification to receive case someone edit the NuttX page, I think wikipedia support it. In the other hand, the only way we could get more awareness and making NuttX more popular. Unfortunately nobody here replied to Alin emails asking for help to NuttX Workshop, seems like nobody really cares about NuttX and it is really sad. BR, Alan On 7/21/22, Tomek CEDRO wrote: > On Thu, Jul 21, 2022 at 2:33 PM Tomek CEDRO wrote: >> (..) Wikipedia is not what it used to be. (..) > > By the way, in any system there should be a feedback controlling the > system, including rogue administrators. We cannot accept this > situation, as this happened to me before, it happens now, and it will > happen in future. Wikipedia cannot become a dictatorship of an > uncontrolled group. > > Any ideas? :-) > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
Re: Wikipedia: "Proposal deletion of NuttX"
On Thu, Jul 21, 2022 at 3:17 PM Tomek CEDRO wrote: > I have posted an opposition to deleting Free-and-Open-Source projects > from WikiPedia, particulary the NuttX, with explanation, on the > MrsSnoozyTurtle (focused mostly on deleting articles) talk page: > > https://en.wikipedia.org/wiki/User_talk:MrsSnoozyTurtle In addition: 1. I have added my opposition to removing NuttX page from WikiPedia in the Talk section: https://en.wikipedia.org/wiki/Talk:NuttX 2. I have marked potential requester IP as spam / troll: https://en.wikipedia.org/w/index.php?title=User_talk%3A96.46.149.166#SPAM_/_Troll_? Hope that helps, more users are welcome to comment, we have one week :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Wikipedia: "Proposal deletion of NuttX"
Thank you guys! I just remove the Removal and asked the guy to explain what he saw as Promotion Material. Michael, I think it is a good idea to keep the listing of supported features, it could help people that are not developers to make the direct decision when choosing a RTOS. Please take a look at FreeRTOS page, they list all supported MCUs and features. BR, Alan On 7/21/22, Michal Lenc wrote: > > Hi Alan, > > > > > as a former administrator on Czech Wikipedia I personally do not see a > reason for a deletion. But it may be the standards on English Wiki are > different, each language mutation has its own rules. What could help from > my > point of view would be an addition of "history" chapter or something like > that and a deletion of the long lists of key futures, platforms and > drivers. > Those generally should not be included in a good Wikipedia article. If the > readed wants to know for example all supported platforms he should refer to > > NuttX documentation. Still I do not see this as a reason to delete the > page. > > > > > > For now I would reccomend to ask user MrsSnoozyTurtle on his talk page > (https://en.wikipedia.org/wiki/User_talk:MrsSnoozyTurtle) what parts of the > > article does he consider to be promotional so we know what we need to > change. > > > > > > Best regards, > > Michal Lenc > > > > > -- Původní e-mail -- > Od: Alan Carvalho de Assis > Komu: dev > Datum: 21. 7. 2022 13:10:12 > Předmět: Wikipedia: "Proposal deletion of NuttX" > "Hi team, > > I received this email and I don't know what we need to do to avoid it: > > MrsSnoozyTurtle left a message on *your talk page* in "*Proposed > deletion of NuttX*". > The article NuttX has been proposed for deletion because of the following > concern: Promotional article While all constructive contributions to Wiki > "
Re: Wikipedia: "Proposal deletion of NuttX"
On Thu, Jul 21, 2022 at 2:37 PM Tomek CEDRO wrote: > By the way, in any system there should be a feedback controlling the > system, including rogue administrators. We cannot accept this > situation, as this happened to me before, it happens now, and it will > happen in future. Wikipedia cannot become a dictatorship of an > uncontrolled group. > > Any ideas? :-) I have posted an opposition to deleting Free-and-Open-Source projects from WikiPedia, particulary the NuttX, with explanation, on the MrsSnoozyTurtle (focused mostly on deleting articles) talk page: https://en.wikipedia.org/wiki/User_talk:MrsSnoozyTurtle -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Wikipedia: "Proposal deletion of NuttX"
On Thu, Jul 21, 2022 at 2:33 PM Tomek CEDRO wrote: > (..) Wikipedia is not what it used to be. (..) By the way, in any system there should be a feedback controlling the system, including rogue administrators. We cannot accept this situation, as this happened to me before, it happens now, and it will happen in future. Wikipedia cannot become a dictatorship of an uncontrolled group. Any ideas? :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Wikipedia: "Proposal deletion of NuttX"
On Thu, Jul 21, 2022 at 1:10 PM Alan Carvalho de Assis wrote: > Hi team, > I received this email and I don't know what we need to do to avoid it: > MrsSnoozyTurtle left a message on *your talk page* in "*Proposed > deletion of NuttX*". > The article NuttX has been proposed for deletion because of the following > concern: Promotional article While all constructive contributions to Wiki Thank you for your vigilance Alan! We, as the NuttX community, need to object the deletion by creating account on wikipedia and putting our arguments against deletion on the NuttX Talk page. Wikipedia is not what it used to be. I had many situations of this kind. They replaced brains with asses and creators are mostly on the lost position. I lots my faith in wikipedia some time ago. But there are also still some good administrators and we can win this (unnecessary and unjust) fight :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: LCD Framebuffer putarea and display redraw
Excerpts from Alan Carvalho de Assis's message of July 21, 2022 1:20 pm: > Hi Karel, > > On Thursday, July 21, 2022, Karel Kočí wrote: > >> Hi >> >> Excerpts from Alan Carvalho de Assis's message of July 20, 2022 5:21 pm: >> > Hi Karel, >> > >> > On 7/20/22, Karel Kočí wrote: >> >> Hi >> >> >> >> I discovered that commit 664d45dcbace03a879017aa99566592be31f4308 >> broke LCD >> >> >> >> framebuffer (at least for ST7789). The issue is with `putarea` call. >> >> Originally >> >> it was called only when full display redraw was requested but now it is >> >> called >> >> every time when defined. The core of the issue is that from >> documentation >> >> the >> >> buffer passed to the putarea should contain pixels for that area but LCD >> >> framebuffer always passes the complete buffer. >> >> >> > >> > Analyzing logically the expected behavior, now putarea() is now called >> > correctly, so the modification that the guy did on PR #6551 is good. >> > In the past when you was wanting to update only an area of the LCD >> > there existed an updatearea() function inside each LCD drivers that >> > was called. >> > >> > If you enable CONFIG_NX_UPDATE you will see that >> > graphics/nxbe/nxbe_notify_rectangle.c still expecting that >> > updatearea() inside the lcd_dev_s (I discovered it yesterday and I'm >> > trying to fix it). >> > >> > That function was transfered to lcd_framebuffer.c but we you noticed >> > it was calling putarea() only to redraw all the display, that is >> > obviously incorrect. In the other hand, putrun() is a raster function >> > that normally update the LCD line by line (it could be any row or >> > column, but not an area like putarea). >> > >> > Yesterday I sent the PR #6639 that uses the putarea() to rendering of >> > APA102 because it was using putrun() and I could see the image be >> > rendered in the screen because APA102 requires me to send the bit >> > stream sequentially for all the LEDs in the matrix. >> > >> > Now it is very fast as you can see here: >> > >> > https://www.youtube.com/watch?v=qA-UmD8ujlE >> > >> >> I see two possible fixes. Either we call putarea only when full display >> >> update >> >> is requested or we change the definition of the putarea in such a way >> that >> >> it is >> >> driver's resposibility to pick the are from buffer. The first solution >> is >> >> simple >> >> and is pretty much revert to the previous state. The second change is >> kind >> >> of >> >> what is suggested in the new comment added in >> >> 664d45dcbace03a879017aa99566592be31f4308 but no work was done to >> propagate >> >> that >> >> to actuall API documentation in 'include/nuttx/lcd/lcd.h' . >> >> >> >> Thus, what do you think? Revert or propagation of the new behavior? >> >> >> > >> > Although the first solution is simpler it is incorrect (that is the >> > way it was doing before), putarea exist to update an area of the LCD >> > screen. >> I am not against the idea at all. It makes sense. >> >> > I think the right solution is to fix ST7789 to update only the >> > requested area received by putarea(). >> I am going to do that (at least for ST7789). I am also going to update >> documentation for LCD API. Honestly, the only ambiguity and the reason for >> my >> original mail and the need to actually debug this was that this comment >> was >> ignored >> https://github.com/apache/incubator-nuttx/pull/6551#discussion_r912844774 >> and >> changes were merged without updated documentation. It wasn't hard for me >> to >> locate the commit that broke it but it was hard to figure out what was the >> original idea of the committer as that was missing in the commit message. >> Going trough comments in PR is not exactly optimal even if I would not >> ignore PR >> all together. >> >> >> > I completely agree with you! During many years nice features were added on > NuttX, but the documentation didn't follow it. > > Documentation still a weak factor on NuttX. Some years ago someone > suggested we could run some script on our code to extract the functions > documentation, because although we are not using Doxygen the current > functions documentation seems very standardized. I do not consider exported documentation as critical as I read it in header files anyway most of the times. The primary issue, as I see it, is the missing or not updated documentation, as you stated as well. The missing documentation is not nice but I can still read the code (documentation just makes work much more faster). The invalid documentation is on the other hand pretty nasty and should be avoided as much as possible. In any case I created PR https://github.com/apache/incubator-nuttx/pull/6657 that resolves this issue for me but other drivers should be updated as well. The quick grep revealed these LCD drivers: * apa102 (seems to be updated in 9587e4a85e46dd9214f208914134edb34f6cb0a2) * gc9a01 (has the same code as st7789 had and thus needs probably be fixed) With regards Karel Kočí pgpryb0szf8YC.pgp Description:
Re: Wikipedia: "Proposal deletion of NuttX"
Hi Alan, as a former administrator on Czech Wikipedia I personally do not see a reason for a deletion. But it may be the standards on English Wiki are different, each language mutation has its own rules. What could help from my point of view would be an addition of "history" chapter or something like that and a deletion of the long lists of key futures, platforms and drivers. Those generally should not be included in a good Wikipedia article. If the readed wants to know for example all supported platforms he should refer to NuttX documentation. Still I do not see this as a reason to delete the page. For now I would reccomend to ask user MrsSnoozyTurtle on his talk page (https://en.wikipedia.org/wiki/User_talk:MrsSnoozyTurtle) what parts of the article does he consider to be promotional so we know what we need to change. Best regards, Michal Lenc -- Původní e-mail -- Od: Alan Carvalho de Assis Komu: dev Datum: 21. 7. 2022 13:10:12 Předmět: Wikipedia: "Proposal deletion of NuttX" "Hi team, I received this email and I don't know what we need to do to avoid it: MrsSnoozyTurtle left a message on *your talk page* in "*Proposed deletion of NuttX*". The article NuttX has been proposed for deletion because of the following concern: Promotional article While all constructive contributions to Wiki "
RE: Wikipedia: "Proposal deletion of NuttX"
I can't spot promotional materials and I think that we should try to contact MrsSnoozyTurtle and understand what is his concern Best regards Alin -Original Message- From: Alan Carvalho de Assis Sent: den 21 juli 2022 13:10 To: dev Subject: Wikipedia: "Proposal deletion of NuttX" Hi team, I received this email and I don't know what we need to do to avoid it: MrsSnoozyTurtle left a message on *your talk page* in "*Proposed deletion of NuttX*". The article NuttX has been proposed for deletion because of the following concern: Promotional article While all constructive contributions to Wiki
Re: Wikipedia: "Proposal deletion of NuttX"
Hi, well I would recommend to object to deletion per wikipedia guide lines [1]. Then figure out what is deemed "promotional" about the article because I could not. [1]: https://en.wikipedia.org/wiki/Wikipedia:Proposed_deletion#Objecting Regards, Marc Rosen ZeitControl Cardsystems GmbH Siedlerweg 39 D-32429 Minden Tel.++49 (0)571 50 52 222 Fax.++49 (0)571 50 52 299 E-Mail ma...@zeitcontrol.de Am 21.07.2022 um 13:09 schrieb Alan Carvalho de Assis: Hi team, I received this email and I don't know what we need to do to avoid it: MrsSnoozyTurtle left a message on *your talk page* in "*Proposed deletion of NuttX*". The article NuttX has been proposed for deletion because of the following concern: Promotional article While all constructive contributions to Wiki
Re: LCD Framebuffer putarea and display redraw
Hi Karel, On Thursday, July 21, 2022, Karel Kočí wrote: > Hi > > Excerpts from Alan Carvalho de Assis's message of July 20, 2022 5:21 pm: > > Hi Karel, > > > > On 7/20/22, Karel Kočí wrote: > >> Hi > >> > >> I discovered that commit 664d45dcbace03a879017aa99566592be31f4308 > broke LCD > >> > >> framebuffer (at least for ST7789). The issue is with `putarea` call. > >> Originally > >> it was called only when full display redraw was requested but now it is > >> called > >> every time when defined. The core of the issue is that from > documentation > >> the > >> buffer passed to the putarea should contain pixels for that area but LCD > >> framebuffer always passes the complete buffer. > >> > > > > Analyzing logically the expected behavior, now putarea() is now called > > correctly, so the modification that the guy did on PR #6551 is good. > > In the past when you was wanting to update only an area of the LCD > > there existed an updatearea() function inside each LCD drivers that > > was called. > > > > If you enable CONFIG_NX_UPDATE you will see that > > graphics/nxbe/nxbe_notify_rectangle.c still expecting that > > updatearea() inside the lcd_dev_s (I discovered it yesterday and I'm > > trying to fix it). > > > > That function was transfered to lcd_framebuffer.c but we you noticed > > it was calling putarea() only to redraw all the display, that is > > obviously incorrect. In the other hand, putrun() is a raster function > > that normally update the LCD line by line (it could be any row or > > column, but not an area like putarea). > > > > Yesterday I sent the PR #6639 that uses the putarea() to rendering of > > APA102 because it was using putrun() and I could see the image be > > rendered in the screen because APA102 requires me to send the bit > > stream sequentially for all the LEDs in the matrix. > > > > Now it is very fast as you can see here: > > > > https://www.youtube.com/watch?v=qA-UmD8ujlE > > > >> I see two possible fixes. Either we call putarea only when full display > >> update > >> is requested or we change the definition of the putarea in such a way > that > >> it is > >> driver's resposibility to pick the are from buffer. The first solution > is > >> simple > >> and is pretty much revert to the previous state. The second change is > kind > >> of > >> what is suggested in the new comment added in > >> 664d45dcbace03a879017aa99566592be31f4308 but no work was done to > propagate > >> that > >> to actuall API documentation in 'include/nuttx/lcd/lcd.h' . > >> > >> Thus, what do you think? Revert or propagation of the new behavior? > >> > > > > Although the first solution is simpler it is incorrect (that is the > > way it was doing before), putarea exist to update an area of the LCD > > screen. > I am not against the idea at all. It makes sense. > > > I think the right solution is to fix ST7789 to update only the > > requested area received by putarea(). > I am going to do that (at least for ST7789). I am also going to update > documentation for LCD API. Honestly, the only ambiguity and the reason for > my > original mail and the need to actually debug this was that this comment > was > ignored > https://github.com/apache/incubator-nuttx/pull/6551#discussion_r912844774 > and > changes were merged without updated documentation. It wasn't hard for me > to > locate the commit that broke it but it was hard to figure out what was the > original idea of the committer as that was missing in the commit message. > Going trough comments in PR is not exactly optimal even if I would not > ignore PR > all together. > > > I completely agree with you! During many years nice features were added on NuttX, but the documentation didn't follow it. Documentation still a weak factor on NuttX. Some years ago someone suggested we could run some script on our code to extract the functions documentation, because although we are not using Doxygen the current functions documentation seems very standardized. So, as you could guess, it never happened. BR, Alan
Wikipedia: "Proposal deletion of NuttX"
Hi team, I received this email and I don't know what we need to do to avoid it: MrsSnoozyTurtle left a message on *your talk page* in "*Proposed deletion of NuttX*". The article NuttX has been proposed for deletion because of the following concern: Promotional article While all constructive contributions to Wiki
Expose net_driver_s tx buffer status to implement POLLOUT
Hi, For SocketCAN I would like to implement the POLLOUT functionality. However this means I've to query the driver check if the internal TX buffer is full. My first thought would be extending struct net_driver_s with the following callback int (*d_txfull)(FAR struct net_driver_s *dev); Would this make sense or is there a better way to query the driver from network stack? Kind regards Peter van der Perk
Re: LCD Framebuffer putarea and display redraw
Hi Excerpts from Alan Carvalho de Assis's message of July 20, 2022 5:21 pm: > Hi Karel, > > On 7/20/22, Karel Kočí wrote: >> Hi >> >> I discovered that commit 664d45dcbace03a879017aa99566592be31f4308 broke LCD >> >> framebuffer (at least for ST7789). The issue is with `putarea` call. >> Originally >> it was called only when full display redraw was requested but now it is >> called >> every time when defined. The core of the issue is that from documentation >> the >> buffer passed to the putarea should contain pixels for that area but LCD >> framebuffer always passes the complete buffer. >> > > Analyzing logically the expected behavior, now putarea() is now called > correctly, so the modification that the guy did on PR #6551 is good. > In the past when you was wanting to update only an area of the LCD > there existed an updatearea() function inside each LCD drivers that > was called. > > If you enable CONFIG_NX_UPDATE you will see that > graphics/nxbe/nxbe_notify_rectangle.c still expecting that > updatearea() inside the lcd_dev_s (I discovered it yesterday and I'm > trying to fix it). > > That function was transfered to lcd_framebuffer.c but we you noticed > it was calling putarea() only to redraw all the display, that is > obviously incorrect. In the other hand, putrun() is a raster function > that normally update the LCD line by line (it could be any row or > column, but not an area like putarea). > > Yesterday I sent the PR #6639 that uses the putarea() to rendering of > APA102 because it was using putrun() and I could see the image be > rendered in the screen because APA102 requires me to send the bit > stream sequentially for all the LEDs in the matrix. > > Now it is very fast as you can see here: > > https://www.youtube.com/watch?v=qA-UmD8ujlE > >> I see two possible fixes. Either we call putarea only when full display >> update >> is requested or we change the definition of the putarea in such a way that >> it is >> driver's resposibility to pick the are from buffer. The first solution is >> simple >> and is pretty much revert to the previous state. The second change is kind >> of >> what is suggested in the new comment added in >> 664d45dcbace03a879017aa99566592be31f4308 but no work was done to propagate >> that >> to actuall API documentation in 'include/nuttx/lcd/lcd.h' . >> >> Thus, what do you think? Revert or propagation of the new behavior? >> > > Although the first solution is simpler it is incorrect (that is the > way it was doing before), putarea exist to update an area of the LCD > screen. I am not against the idea at all. It makes sense. > I think the right solution is to fix ST7789 to update only the > requested area received by putarea(). I am going to do that (at least for ST7789). I am also going to update documentation for LCD API. Honestly, the only ambiguity and the reason for my original mail and the need to actually debug this was that this comment was ignored https://github.com/apache/incubator-nuttx/pull/6551#discussion_r912844774 and changes were merged without updated documentation. It wasn't hard for me to locate the commit that broke it but it was hard to figure out what was the original idea of the committer as that was missing in the commit message. Going trough comments in PR is not exactly optimal even if I would not ignore PR all together. With regards Karel Kočí pgpYieK2nB_Jd.pgp Description: PGP signature
