Re: New Task Aware Debugger Available
Morning Alan, It runs on the MCU-Link board. Regards DAVE On 20/07/2021 11:32, Alan Carvalho de Assis wrote: Hi Steve, Nice work! I'm looking forward to test it. Is it possible to use it on MCU-Link existing on some NXP board? Like some board already supported by NuttX? BR, Alan
New Task Aware Debugger Available
Folks, Steve Woodford has just integrated NuttX task awareness into his Maven debugger. This initial version runs on the NXP MCU-Link, replacing the 'stock' firmware. Fortunately the MCULink is only about $10 and I'm sure it'll get ported to anything with a clock tick pretty quickly. There's a couple of READMEs in the archive which provide information about what it does and how it's been done (including a small NuttX patch to make it easier for debuggers to find the TCBfor discussion.) Steve has just joined the mailing list but hasn't introduced himself to you hairy lot yet...and clicking on links from newly signed up users is not something to do lightly, hence my posting this initial intro; https://www.maverick-embedded.co.uk/downloads/maven-mculink-0.5.tgz I'm sure he'll welcome comments and (limited) brickbats. Hopefully he'll be able to show it off at the NuttX Workshop. ...and for those of you _still_ waiting for Debug and Parallel Trace, a morsel to whet your appetites; https://cdn.discordapp.com/attachments/614885210395508738/863565020158754816/1625960319475.jpg Regards DAVE
CFP: WFIoT Industry Fora
oach the forum chairs informally for additional guidance if required. While it is highly desirable to not constrain the session topics, it is essential that they maintain relevance to the technical program, and this should be noted in the proposal. Proposals must be submitted electronically. See https://wfiot2021.iot.ieee.org/ for more information. Suggested Topics (not exhaustive) IoT over 5G/6G IoT for the New Normal Security and privacy in IoT systems Smart Cities and Smart Society Drone/V2X IoT Applications, Technologies and Challenges AI and Machine Learning Neuromorphic computing and its application to IoT Cloud and Fog/Edge Computing, Networking and Storage IoT Blockchain Security and Privacy Important Dates == Proposal Submission Deadline: 15th January 2021 Proposal Acceptance Notification: 15th February 2021 Slides and Presentation Material Submission: 31st May 2021 Contacts == Yoshihiro Ohba KIOXIA Corporation, Japan (yoshihiro.o...@kioxia.com) Dave Marples Technolution BV, The Netherlands (dave.marp...@technolution.eu)
Re: Color ANSI support in nsh
A more general solution would be handy but what is there really in the embedded world that doesn't support vt100? There more code there is, the more interesting ways it can go wrong :-) (BTW; ctrl-L to clear the screen was one of the first things I added after fixing backspace/deleteboth of those drove me crazy). Regards Dave On Mon, 17 Aug 2020, 15:51 Gregory Nutt, wrote: > > > I would suggest that you look at how this is handled in standard > terminals. This works in the form > > of escape sequence which give a code that the terminal can interpret as > being a color. This would > > make it available to applications in a standard form. > > Good point. The GNU part of GNU/Linux devotes a lot of logic into > managing terminals. Eg. > > https://www.gnu.org/software/termutils/manual/termcap-1.3/html_mono/termcap.html > and https://linux.die.net/man/5/terminfo and > https://pubs.opengroup.org/onlinepubs/007908799/xcurses/terminfo.html > and etc... > > NuttX generally just hard codes VT-100 terminal types (or the > almost-dentical ANSII terminal type). But there are lots of others. > Perhaps we should really be considering how we handle terminals in > general not just color on or off? That is really what the current > discussion is about, terminal capabilities (termcaps) and > customizations. Maybe, as a start, we should consider a > terminfo/termaps for monochrome vs. color only. That would be a step in > the Unix direction version yet-another-ad-hoc-config-setting. > > > >
Re: Color ANSI support in nsh
Guys, chill, it was a joke :-) of course colour has utility for improved cognition. Back in the day I remember discussions about if colour terminals would ever take off cos folks couldn't see the point of them. That argument got resolved. Colour certainly has utility. Small size does too. If we can accommodate both (KConfig) then everyone is a winner. Dave On Mon, 17 Aug 2020, 07:50 Maciej Wójcik, wrote: > I am confused a bit. Are you all guys talking about the same thing? If I > understand correctly Christian just wanted to introduce colors to NSH. > > Colours in the terminal are not about looking good. Colours improve > readability. The same text on the screen carries more information. This is > why everyone is using syntax highlighting in the editor when programming. > > It is easier to spot red error and yellow warning than just all black text > in terminal log. It would be great if there would be native option to > enable this, without pdcurses. > > > On Mon, 17 Aug 2020, 08:32 , wrote: > > > Please do not make technology about looks in functionality it has to > > work and be solid and has to address its purposes. If all is finished and > > value is there, one could bring a nice color too it 😉 Color is throwing > > money where functionality died > > > > Ben > > > > -Oorspronkelijk bericht- > > Van: Alan Carvalho de Assis > > Verzonden: zondag 16 augustus 2020 17:02 > > Aan: dev@nuttx.apache.org > > Onderwerp: Re: Color ANSI support in nsh > > > > Christian, > > > > If I'm not wrong NuttX already has this feature to fancy interface if you > > use of pdcurses library. > > > > Greg added pdcurses some time ago and Ken Petit added support to use it > > over telnet > > > > BR, > > > > Alan > > > > On 8/16/20, Christian Catchpole wrote: > > > Yeah i should have had a poke around before posting on the group. I > > > keep finding NuttX has so many features in the Kconfig :) I also > > > suggested command history then found my Spresence NSH has history, so > > > obviously i was not the first to think of it. > > > I don't want to go TOO crazy with ANSI colours. I'll experiment with a > > > few things and then loop back around and see what others think. > > > > > > Thanks, > > > Christian > > > > > > > > > On Sun, 16 Aug 2020 at 22:11, Dave Marples wrote: > > > > > >> Hiya, > > >> > > >> Yes, there's some cheesy simple stuff in there already (mainly to > > >> stop the zephyr folks throwing shade cos their terminal is prettier). > > >> At the moment it only highlights commands, responses and errors iirc, > > >> but making it more context aware would certainly be niceit's > > >> already switched on/off by kconfig option. > > >> > > >> Regards > > >> > > >> Dave > > >> > > >> On Sun, 16 Aug 2020, 12:24 David Sidrane, > > >> wrote: > > >> > > >> > Hi Christian, > > >> > > > >> > As long as there is a Knob in Kconfig to enable / disable each > > >> > feature (that defaults to disable) the impact is 0. > > >> > > > >> > IIRC there is a history, and some fancy-ness that was added by Dave > > >> > a > > >> while > > >> > ago. Good docs and an example defconfig would will keep it > > >> > maintained > > >> (and > > >> > built). Once we have scripted test running against the sim (or real > > >> > HW) test cases will keep it from breaking. > > >> > > > >> > David > > >> > > > >> > -Original Message- > > >> > From: Christian Catchpole [mailto:christ...@catchpole.net] > > >> > Sent: Saturday, August 15, 2020 5:52 PM > > >> > To: dev@nuttx.apache.org > > >> > Subject: Color ANSI support in nsh > > >> > > > >> > Hi everyone, > > >> > > > >> > I have been adding ANSI escape codes for colour support to my app’s > > >> console > > >> > output and have been experimenting with adding it to nsh itself. At > > >> > a minimum to colour the prompt. > > >> > > > >> > I had been thinking this is something i could develop and propose > > >> > to come back into the mainline as a nsh kconfig option. > > >> > > > >> > But before i do, the obvious question is, has this been proposed > > >> > before > > >> and > > >> > are there reasons we wouldn’t want this in NuttX? > > >> > > > >> > I’m also thinking it would be good to have a single line of command > > >> > history. Other configurable options could be clear screen on nsh > > >> > entry (I added this as my app was using ANSI line positioning and > > >> > resets back into nsh looked messy). There are all sorts of fun > > >> > things which could be done with ANSI terminal emulation. > > >> > > > >> > Thanks, > > >> > See you all tonight. Where you’ll see my demo going crazy with ANSI > > >> colour > > >> > codes. > > >> > > > >> > Christian > > >> > > > >> > > > > > > > >
Re: Color ANSI support in nsh
Hiya, Yes, there's some cheesy simple stuff in there already (mainly to stop the zephyr folks throwing shade cos their terminal is prettier). At the moment it only highlights commands, responses and errors iirc, but making it more context aware would certainly be niceit's already switched on/off by kconfig option. Regards Dave On Sun, 16 Aug 2020, 12:24 David Sidrane, wrote: > Hi Christian, > > As long as there is a Knob in Kconfig to enable / disable each feature > (that > defaults to disable) the impact is 0. > > IIRC there is a history, and some fancy-ness that was added by Dave a while > ago. Good docs and an example defconfig would will keep it maintained (and > built). Once we have scripted test running against the sim (or real HW) > test > cases will keep it from breaking. > > David > > -Original Message- > From: Christian Catchpole [mailto:christ...@catchpole.net] > Sent: Saturday, August 15, 2020 5:52 PM > To: dev@nuttx.apache.org > Subject: Color ANSI support in nsh > > Hi everyone, > > I have been adding ANSI escape codes for colour support to my app’s console > output and have been experimenting with adding it to nsh itself. At a > minimum to colour the prompt. > > I had been thinking this is something i could develop and propose to come > back into the mainline as a nsh kconfig option. > > But before i do, the obvious question is, has this been proposed before and > are there reasons we wouldn’t want this in NuttX? > > I’m also thinking it would be good to have a single line of command > history. Other configurable options could be clear screen on nsh entry (I > added this as my app was using ANSI line positioning and resets back into > nsh looked messy). There are all sorts of fun things which could be done > with ANSI terminal emulation. > > Thanks, > See you all tonight. Where you’ll see my demo going crazy with ANSI colour > codes. > > Christian >
Re: lpc54xx: Debugging I2C and wm8904
Andrei, Might be a red herring but take a look at the i2c module for mimxrtthere were changes applied there recently for similar issues. It could well be that the modules have common heritage and so have the same bugs...not at my desk otherwise I'd have a look myself. Regards Dave On Sun, 23 Feb 2020, 12:57 Andrei Stefanescu, wrote: > Hi, > > I am planning to use the wm8904 codec(found on the lpcxpresso54628 board) > with Nuttx. > > I have the following problem: during the initial I2C setup of the wm8904, > when trying to write to the 0x21 register, there is an indefinite stretch > for the slave ACK. I attached the screenshots from the oscilloscope. The > first one is with the start sequence which seems ok and the second one > shows the failure. The 9th bit, the one for the slave ACK, stretches > indefinitely. The SDA line seems to go up a bit, so I'm guessing that > WM8904 does something. I don't understand why SCL doesn't go low. The I2C > module reports a Start/Stop error and then goes to the idle state. > > I also tried the FreeRTOS example and it seems to work. I modified that > example so that it would perform the same I2C writes and it still works. I > checked to see if there are any differences between the I2C module init and > I2C transfer function but I couldn't identify anything important. > > I also set up the MCLK and checked it with the oscilloscope and it is ok. > Note that I mainly tested with I2C_POLLED but the problem seems to also > appear on interrupt based transfers. > > Also, something that is bothering is that the behavior is a bit flaky. At > first time it will fail to write reg 0x21, after a reset(SW1 button) it > will fail to read the wm8904 id and after another reset it will again fail > to write 0x21 and so on. > > Do you have any ideas or suggestions? Have you seen this behavior before? > > I also attached a patch for I2C, the I2C stop command wouldn't be sent for > a write message. > > Best regards, > Andrei Stefanescu >
Generic SPI interface to LCD
pio(GPIO_LPSPI3_DC);
+#endif
/* Set up default configuration: Master, 8-bit, etc. */
@@ -1632,13 +1680,20 @@ FAR struct spi_dev_s *imxrt_lpspibus_initialize(int bus)
/* Only configure if the bus is not already configured */
- if ((imxrt_lpspi_getreg32(priv, IMXRT_LPSPI_CR_OFFSET) & LPSPI_CR_MEN)
== 0)
+ if ((imxrt_lpspi_getreg32(priv, IMXRT_LPSPI_CR_OFFSET)
+ & LPSPI_CR_MEN) == 0)
{
/* Configure SPI4 pins: SCK, MISO, and MOSI */
imxrt_config_gpio(GPIO_LPSPI4_SCK);
imxrt_config_gpio(GPIO_LPSPI4_MISO);
imxrt_config_gpio(GPIO_LPSPI4_MOSI);
+#ifdef GPIO_LPSPI4_CS
+ imxrt_config_gpio(GPIO_LPSPI4_CS);
+#endif
+#if defined(GPIO_LPSPI4_DC) && defined(CONFIG_SPI_CMDDATA)
+ imxrt_config_gpio(GPIO_LPSPI4_DC);
+#endif
/* Set up default configuration: Master, 8-bit, etc. */
diff --git a/drivers/lcd/Kconfig b/drivers/lcd/Kconfig
index 9bc3ac284b..88a9f5a4d5 100644
--- a/drivers/lcd/Kconfig
+++ b/drivers/lcd/Kconfig
@@ -1134,6 +1134,23 @@ config LCD_ILI9341_IFACE1_RGB565
endchoice
endif
+config LCD_LCDDRV_SPIIF
+ bool "Generic SPI Interface Driver (for ILI9341 or others)"
+ default n
+ depends on LCD_ILI9341
+ ---help---
+ SPI Interface shim to allow LCD and ePaper to be bound to
+ a normal SPI port.
+
+config LCD_LCDDRV_SPEED
+int "Generic SPI Interface speed"
+ default 1000
+ depends on LCD_LCDDRV_SPIIF
+ ---help---
+ SPI Interface speed. According to the specification this is
generally
+ quite limited, but people have had success with much faster
+ speeds than the spec sheets say. YMMV.
+
config LCD_RA8875
bool "RA8875 LCD Display Controller"
default n
diff --git a/drivers/lcd/Make.defs b/drivers/lcd/Make.defs
index bfc50baed8..b40aca2b33 100644
--- a/drivers/lcd/Make.defs
+++ b/drivers/lcd/Make.defs
@@ -124,6 +124,10 @@ ifeq ($(CONFIG_LCD_ILI9341),y)
CSRCS += ili9341.c
endif
+ifeq ($(CONFIG_LCD_LCDDRV_SPIIF),y)
+ CSRCS += lcddrv_spiif.c
+endif
+
ifeq ($(CONFIG_LCD_RA8875),y)
CSRCS += ra8875.c
endif
diff --git a/drivers/lcd/lcddrv_spiif.c b/drivers/lcd/lcddrv_spiif.c
new file mode 100644
index 00..0f60caa828
--- /dev/null
+++ b/drivers/lcd/lcddrv_spiif.c
@@ -0,0 +1,349 @@
+/
+ * drivers/lcd/lcddrv_spiif.c
+ *
+ * Generic Driver interface for the Single Chip LCD driver connected
+ * via spi driver
+ *
+ * Copyright (C) 2019 Greg Nutt. All rights reserved.
+ * Author: Dave Marples
+ * Based on work from Marco Krahl
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in
+ *the documentation and/or other materials provided with the
+ *distribution.
+ * 3. Neither the name NuttX nor the names of its contributors may be
+ *used to endorse or promote products derived from this software
+ *without specific prior writen permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+ * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
+ * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
+ * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
+ * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
+ * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ *
+ /
+
+/
+ * Included Files
+ /
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+/
+ * Pre-processor Definitions
+ /
+
+/
+
Re: Sending .patch
On 28/01/2020 00:11, Alan Carvalho de Assis wrote: Hi Dave, The issue is because GMail and some email servers/clients will convert the patch to octet-stream, please see the discussion here: https://issues.apache.org/jira/browse/INFRA-19691 BR, Alan Yes, I saw that, but a patch probably should be an octet-stream since we can't be certain what character set it's sent in. Does that mean this is a 'won't fix'? Regards DAVE
Re: Sending .patch
Our workflow document already instructs users to send their patches with a .txt extension because of this issue. I just noticed that the git command given there doesn't correspond to that. I will fix that when I get to my computer soon. (I use 'git format-patch master --stdout > your_file_name_here.txt'; I don't know if there's another way that requires less typing.) That's all we can do on our end. It would take an act of Infra to change that. Nathan Probably not a good idea to walk back in the door and start moaning, but why is that a problem? If it's wrong, then it's wrong...otherwise it's one more little foible people have to know about to be able to work with us. Regards DAVE
Re: Sending .patch
On 10/01/2020 09:58, Alan Carvalho de Assis wrote: Hi Everyone, As told I opened an Infra ticket to fix sending .patch to dev@ list. That was the response I received: " [ https://issues.apache.org/jira/browse/INFRA-19691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17012638#comment-17012638 ] Sebb commented on INFRA-19691: -- The content-type will depend on the mail client. I just tried with GMail, and it sent the file test.txt as Content-Type: text/plain; charset="US-ASCII"; name="test.txt" whereas test.patch resulted in: Content-Type: application/octet-stream; name="test.patch" == However, it's usually not ideal to send patches to mailing lists. Better to use an issue tracking system." Then he just Closed the ticket with the resolution: Information Provided BR, Alan So, will this be fixed or not? Tools are there to support users and throwing away patches because the tools are sulky doesn't sound like very support-y to me? Regards DAVE
Re: Imxrt 1050
On 07/01/2020 13:42, Embedded Systems wrote: Hello, I found what is cousin that behaviour it is the WFI instruction in the idle task. Please excuse me for bothering you. Ivan, This does not happen when programming imxrt in other environments (e.g. Zephyr, FreeRTOS) and is a concern to me since it implies there's a clock not switched on properly somewhere. We had this problem with the tick timer not interrupting when WFI was first (re-)enabled but that one was fixed. Chances are there's another bit hidden in one of the GPR registers controlling this. I'm back now so will investigate...just 2000 emails to catch up with first. Regards DAVE
Re: ILI9341 port to STM32F4
Ben, I have this up and running on an imxrt with a 'generic' spi driver (i.e.that should work with any spi device rather than the platform specific one that was previously in use). When I'm back at my desk this evening I'll send the files to you so you can compare and contrast to make something suitable for inclusion based on what you've already got. Regards Dave On Wed, 1 Jan 2020, 18:39 Gregory Nutt, wrote: > > > Disabling the colormap config (CONFIG_STM32_FB_CMAP) it gives a white > > screen (no text "Hello World"), but no hardfault... and if I start > nxhello > > for the second time I get: > > stm32_spi2select: devid: 262144 CS: assert > White is probably better. That just means that the data sent to the LCD > is bad (all ones?) but the backlight is on. > > ili9341_getplaneinfo: planeno: 0 bpp: 16 > bpp=16, certainly you are not using a colormap. > > * and if I start nxhello for the second time I get: * > > The example probably does not disconnect from NX. If it did disconnt, > the screen should go black you would see nothing. I think all of the > other nxhello examples run standalone (not sure). > > >
Re: nxgl Redrawing
If it is not too device specific, I can put it on a branch and we can haggle through the details before merging it to master. I think your original proposal for nx_updatedisplay() would be okay if it were renamed and took three arguments like: int nx_synch(NXWINDOW hwnd, int cmd, unsigned long arg) it would be prototyped in include/nuttx/nx/nx.h and there would probably need to be a new include/nuttx/nx/nx_ioctl.h to hold IOCTL commands and structures. These are things I can help with. Greg Yes, I already did some name changes because they were too close to already used terms. Let me build this strawman and then we've got something to work from. Regards DAVE
Re: nxgl Redrawing
Linux uses Xorg for graphics. So if this feature is supported in Linux, then I think it would be through Xorg? The NX server is the tiny, moral equivalent of the XServer. This is interesting: https://hackaday.com/2018/08/14/run-a-linux-terminal-on-cheap-e-ink-displays/ The interface is written in Python: https://github.com/joukos/PaperTTY but I don't really see anything of interest. I see a lot of references to "deferred IO" with ePaper devices. AFAIK deferred IO is basically what drivers/lcd/lcd_framebuffer.c does: If buffers all writes to the device in a framebuffer. You could then force the framebuffer dump to hardware using the FBIO_UPDATE ioctl in drivers/video/fb.c Sorry... a half hour of Googling did not answer the question for me. I'm not aware of any 'standard' interfaces. Most of the code I've seen is hackup bits and pieces, but there's no way I'm going to build a whole parallel ecosystem when we've got all the juicy stuff to hand...provided we don't break anything to use it! For interest, you can see the sort of modules I'm using at https://www.buydisplay.com/default/e-paper-display-module-e-ink-display-kit-manufacturers/2-7-inch So, I think the path here is that I'll tidy up what I've done and then I'll submit it for comment and kickabout, and see where we go from there. Regards DAVE
Re: nxgl Redrawing
How are other operating systems / graphics libraries handling this? From what I've seen they mostly don't...you end up with a parallel graphics subsystem built on top of an SPI. We can do better than that, given that very little needs to be extended. Regards DAVE
Re: nxgl Redrawing
Hi Greg, Thanks for the replies. Comments embedded; What is the interface to the ePaper device? Is it through a serial interface? Or a framebuffer interface? The interface is over SPI. It 'looks like' a normal lcd supported by lcd_dev_s. The particular one I have is write-only, but read/write ones exist too. What do you might by NXGL? It is library of simply drawing helpers. I take it you are not using NX, the full graphics system. It would update automatically and we would not be having this discussion. It's worth explaining a little bit more about how these devices work, then it'll be clearer, I hope. They have a display RAM just like an SPI or I2C interfaced LCD does. You write to it in the same way using similar commands. The difference is that the display RAM _does _not_ automatically get transferred onto the screen. That has to be done by a separate operation which, depending on the device in question, can take up to 15 seconds or so. NXGL offers a nice set of drawing primitives which remain applicable to these displays. There is no difference to NXGL or the way that it is used, and no code in NXGL is changed to allow it to work with ePaper. Unfortunately, nothing changes on the screen until the send-to-screen (redraw) command is issued. Since you are redrawing something that was not drawn by NX, it must be something that you drew in your application? True? Are you using a software framebuffer? It was drawn by NX, it just didn't make it to the screen yet. The correct way to implement a software framebuffer driver for a serial graphics device is via drivers/lcd/lcd_framebuffer.c. That driver will allocate the software framebuffer and export a standard NuttX framebuffer driver interface. The framebuffer driver at drivers/video/fb.c will expose the framebuffer driver to the application. From the framebuffer driver you can use the FIOC_MMAP IOCTL command to get the address of the framebuffer. You would need enable CONFIG_LCD_UPDATE, then you can use FBIO_UPDATE command to force the software software framebuffer to be written to the serial hardware. A framebuffer isn't needed, as there is already one on the device. However, what I need to do is directly equivalent to FBIO_UPDATE. Normally FBIO_UPDATE works from NuttX RAM to the LCD (and automatically onto the display), I want to go from the ePaper RAM to the display. Using the framebuffer wouldn't help me as I'd still need to perform the redraw operation to get the stuff onto the actual display after sending the FBIO_UPDATE. Now, that sounds like you are using NX. NX will automatically update the display. I cannot imagine a situation where that would be necessary. Let's talk more before you waste your time. I would have to understand what you are really doing to be able to help you. NX _thinks_ it's updated the display and indeed, in the normal scheme of things (with an LCD), it would have. Unfortunately, for this class of displays, this second step to sync the display ram to the display itself is needed. I've just read through the other notes you've sent. To avoid fragmenting my reply; *) It's an ePaper electrophoretic display which is bi-stable - whatever is on the display will stay there, even without power. That means transferring the contents of the display frame memory to the display is a second step operation which takes a while to happen. *) I can use nxgl to write to it no problem. As far as nxgl is concerned it looks just like an ILI9341 or similar (different command set, but the same principles). The problem is that what is written to it does not end up on the display until a separate, time consuming, redraw command is issued. While the redraw is going on the display is away with the faries and will not communicate at all. That isn't a problem for us as new drawing commands will just back up in the NXGL MQ until it becomes available again. *) There is no modification needed to any existing nxgl or other code for this to work...it's a simple extension to add this redraw command...but I need to be comfortable that I've put it in the right place, hence why I'm asking for input. It means that some practical details of the implementation of the display technology are 'leaking' up into the graphics abstraction, but I don't really see a way to avoid it. Only the application knows when it's permissible to take an extended time to perform an update. Regards DAVE
Re: nxgl Redrawing
Hmm...going further, the only way I see to deal with this at the nxgl layer above the lcd structure itself is to add a nx_redraw with corresponding NX_EVENT_REDRAWING/NXEVENT_REDRAWN event callbacks, but that makes the nxgl layer device-aware...I don't see how it can't be really, these things are pretty different to traditional LCDs. For the case of the lcd nx_updatedisplay member not being present I would just return the NXEVENT_REDRAWN immediately so everything would remain back-compatible. I don't really see any way to avoid this. Greg, any suggestions for a better approach? Regards DAVE On 17/12/2019 10:56, Dave Marples wrote: Folks, I've implemented an ePaper driver under nxgl, but as some of you are probably aware there needs to be an explicit redraw request to update an ePaper display. I'm not quite sure how to do that under nxgl as normally it would be driven automatically. It also takes a fair bit of time (~14 seconds for a colour display) during which period access to the ePaper is 'locked out' so the application really does need to be aware of what is going on. My intention is to add an nx_updatedisplay() API...but is there a better, or already available, way to do this? It could be done via a call to nx_setvisibility on the background window I guess, but personally I don't like overlaid semantics like that... Regards DAVE
Re: nxgl Redrawing
Hi Alan,
I'm no expert on this stuff either but as I understand things the
nx_callback/redraw, is for when nx requests that the client redraws a
portion of the screen (See 2.3.4.1 of the NX Graphics Subsystem manual).
I want to go the other way - when the application has decided that a new
display is 'stable', it requests for it to be put on the screen.
I don't really see how to do that in a standard way yet, so I've added a
new method to lcd.c::struct lcd_dev_s called 'redraw', but I don't want
to be making extensions to APIs without there being some element of
discussion first...
Regards
DAVE
On 17/12/2019 11:34, Alan Carvalho de Assis wrote:
Hi Dave,
On 12/17/19, Dave Marples wrote:
Folks,
I've implemented an ePaper driver under nxgl, but as some of you are
probably aware there needs to be an explicit redraw request to update an
ePaper display.
Other guy already used ePaper with NX Graphic libs, if I'm not wrong
it was Petteri Aimonen.
He also used NuttX nxgl in his Master Thesis:
http://jpa.kapsi.fi/stuff/other/diplomityo.pdf
I'm not quite sure how to do that under nxgl as normally it would be
driven automatically. It also takes a fair bit of time (~14 seconds for
a colour display) during which period access to the ePaper is 'locked
out' so the application really does need to be aware of what is going on.
My intention is to add an nx_updatedisplay() API...but is there a
better, or already available, way to do this? It could be done via a
call to nx_setvisibility on the background window I guess, but
personally I don't like overlaid semantics like that...
I'm not expert on graphics, but I think you can use the redraw in the
nx_callback to do it.
Please take a look at apps/examples/nxlines, mainly on it:
const struct nx_callback_s g_nxlinescb =
{
nxlines_redraw, /* redraw */
...
BR,
Alan
nxgl Redrawing
Folks, I've implemented an ePaper driver under nxgl, but as some of you are probably aware there needs to be an explicit redraw request to update an ePaper display. I'm not quite sure how to do that under nxgl as normally it would be driven automatically. It also takes a fair bit of time (~14 seconds for a colour display) during which period access to the ePaper is 'locked out' so the application really does need to be aware of what is going on. My intention is to add an nx_updatedisplay() API...but is there a better, or already available, way to do this? It could be done via a call to nx_setvisibility on the background window I guess, but personally I don't like overlaid semantics like that... Regards DAVE
