Discussion:
compiling sim/nx
(too old to reply)
t_fahmy_bassem
2011-02-23 19:00:03 UTC
Permalink
Hi,
First i really apologize as i'm floading the forum with my questions. I'm trying nuttx for a new project so i'm trying to test every thing.

i'm now compiling for the simulator for nx. when i compiled i get an error:

up_framebuffer.c:145: error: `FB_FMT_RGB8' undeclared here (not in a function)

i searched and found that in case of CONFIG_SIM_FBBPP = 8, then FB_FMT equal FB_FMT_RGB8 which is not defined in fb.h
there is another definition FB_FMT_RGB8_32
#define FB_FMT_RGB1 3 /* BPP=1 */
#define FB_FMT_RGB4 4 /* BPP=4 */
#define FB_FMT_RGB8_332 5 /* BPP=8 */
#define FB_FMT_RGB12_444 6 /* BPP=12 */
#define FB_FMT_RGB16_555 7 /* BPP=16 R=5, G=5, B=5 (1 unused bit) */
#define FB_FMT_RGB16_565 8 /* BPP=16 R=6, G=6, B=5 */
#define FB_FMT_RGB24 9 /* BPP=24 */
#define FB_FMT_RGB32 10 /* BPP=32 */

I tried changing the CONFIG_SIM_FBBPP to 4. it compiled but there was an error in playing saying that BPP = 4 is not supported.

so can any body tell what is wrong?

Regards
Bassem
Gregory N
2011-02-23 20:23:59 UTC
Permalink
Post by t_fahmy_bassem
up_framebuffer.c:145: error: `FB_FMT_RGB8' undeclared here (not in a function)
Yep, looks like I accidently wiped out the FB_FMT_RGB8 (pallette) definition when I meant to add the FB_FMT_RGB8_332 (for the Nokia 6100) a couple of months ago. Looks like it also breaks the DM320 build.
Post by t_fahmy_bassem
I tried changing the CONFIG_SIM_FBBPP to 4. it compiled but there was an error in playing saying that BPP = 4 is not supported.
You would also need to changes these in the .config file:

CONFIG_NX_DISABLE_1BPP=y
CONFIG_NX_DISABLE_2BPP=y
CONFIG_NX_DISABLE_4BPP=y <-- CHANGE to n
CONFIG_NX_DISABLE_8BPP=n
CONFIG_NX_DISABLE_16BPP=y
CONFIG_NX_DISABLE_24BPP=y
CONFIG_NX_DISABLE_32BPP=y

Note.. You will be disappointed. The basic configs/sim/nx example does nothing visible. The driver is just a stub. There is an X11 version that can be configured that actually shows an X11 window. See configs/sim/README.txt. But that version only compiles on old Linux installations because it depends on old X11 header files being in certain places.

Greg
Bassem Fahmy
2011-02-23 21:26:14 UTC
Permalink
Hi Greg,
Thank you for the tip. I really appreciate your help. One thing come to my notice that some features that were originally working may later be broken during next releases while doing other fixes. I was wondering is there a set of regression tests that you do before doing a release.
An idea that crossed my mind is to ask for volunteers for testing the trunk before the release. so for example i can test the simulator and later when i start the lpc1766 i can test the Olimex port of this platform and so on.

I'm not sure how do they do it in the linux kernel. may be we can do like what they do.

Regards,
Bassem

