headers
Andy Jackson | 1 May 2006 16:21
Picon

Re: configtool development

Hi,

Apologies for the late response. Patches to enable Configtool compilation 
with wxWidgets 2.6.x can be found at our web site:

http://www.xylanta.com

in the Downloads section. My build environment is Cygwin, so your mileage 
may vary, however if they prove stable, then I will submit them for 
inclusion in the repository.

Kind regards,

    Andy..

----- Original Message ----- 
From: "Lars Poeschel" <larsi <at> wh2.tu-dresden.de>
To: <ecos-devel <at> ecos.sourceware.org>
Sent: Friday, April 14, 2006 6:47 PM
Subject: configtool development

> Hello!
>
> I am working on ecos for a study project. Therefore I'd like to build the 
> gui
> configtool from source. I failed on my Linux Debian Testing System.
> I found some problems with the Makefile in
> ecos/host/tools/configtool/standalone/wxwin. I also noticed issues with
> UNICODE and compatibilty with the recent wxWidgets 2.6.3.
> In the next days I will try to fix this to have configtool build correctly
(Continue reading)

Permalink | Reply | 4 comments |
headers
Andrew Lunn | 1 May 2006 18:15
Picon

Re: configtool development

On Mon, May 01, 2006 at 03:21:20PM +0100, Andy Jackson wrote:
> Hi,
> 
> Apologies for the late response. Patches to enable Configtool compilation 
> with wxWidgets 2.6.x can be found at our web site:
> 
> http://www.xylanta.com
> 
> in the Downloads section. My build environment is Cygwin, so your mileage 
> may vary, however if they prove stable, then I will submit them for 
> inclusion in the repository.

Hi Andy

Thanks for the pointer to the patch. Unfortunetly, it will not compile
on my Linux system.

c++ -O2 -c -I/usr/include/tcl8.4/ -I/opt/ecos//include
-I/home/lunn/eCos/anoncvs-clean/host//tools/configtool/common/common
-I/home/lunn/eCos/anoncvs-clean/host//tools/Utils/common
-I/home/lunn/eCos/anoncvs-clean/host//tools/ecostest/common -DecUSE_EXPERIMENTAL_CODE=1
`/usr/bin/wx-config --cppflags` -o /home/lunn/eCos/build/aboutdlg.o /home/lunn/eCos/anoncvs-clean/host//tools/configtool/standalone/wxwin/aboutdlg.cpp
/home/lunn/eCos/anoncvs-clean/host//tools/Utils/common/Collections.h: In member function 'bool
String::operator==(const char*) const':
/home/lunn/eCos/anoncvs-clean/host//tools/Utils/common/Collections.h:88: error: no matching
function for call to 'String::compare(const char* const&) const'
/usr/lib/gcc/i486-linux-gnu/4.0.4/../../../../include/c++/4.0.4/bits/basic_string.h:1919:
note: candidates are: int std::basic_string<_CharT, _Traits, _Alloc>::compare(const
std::basic_string<_CharT, _Traits, _Alloc>&) const [with _CharT = wchar_t, _Traits =
std::char_traits<wchar_t>, _Alloc = std::allocator<wchar_t>]
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Dallaway | 2 May 2006 10:56
Favicon

Re: configtool development

Hi Andy

Andy Jackson wrote:

> Apologies for the late response. Patches to enable Configtool
> compilation with wxWidgets 2.6.x can be found at our web site:
> 
> http://www.xylanta.com
> 
> in the Downloads section. My build environment is Cygwin, so your
> mileage may vary, however if they prove stable, then I will submit them
> for inclusion in the repository.

Thank you for the pointer to your configtool patches. I will review
these shortly. The patch for building against wxWidgets 2.6.x is
particularly welcome...

John Dallaway
eCosCentric Limited
Permalink | Reply | 2 comments |
headers
llandre | 5 May 2006 12:12
Picon

Running Microwindows on monochrome/grayscale LCD

Hi all,

I have to write a couple of Microwindows screen drivers for monochrome 
and 4-bpp greyscale LCD panels. As reference I'm looking at 
src/drivers/scr_ecos.c but this supports color mode only (RGB 555 and 
RGB 565) and, for istance, I can't understand which pixel format I have 
to use (MWPF_PIXELVAL, MWPF_PALETTE ...) and if rmask, gmask and bmask 
have to be handled.
I'd like to find a driver supporting monochrome or grayscale panels to 
use it as starting point. Anybody can provide such an example? Any hint 
or advice will be appreciated, too.

Thanks a lot in advance,
llandre

DAVE Electronics System House - R&D Department
web:   http://www.dave-tech.it
email: r&d2 <at> dave-tech.it
Permalink | Reply | 0 comments |
headers
llandre | 5 May 2006 15:21
Picon

Re: Running Microwindows on monochrome/grayscale LCD

Hi,

if I understand correctly you suggest to keep pixtype set to 
MWPF_TRUECOLOR555 (or MWPF_TRUECOLOR565) and to use only G component to 
paint the pixels, while R and B become just dummies. It it correct? What 
about bpp field?

