PDA

View Full Version : DCT3 NLib released



wumpus
10-09-2003, 10:34 PM
Tonight I released NLib, the codebase I use for all DCT3 experiments to the semi-public (members of my site)

It includes:
* Basic I/O functions (For lights, MBUS lines)
* Cached CCont read/write + A/D converter reading
* DSP functions; constants for various shared memory locations, working MDI and codeblock upload interface
* Flasher debugging (fits with wmx-sendcode)
* Interrupt handling (IRQ and FIQ)

I hope it is another step towards an understanding of DCT3 and a framework to make use of it..

g3gg0
11-09-2003, 12:14 AM
Tonight I released NLib, the codebase I use for all DCT3 experiments to the semi-public (members of my site)

It includes:
* Basic I/O functions (For lights, MBUS lines)
* Cached CCont read/write + A/D converter reading
* DSP functions; constants for various shared memory locations, working MDI and codeblock upload interface
* Flasher debugging (fits with wmx-sendcode)
* Interrupt handling (IRQ and FIQ)

I hope it is another step towards an understanding of DCT3 and a framework to make use of it..


woow, i must admit its a really clean and good coded library!!
i will use this lib as reference to get MADos at least half as clean as this one...
is it okay for u if i grab some ideas and code from this lib and put it
into MADos?

i want to rework MADos now before it gets still bigger ;(
things like replacing IOports as #defines are a must towards
compatibility to other phones....

the problem was:
- i started MADos without knowing what it will be
- didnt even know if it ever would work
- i never coded some routines that provide basic functions on a system
.... so i dont know how's the best to code


but i hope i can rework that lib the next time so its somewhat easier to
understand and more extendable :)

Saiko
11-09-2003, 06:34 AM
Wow!!! Where can I get NLib? How to became a member of your site? Or please explain how DSP works… Please I really need this!

wumpus
11-09-2003, 12:35 PM
g3gg0: of course you may use the libs in MADos, that's exactly what we need, a merge.. fill in missing things. The only thing we need to settle is what to use from which in areas where the systems overlap.

Saiko: I'll see what I can do. See PM..

wumpus
11-09-2003, 12:59 PM
As some people have already noticed Keypad and LCD stuff is lacking, I did not do those because g3gg0 is doing excellent UI work in his demos and MADos (and doing things twice is deadly). They will be rolled in at some point (or if someone would like to do it, great, you need to port the I/O interfaces though to _io[] and IO_setBit(...), and probably more )

<M457>
11-09-2003, 02:09 PM
wooow, my compliments! :)
@g3gg0: if you need an help :rolleyes: you can rely on me!
btw please update CVS repository if you made some changes ;)
tnx

wumpus
11-09-2003, 04:39 PM
1.0 has been released..

BOEBOE
11-09-2003, 07:23 PM
1.0 has been released..


@ Wumpus why can't you distribute this public?

Could you take sum screenshots of MadOS and nLib? Cause MadOS isn't working here and I can't acess nLib.

<M457>
11-09-2003, 07:58 PM
Cause MadOS isn't working here


what is your problem? it works very fine on 33x0 and 3410 (not tested)

BOEBOE
11-09-2003, 08:29 PM
what is your problem? it works very fine on 33x0 and 3410 (not tested)

I just can't get it working on my computer...

=> Edit: Just got it working!

g3gg0
11-09-2003, 09:29 PM
I just can't get it working on my computer...
errhhm... maybe you can describe it a little bit better?

@wumpus/M457:
okay, now im redesigning the MADos structure from flat one to
a more structured one...

a dir "apps" for snake, fire and other higlevel things
"core" for lib, crt0, menu and ui thingies(will follow)
"hw" for io, dsp, kpd, int and so on..
"include" for include files....
and so on

i thinnk thats a must befor we can merge nlib into it...

i think i got it running in 2 days : )
still have to do some other work but then we can do mutexes and
IPC

BOEBOE
11-09-2003, 09:31 PM
errhhm... maybe you can describe it a little bit better?


Got it working now!

Nice job! What did you guys now actually succeed to? I see already a Calendar mod, and so on!

wumpus
11-09-2003, 10:23 PM
@ Wumpus why can't you distribute this public?
It will be... when it's ready
Heck my site isn't even ready yet for the public, some things are getting behind while others seem to fly right now

g3gg0
12-09-2003, 12:58 AM
okay i updated the CVS now... it was easier than i thought : )
i also changed the int handling a little bit, but it needs testing...
didnt test it yet!!!

krisha is making ui.c, a small user interface (dialogs, messages, selectors etc)
m457 what do u want to do next?
add nlib's DSP code uploader to MADos? : )

<M457>
12-09-2003, 10:14 PM
ok now I'm going to try ;)

<M457>
14-09-2003, 05:18 PM
I updated CVS... DSP codeblock works!

I tried with no success to merge with MADos Nlib irq_handler :sad:

g3gg0
14-09-2003, 05:45 PM
I updated CVS... DSP codeblock works!

I tried with no success to merge with MADos Nlib irq_handler :sad:

k, nice : )
maybe as next step, convert the routines to MADos programming style
and take over all functionalities into MADos?
or should we leave nlib as standalone besdie MADos?
what do you think?

i would convert it to MADos style so we have one project not
depending on "external" code.. of course then we have to work
on MADos only.. that wouldnt be the easiest since wumpus surely
doesnt want to leave his project nlib (as i can understand)

so what to do?


okay i changed scheduler so a thread can be activated at a specified
time...
thread = sched_add ( function, 1, SCHED_PARM_STOP );
sched_set_activation ( thread, lib_get_time () + 2000 );

would add a new thread thats in state STOPPED and gets activated
in 2 seconds....
with sched_set_parm ( 0xFF, SCHED_PARM_MASTER );
this thread could place itself (0xFF) in single thread mode (no other threads get called)
with sched_set_parm ( 0xFF, SCHED_PARM_RUN );
sets normal mode again : )
i think its rather useful : D

wumpus
14-09-2003, 09:17 PM
Well I'll take a look at the new MADos now

Btw: Please don't commit easily rebuildable binaries (.exe,.o,.obj) to your CVS tree.. see .cvsignore syntax. Building those is way faster than downloading them over and over :-)

g3gg0
14-09-2003, 09:23 PM
Well I'll take a look at the new MADos now

Btw: Please don't commit easily rebuildable binaries (.exe,.o,.obj) to your CVS tree.. see .cvsignore syntax. Building those is way faster than downloading them over and over :-)


errhm, didnt add any binaries...
no exe, no fls and no .o
which do u mean?!

only nokia/MADos is for free......


i changed some cvs permissions...
please check if u still have access to nokia/MADos
if not please inform me

<M457>
14-09-2003, 10:48 PM
maybe as next step, convert the routines to MADos programming style
and take over all functionalities into MADos?
or should we leave nlib as standalone besdie MADos?
what do you think?

i would convert it to MADos style so we have one project not
depending on "external" code.. of course then we have to work
on MADos only.. that wouldnt be the easiest since wumpus surely
doesnt want to leave his project nlib (as i can understand)

so what to do?

I' am agree with you, it's better have only a project with one programming style...
@wumpus:
what do you advice us?

wumpus
15-09-2003, 12:13 AM
I don't know, I typed exactly what you put in the PM about cvs and got a whole load of things.. might be a permission problem yes :) But it's fixed now.

Well, I think merging is still a good idea, MADos is a very nice piece of work!

But I have some comments on MADos coding style:

- io_set, io_wait and friends use full 32 bit addresses. I'd like to see those as 8 bit, internally indexed into some memory mapped I/O array like in NLib. (because this generates cleaner, smaller code, and looks clearer as you refer to it as a port # not just another pointer)

- you still have the literal crt0 code from Nokia

- all Exception vectors point to your interrupt handler (including page faults and stuff that need separate error handling, if implemented at all). The idea to merge FIQ and IRQ handlers is a valid choice though. (although it increases interrupt handling latency, as both sets of interrupt lines need to be scanned on every int)

Well the other differences are not that important really just a matter of taste (procedure names, identation)

g3gg0
15-09-2003, 12:21 AM
of course we can change all these points u said : )
some of them were just made to get it working....
many things need tuning and fixes...

but nice to hear that u agree to the merge : )
first i will replace all io's with defines like u did

Saiko
15-09-2003, 09:30 PM
Saiko: I'll see what I can do. See PM..

Hey Wumpus, I’m steel waiting for your answer........

wumpus
15-09-2003, 10:36 PM
Hey Wumpus, I’m steel waiting for your answer........
Hey I did PM you the day I posted that message!

Strange, got to be something with the reorganisation..

sk3done
18-09-2003, 10:27 AM
@wumpus
hi mate anychance of access to that nlib as well mate im getting quite used to mados now so glad i learned c then asm if u could u would be my new hero

ta agin mate