To: nuttx-***@public.gmane.org
From: spudarnia-/***@public.gmane.org
Date: Wed, 23 Feb 2011 20:23:59 +0000
Subject: [nuttx] Re: compiling sim/nx
Post by t_fahmy_bassem
up_framebuffer.c:145: error: `FB_FMT_RGB8' undeclared here (not in a function)
Yep, looks like I accidently wiped out the FB_FMT_RGB8 (pallette) definition when I meant to add the FB_FMT_RGB8_332 (for the Nokia 6100) a couple of months ago. Looks like it also breaks the DM320 build.
Post by t_fahmy_bassem
I tried changing the CONFIG_SIM_FBBPP to 4. it compiled but there was an error in playing saying that BPP = 4 is not supported.
You would also need to changes these in the .config file:



CONFIG_NX_DISABLE_1BPP=y

CONFIG_NX_DISABLE_2BPP=y

CONFIG_NX_DISABLE_4BPP=y <-- CHANGE to n

CONFIG_NX_DISABLE_8BPP=n

CONFIG_NX_DISABLE_16BPP=y

CONFIG_NX_DISABLE_24BPP=y

CONFIG_NX_DISABLE_32BPP=y



Note.. You will be disappointed. The basic configs/sim/nx example does nothing visible. The driver is just a stub. There is an X11 version that can be configured that actually shows an X11 window. See configs/sim/README.txt. But that version only compiles on old Linux installations because it depends on old X11 header files being in certain places.



Greg
Gregory N
2011-02-23 21:40:22 UTC
Permalink
Post by Bassem Fahmy
Thank you for the tip. I really appreciate your help. One thing come to my notice that some features that were originally working may later be broken during next releases while doing other fixes. I was wondering is there a set of regression tests that you do before doing a release.
An idea that crossed my mind is to ask for volunteers for testing the trunk before the release. so for example i can test the simulator and later when i start the lpc1766 i can test the Olimex port of this platform and so on.
Regression testing is big problem. There are a lot of different configurations, many different boards, and many different toolchains. I am careful, but over time things can become broken if they are not re-built and re-tested. I think it would be great if anyone could help out. Many people contribute software, but I am the only person working consistently on the project and the effort is really more than one person can do right.

I can think of lots of ways people could contribute. Contributing code and testing, or course, is a great help. But there are many other things that could be helpful to -- reviewing updating documents, translating documents, improved build system, configuration tools, a more professional website, etc. etc.

I'm open to any good ideas for more community participation.
Post by Bassem Fahmy
I'm not sure how do they do it in the linux kernel. may be we can do like what they do.
I think in Linux, there are many "owners" of different ports and subsystems. I think those owners take responsibility for the correctness of their subsystems at the time of each release.

Greg
Gregg Levine
2011-02-23 22:27:49 UTC
Permalink
Post by t_fahmy_bassem
up_framebuffer.c:145: error: `FB_FMT_RGB8' undeclared here (not in a function)
Yep, looks like I accidently wiped out the FB_FMT_RGB8 (pallette) definition when I meant to add the FB_FMT_RGB8_332 (for the Nokia 6100) a couple of months ago.  Looks like it also breaks the DM320 build.
Post by t_fahmy_bassem
I tried changing the CONFIG_SIM_FBBPP to 4. it compiled but there was an error in playing saying that BPP = 4 is not supported.
CONFIG_NX_DISABLE_1BPP=y
CONFIG_NX_DISABLE_2BPP=y
CONFIG_NX_DISABLE_4BPP=y <-- CHANGE to n
CONFIG_NX_DISABLE_8BPP=n
CONFIG_NX_DISABLE_16BPP=y
CONFIG_NX_DISABLE_24BPP=y
CONFIG_NX_DISABLE_32BPP=y
Note.. You will be disappointed.  The basic configs/sim/nx example does nothing visible.  The driver is just a stub.  There is an X11 version that can be configured that actually shows an X11 window.  See configs/sim/README.txt.  But that version only compiles on old Linux installations because it depends on old X11 header files being in certain places.
Greg
------------------------------------
Hello!
Are we discussing the LCD display that Sparkfun sells both with and
without a breakout board? According to them it (the display) gets used
on a lot of things, including Olimex boards. I have one here, big
problem lays with making it work for me for my purposes. Its a 3.3v
input display which is a a big nuisance because my shop (if it can be
called that) is a 5v one.

-----
Gregg C Levine gregg.drwho8-***@public.gmane.org
"This signature fought the Time Wars, time and again."
Gregory N
2011-02-23 22:36:03 UTC
Permalink
Post by Gregg Levine
Yep, looks like I accidently wiped out the FB_FMT_RGB8 (pallette) definition when I meant to add the FB_FMT_RGB8_332 (for the Nokia 6100) a couple of months ago.  Looks like it also breaks the DM320 build.
Are we discussing the LCD display that Sparkfun sells both with and
without a breakout board? According to them it (the display) gets used
on a lot of things, including Olimex boards. I have one here, big
problem lays with making it work for me for my purposes. Its a 3.3v
input display which is a a big nuisance because my shop (if it can be
called that) is a 5v one.
Yes.. that would be the one. There have been a couple of threads here the past couple of days that the Nokia 6100 display has come up. It is on the Olimex LPC1766STK board that I use. I wrote a driver for it (breaking some other things), but never really got it fully working.

It needs 9-bits of data per transfer. That is pretty easy if you use 8-bit SPI and a GPIO output for the 9th bit, but the Olimex board uses real 9-bit SPI which is pretty tricky.

Greg

Continue reading on narkive:
Loading...