> Hi
> You can try like this
> Make R,B value  equal to 0 , which will make G as display input for 
> monochrome display
> So Assign r,b=0 in the  code and try
> Thanks
> Sai
> */llandre <r&d2 <at> dave-tech.it>/* wrote:
> 
>     Hi all,
> 
>     I have to write a couple of Microwindows screen drivers for monochrome
>     and 4-bpp greyscale LCD panels. As reference I'm looking at
>     src/drivers/scr_ecos.c but this supports color mode only (RGB 555 and
>     RGB 565) and, for istance, I can't understand which pixel format I have
>     to use (MWPF_PIXELVAL, MWPF_PALETTE ...) and if rmask, gmask and bmask
>     have to be handled.
>     I'd like to find a driver supporting monochrome or grayscale panels to
>     use it as starting point. Anybody can provide such an example? Any hint
>     or advice will be appreciated, too.

--

-- 
llandre
(Continue reading)

Permalink | Reply | 0 comments |
headers
sumanth | 9 May 2006 15:15

How to clear status of interrupt in pic


Hi all,
          I am porting ecos to xscale  Ixp425 processor , the interrupt
status register of the ixp425 at address 0xC8003000 according to intel's
manual on reset should contain  0x0 but my board is containing 0x3FF080C0 ,
by this the processor is asserting interrupts even the interrupt has not
occured, and the code is looping between the isr and dsr.

How to clear the interrupt status register of the pic, it is read only,
I am using the axd debugger for debugging.
I have tried by reading the register contents, stil it does'nt clears.
How to solve the problem?

Thanks in advance

Regards,
Sumanth

--
View this message in context: http://www.nabble.com/How-to-clear-status-of-interrupt-in-pic-t1584415.html#a4299639
Sent from the Sourceware - ecos-devel forum at Nabble.com.
Permalink | Reply | 0 comments |
headers
Lars Poeschel | 10 May 2006 19:13
Picon

_TCHAR

Hello!

In ecos/host/tools/Utils/common/wcharunix.h
_TCHAR is typdef'd as char. Shouldn't it be wchar_t for unicode builds ?
Is wcharunix.h only included in unix-builds or does Windows use it also 
?

Thanks,

Lars
Permalink | Reply | 3 comments |
headers
Andrew Lunn | 10 May 2006 20:07
Picon

Re: _TCHAR

On Wed, May 10, 2006 at 07:13:33PM +0200, Lars Poeschel wrote:
> Hello!
> 
> In ecos/host/tools/Utils/common/wcharunix.h
> _TCHAR is typdef'd as char. Shouldn't it be wchar_t for unicode builds ?
> Is wcharunix.h only included in unix-builds or does Windows use it also 

I know very little about unicode, so please ignore what i say....

I think wcharunix.h needs remove altogether. The wxWidgets wxchar.h
and the system <wchar.h> should be used.

    Andrew
Permalink | Reply | 2 comments |
headers
Lars Poeschel | 10 May 2006 20:58
Picon

Re: _TCHAR


Am 10.05.2006 um 20:07 schrieb Andrew Lunn:

> On Wed, May 10, 2006 at 07:13:33PM +0200, Lars Poeschel wrote:
>> Hello!
>>
>> In ecos/host/tools/Utils/common/wcharunix.h
>> _TCHAR is typdef'd as char. Shouldn't it be wchar_t for unicode 
>> builds ?
>> Is wcharunix.h only included in unix-builds or does Windows use it 
>> also
>
> I know very little about unicode, so please ignore what i say....

I do not do that, because you have an interesting idea! ;-)

> I think wcharunix.h needs remove altogether. The wxWidgets wxchar.h
> and the system <wchar.h> should be used.

I think, this is not possible very easily because many Files outside 
the wx configtool depend on functions where aliases are defined in 
wcharunix.h such as _tprintf are #define'd here and allow us to use 
wprintf in unicode builds and printf for ansi builds.
I think that should stay here (maybe change the name of the file to 
someting more descriptable in that case). But to remove the TCHAR 
defines and typedefs here and use system/wxWidgets' instead is not the 
worst idea! From the programmers point of view this can make things 
much easier, since unicode support of wxWidgets seems very good to me 
and I could save much of the wchart_t <-> char conversion for library 
functions where GNU does not provide wide character versions.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Lunn | 10 May 2006 21:32
Picon

Re: _TCHAR

On Wed, May 10, 2006 at 08:58:37PM +0200, Lars Poeschel wrote:
> 
> Am 10.05.2006 um 20:07 schrieb Andrew Lunn:
> 
> >On Wed, May 10, 2006 at 07:13:33PM +0200, Lars Poeschel wrote:
> >>Hello!
> >>
> >>In ecos/host/tools/Utils/common/wcharunix.h
> >>_TCHAR is typdef'd as char. Shouldn't it be wchar_t for unicode 
> >>builds ?
> >>Is wcharunix.h only included in unix-builds or does Windows use it 
> >>also
> >
> >I know very little about unicode, so please ignore what i say....
> 
> I do not do that, because you have an interesting idea! ;-)
> 
> >I think wcharunix.h needs remove altogether. The wxWidgets wxchar.h
> >and the system <wchar.h> should be used.
> 
> I think, this is not possible very easily because many Files outside 
> the wx configtool depend on functions where aliases are defined in 
> wcharunix.h such as _tprintf are #define'd here and allow us to use 
> wprintf in unicode builds and printf for ansi builds.

ecosconfig should not depend on wx. Part of the problem that nobody
builds configtool from sources, is that it needs wx and it is hard to
build. ecosconfig on the other hand is easy to build and it should
stay that way. configtool is only nice to have. ecosconfig is
necassary and has to remain easy to build.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane