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
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.
2021
Contacts
==
Yoshihiro Ohba KIOXIA Corporation, Japan
(yoshihiro.o...@kioxia.com)
Dave Marples Technolution BV, The Netherlands (dave.marp...@technolution.eu)
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
g 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
&g
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
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,
..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
+ *
+ * Cop
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
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 >
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:
" [
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
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
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
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
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
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
?
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
...
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
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
20 matches
Mail list logo
