[En-Nut-Discussion] qnutconf (was: A few network related feature polls)

[Thiago A. Corrêa]

Hi,

On Fri, Nov 27, 2009 at 10:53 AM, Harald Kipp <harald.kipp at egnite.de> wrote:
> Thiago A. Corrêa wrote:
>
>> The qnutconf is missing a Delegate (so it will show radio icons on the
>> tree instead of a checkbox icon) and create proper editor widget
>> (qcombobox) for the multiple choice options and spinbox for the
>> integer options. Other than that, tweaks here and there, and the part
>> that generates the sample tree. It actually builds already, but with
>> the missing custom delegate, some choices are unavailable for
>> modification.
>
> I wish to have _your_ problems. ;-) I finally succeeded to get it
> compiling and running on Windows, using VS2008. But whatever directory I
> use initially, it always fails with "Erro: There was a problem opening
> the file, please check the log message." and and

Hmmm hard to say. It´s easier to place a break point at the loading of
the file and follow the calls to see where it goes wrong. It shouldn´t
be necessary to go down to the C code though. For me it just works. I
run it at the level below nut and, most often, at the qnutconf folder
level. I added code that looks for nut up and down in the tree, the
nutconf only looks down, therefore would only work if run at the same
level as the one containing the nut folder.

> 14:40:54: Nut/OS Configurator Version 3.0.0
> 14:40:54: Linked to Qt 4.5.3
> 14:40:54: Working in C:/ethernut-4.9/nut/conf
> 14:40:59:
>
> in the log. Yes, the last one is empty. Explicitly setting the
> repository path in the settings doesn't help.

Can´t remember what might be wrong. As I said to Ole, I only tried
with avr32 .conf files, which one did you load? The avr32 are smaller
than most other platforms I think. There could be a problem with some
of those more complex files. Although the loading and evaluating of
lua should be the same.

> May be I still didn't get the Qt setup right? I had to do a lot of weird
> things to make it work in VS2008, with which I'm not familiar.
> Unfortunately VS2003 is not supported by the Qt plug-in.

It should be straight foward. Download from qtsoftware site and run
install. Then place the Qt\version\bin to path. You could also use Qt
Creator, an IDE from Trolltech (Nokia now). It should generate a
project and build, but I never used it myself. Anyway, if you go to
the command line and type: qmake -tp vc
Then it should generate a project for you, ready to load up from the
IDE. For that to work, just make sure that your QMAKESPEC environment
variable is set to win32-msvc2003 or the appropriate one if using a
different compiler

>
>> Are you aware of problems with the AVR32 build?
>
> Basically it seems to work. But I'd like to do a some more tests with
> the EVK1104, but there are a few issues with that board, like the fixed
> baud rate at the USB/RS-232 bridge. Unless these are solved, there
> wouldn't be much fun using this board. I also have an STK1000, but
> adding support for the AP7 may require more effort.
>

Outch, I wasnt aware of that. I got an EVK1104, but didn´t have the
time to play with it yet :(
I started some AP7000 support. That is, compile goes a few files
further than it did before. Unfortunally, the toolchain API that Atmel
provides isn't unified, so there at differences in the structures that
represent a device, even if the chip's registers are basically the
same. I reported that and they fixed the one instance that I pointed
out, but since I only come up with them one at the time as I try to go
further into the compilation process, that's time consuming and
impossible to just wait for fixes, we would need work-arounds.

So, I created a structure that separates the different implementations
(when needed) into files with common and specific code, such as:
timers.c --> generic code
timers_uc3.c  --> uc3 specific implementations
timers_ap.c  --> ap7xx specific implementations.

Then, I use the build system to build this or that arch code (much
like Trolltech did with Qt). This reduces a lot the #ifdefs.
I could commit it, but then as I said, it's very primordial support
and doesn't even build fully. I guess we could extend for tha AP7xx
later if someone wishes to use it for standalone code.

PS: Some of this might be outdated in relation with the topic, I
started replying at the hotel, but my internet time was up before I
could send. Luckly gmail kept my draft :)

Kind Regards,
    Thiago A. Correa