Hallo Nutzerinnen und Nutzer ;)

Ich habe ein eigenes OS für AVR Mikrocontroller geschrieben, dass ich
euch hiermit (inkl. Sourcecode) zur Verfügung stellen möchte.

Ich habe es Nano OS getauft.

Es beinhaltet folgende Features:

-preemptives Multitasking inkl. Prioritäten,
-binäre Semaphore (Mutex),
-Message Queues,
-ein einfaches Speichermanagement (basiert auf einem array im RAM) sowie
-Funktionen zur Task-Kontrolle (anhalten, löschen usw...)

Die einzelnen Funktionewn sind im Quelltext dokumentiert.

Das zip beinhaltet folgende Files:

/software/nano_os.c - Das main-File

/software/system/header/nano_os.h - die zentrale Konfigurationsdatei

/software/system/idle.c - den idle-task
/software/system/kernel.c - den "kernel"
/software/system/memory.c - das Speichermanagement
/software/system/message.c - die Message Queue
/software/system/scheduler.c - den Scheduler
/software/system/tasks.c - die Task-Steuerung

/software/user/user.c - die Usersoftware
/software/user/user.h - das header-file für die User-Software

Das OS ist im Rahmen einer Diplomarbeit entstanden, die hier leider
nicht veröffentlicht werden kann.
Es wurde entwickelt auf einem AtMega 168; Für andere Prozessoren muss
das File nano_os.h angepasst werden.

Die Dokumentation des APIs findet sich in den einzelnen Dateien; als
User-Software ist eine Binäruhr für einen Atmel AtMega 168 dabei, die
die Uhrzeit über PORTC und PORTD ausgibt. Der Schaltplan der Hardware im
eagle-Format liegt bei.

Mich interessiert insbesondere das Feedback. Also viel Spass mit dem OS,
in dem sicher noch viele Fehler zu finden sind ;)
Fragen werden gern angenommen.

gruß

tobi

>  Für andere Prozessoren muss
> das File nano_os.h angepasst werden.

Wenn ich das richtig sehe dann doch wohl auch scheduler.c weil dort ein
paar sehr prozessorspezifische Annahmen gemacht werden und es sogar
Assemblercode gibt.

Olaf

@Tom: Das ganze veröffentliche ich unter GNU GPL. Du kannst den Code
also gern verwenden, und auch weitergeben.
Solltest du den Code des OS selbst verändern, wäre eine Meldung
(hacker-tobi@gmx.net) nicht schlecht. Die user - Software ist hiervon
ausgenommen.
Lese ich das richtig...du baust Uhren ? Genau dafür ist dieses OS
geschrieben worden ;) Ich baue hauptsächlich Multifunktions-Uhren mit
AVR-Controllern, und daher kam die Idee, einige immer wiederkehrende
Themen zusammenzufassen, und ein OS draus zu gießen.
Hauptthemen waren dabei:

-Verschiedene Aufgaben (z.B. Display-Steuerung, Auslesen von Sensoren)
mit verschiedenen Prioritäten erledigen zu können,
-einheitliche Kommunikationswege zu schaffen und
-das ganze noch auf schwere Ausnahmefehler zu überwachen.

@Olaf: Jain ;) Wenn du das System für andere Prozessoren anpassen
willst, müsstest du die Scheduler.c anpassen.
Und auch andere Teile des Codes, welche avr-gcc - spezifische Makros
verwenden, müssten angepasst werden.
Wenn man in der Atmega - Familie bleibt, dann reicht es jedoch, die
Parameter in nano_os.h anzupassen.

gruß

tobi

Da Du zu beginn bei scheduler() die Register selber sicherst, müsste man
da nicht den GCC ein Attribut setzten, dass er das nicht macht? Quasi
so:

void scheduler() __attribute__ ((naked));
void scheduler()
{
    ...
}

GCC Function-Attributes
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html

Hallo Mario,

nein, denn ich sichere die Register nicht! auf den Stack, sondern in die
Task-Struktur, genauer in das für diesen Zweck vorhandene Array.
Es wäre evtl. noch als Ergänzung möglich, um dem gcc etwas Arbeit zu
ersparen, das muss ich mal testen.
aber es "geht" auch so.

gruß

tobi

hacker-tobi schrieb:
> nein, denn ich sichere die Register nicht! auf den Stack, sondern in die
> Task-Struktur, genauer in das für diesen Zweck vorhandene Array.

Ausschnitt aus deinem Quelltext

#define PUSH(r) asm volatile("push r"#r)
#define POP(r) asm volatile("pop r"#r)

// ...

void scheduler()
{
//save R0-31 to current->stack
PUSH(31);PUSH(30);PUSH(29);PUSH(28);PUSH(27);PUSH(26);PUSH(25);PUSH(24);
PUSH(23);PUSH(22);PUSH(21);PUSH(20);PUSH(19);PUSH(18);PUSH(17);PUSH(16);
PUSH(15);PUSH(14);PUSH(13);PUSH(12);PUSH(11);PUSH(10);PUSH( 9);PUSH( 8);
PUSH( 7);PUSH( 6);PUSH( 5);PUSH( 4);PUSH( 3);PUSH( 2);PUSH( 1);PUSH( 0);

// ...

Ich verstehe jetzt nicht genau wieso Du "nein" behauptest und es
trotzdem machst, aber ja... Mir ist übrigens klar, dass der Stackpointer
immer wieder auf die aktuelle Task gesetzt wird.

Kann es sein, dass Du dich an GOS orientiert hast. Da sind ja schon
einige Gemeinsamkeiten.

Beitrag "GOS: einfacher preemptive multitasking scheduler"

Was man vielleicht noch dazu schreiben sollte:

Ich "verbiege" in tasks.c den Stackpointer so, dass er für jeden Task
auf eine interne Datenstruktur char[64] zeigt, welche für den aktuellen
Task unter current->stack[] zu finden ist:

t->sp = (unsigned char *)(t->stack + sizeof(t->stack) - 3);

So gesehen ist es korrekt, "PUSH" und POP" sind Stack-Operationen,
arbeiten aber in diesem Fall auf die interne Datenstruktur.

gruß

tobi

Tobi,

super cool... eine kleine Empfehlung..
da du ja eigentlich weisst, wie gross dein task stack ist, überprüfe
beim scheduler, ob der task nicht seine grenzen überschritten hat. spart
viel debuging.. am besten noch bevor register auf den stack gesichert
werden, den schon dort könnte es passieren, das Daten überschrieben
werden..


lg roman

Hallo Roman,

prinzipiell eine gute Idee. Ich nehme an, du meinst ein Konstrukt a la

if (SP >= (current->sp + STACK_SIZE))
 task_anhilate(&current);

?

Ich überlege nur gerade, wann ein Task seine Grenzen überschreitet, denn
eigentlich hat er ja auf dem Stack nichts zu schaffen ;)
Mir fallen da im Moment nur verschachtelte Funktionsaufrufe und die
Rettung der GPR ein...

Na ja, wenn ich schon dabei bin, kann ich auf die Art auch einen
Stack-underrun vermeiden mit

if (SP >= (current->sp + STACK_SIZE) || SP < current->sp))
 task_anhilate(&current)

Bitte korrigiert mich, wenn ich falsch liege.

PS. task_anhilate ist jetzt natürlich nur ein Beispiel; hier könnten
auch andere Aktionen stehen.

166 downloads... weitere Ideen/Anregungen?

Hallo hacker-tobi,

bin dabei mich mit Deinem OS zu beschäftigen.
Kannst Du nicht eine abgespeckte Anleitung dazu legen?

Ich denke, daß wird auch anderen helfen sich an diese
Materie heran zu wagen, und es eher zu Benutzen.

Gruß

Hallo Lernender,

die API ist im Quelltext dokumentiert.

Es gibt eine vollständige Anleitung, diese ist aber leider in der
Diplomarbeit enthalten, und die darf ich erst veröffentlichen, wenn ich
die Freigabe dazu habe.

Sollte ich keine Freigabe zur Veröffentlichung bekommen, werde ich eine
Kurzanleitung erstellen und veröffentlichen. Aber auch das spreche ich
dann zur Sicherheit erst mit der Hochschule ab.

Also habt Geduld...

Hallo hacker-tobi,

danke für die schnelle Info.

Gruß

Hi,

das ganze klingt sehr interresant. Wird deine Diplomarbeit noch anders
veröffentlicht. (z.B. von der Uni)

grüße

//+++++++++++++++++TASK Control Structure+++++++++++++++
typedef volatile struct Task
{
  volatile uint8_t ID;
  volatile unsigned char sreg;
  volatile unsigned char *sp;
  volatile TaskPrio prio;
#ifdef TASK_USE_SIGNAL
  volatile TaskState state;
  volatile uint8_t laps;
#endif
  volatile unsigned char stack[STACK_SIZE];
} Task;

Also ich verstehe jetzt nicht ganz, wieso Du beim Checken ob ein
Stacküberlauf bzw. -unterlauf Du den Stackpointer SP mit current->sp
vergleichst???

StackÜBERlauf tritt doch auf, wenn SP kleiner als current->stack ist

 if (SP < current->stack) ...

und ein StackUNTERlauf triff auf, wenn SP größer als höchste Adresse vom
Array current->stack[]

 if (SP >= &(current->stack[STACK_SIZE]) ...

// Ausschnitt nano_os.h
// ...
//+++++++++++++++++++++Signal-Handler++++++++++++++++++
SIGNAL (SIG_OVERFLOW0)
{
scheduler();
}
// ...

Was mir noch aufgefallen ist, wieso eigentlich SIGNAL und nicht ISR?

Wieso springst Du aus scheduler() aus dem Interrupt zurück (letzte
Zeile, asm volatile("reti");) und wird eigentlich current ausser in
scheduler() nochmals verändert? Wenn nicht, dann macht die Zeile
"current = tasks[currentTask];" keinen Sinn, denn current ==
task[currentTask]. Wenn ja, dann würde ich noch ein volatile bei der
Deklaration von current schreiben (nano_os.h).

void scheduler()
{
//save R0-31 to current->stack
PUSH(31);PUSH(30);PUSH(29);PUSH(28);PUSH(27);PUSH(26);PUSH(25);PUSH(24);
PUSH(23);PUSH(22);PUSH(21);PUSH(20);PUSH(19);PUSH(18);PUSH(17);PUSH(16);
PUSH(15);PUSH(14);PUSH(13);PUSH(12);PUSH(11);PUSH(10);PUSH( 9);PUSH( 8);
PUSH( 7);PUSH( 6);PUSH( 5);PUSH( 4);PUSH( 3);PUSH( 2);PUSH( 1);PUSH( 0);
TIMER_REG = CLK1024;
//save SREG and SP
if (currentTask >= 0)
  {
  current = tasks[currentTask];     // // // // die Zeile
  current->sreg = SREG;
  current->sp = (unsigned char *)(SP + 32);
  }
//switch to next task
do
  {
  currentTask++;
  if (currentTask >= NUMBER)
    {
    currentTask = 0;
    }
  current = tasks[currentTask];

  #ifdef TASK_USE_SIGNAL
  if (current && current->state == TaskStateWaitForLaps)
    {
    if (current->laps > 0)
      current->laps--;
    else
      current->state=TaskStateActive;
    }
  #endif

  }

#ifdef TASK_USE_SIGNAL
while (!(current && current->state==TaskStateActive));
#else
while (!current);
#endif

//restore this task (SREG, SP and R0...31)
if (current)
  {
  TCNT0 = current->prio;
  SREG = current->sreg;
  SP = (unsigned int)(current->sp - 32);
  }
POP( 0);POP( 1);POP( 2);POP( 3);POP( 4);POP( 5);POP( 6);POP( 7);
POP( 8);POP( 9);POP(10);POP(11);POP(12);POP(13);POP(14);POP(15);
POP(16);POP(17);POP(18);POP(19);POP(20);POP(21);POP(22);POP(23);
POP(24);POP(25);POP(26);POP(27);POP(28);POP(29);POP(30);POP(31);
asm volatile("reti");     // // // // das reti
}

mar IO schrieb:
> Was mir noch aufgefallen ist, wieso eigentlich SIGNAL und nicht ISR?

Ich geh übrigens von AVR-GCC + nongnu AVR Libc aus.

http://www.nongnu.org/avr-libc/user-manual/group__...

Hallo tobi,

ja so was habe ich gemeint...
es sind nicht nur verschachtelte funktions konstrukte, die probleme
verursachen koennen, auch lokale variablen.

btw. zb. bei Linux oder Solaris, kann man die stack groesse als
parameter angeben. Ich weiss frueher hatten wir im solaris ein page
kernel thread stack dh. 8K spaeter 16k. Meistens hat es gereicht..jedoch
wenn nicht.. big baga bum.

das waere vieleicht gar nicht so schlecht, den stack nicht als array zu
definieren, sondern dynamisch allozieren und den stack size als
parameter uebergeben beim task create.

ehh.. nur so eine dumme frage.. beim interrupt, wo wird der stack
gesichert ?? auf dem current task ??


lg roman

Roman65536 schrieb:
> ehh.. nur so eine dumme frage.. beim interrupt, wo wird der stack
> gesichert ?? auf dem current task ??

Beitrag "Re: NeuesOS für AVR Mikrocontroller"

zu finden in scheduler.c

Jetzt habe ich mal deinen Code mit dem AVR-GCC übersetzt mit OPT=3 und
irgendwie frage ich mich ob der Code auch so funktioniert. Grund ist die
Zeile 0x175e, da wird aus dem Interrupt rausgesprungen, aber der
Ursprung ist noch nicht wieder hergestellt. Dies ist erst nach Zeile
0x1770. Ich kann mich auch irren, bin mir aber nicht 100 %ig sicher

Hi

@Mario:

Stack: Da liegst du richtig. Sorry war mein Fehler. Hatte vorhin den
Quelltext auch nicht vor mir.
Habs aufgenommen. Jetzt wird das System vom Scheduler zurückgesetzt,
wenn eine Stack-Violation auftritt.

Thema Signal: Macht der Gewohnheit. Aber es macht auch keinen
Unterschied, da Signal und ISR() das selbe bewirken. Des wegen auch das
RETI.

Thema current: kann theoretisch wegbleiben, ist ja nur ein Pointer auf
tasks[currentTask]. Ich empfinde es aber so als Vereinfachung, daher
bleibt der ;)

Thema code: Der läuft - schon in mehreren Projekten. Ich werd mir dein
File die Tage mal ansehen, heut bin ich zu müde

@Bachelor:

Das weiß ich zur Zeit noch nicht. Ich poste hier wenn ich was neues
weiß.

@Roman: Wie schon an Mario adressiert, ist die Stack-Überwachung mit
aufgenommen.
Das dynamische Management überleg ich mir die Tage mal, ob ich das z.B.
mit malloc() im heap realisiere. Aber eigentlich bin ich kein freund von
malloc(). Wird auch nur für die queues verwendet. Any better idea?

@All

Ich habe einen Ordner "doku" angelegt, und dort die komplette API
dokumentiert. Ist momentan noch eine simple API-Zusammenfassung, aber
wenn ich Zeit und die Eralubnis hab, kommt da evtl. noch mehr.

@Mar IO: Anmerkung: versuchs mal mit Optimize-Level s. Bei 3 kommt bei
mir funktionsfähiger code raus, der aber erheblich größer ist, als bei
s.
Mehr find ich heut abend nicht mehr raus...deinen Code schau ich mir die
Tage an

@All
Schön, dass das kleine OS so viel Anklang findet.
Und danke für die konstruktive Kritik.
Ich freu mich auch über positive meldungen, wenn jemand ein Projekt
damit realisieren sollte und es funktioniert ;)

@Mar IO: Nochmal wegen dem current: Ich seh grad, ich hab dich
mißverstanden. Ich dachte du beziehst dich auf den Pointer "current" an
sich, aber dir gehts ja nur um die eine Zeile.
Die kann raus. Habe ich auch erledigt.

Und dann hab ich auch noch gesehen, das die push/pop im scheduler mit
durch die if-bedingungen abgesichert werden sollten. auch das habe ich
angepasst.

also hier nochmal ein aktuelles file mit angepasstem scheduler...

ich geh jetzt ins bett

gruß und gute n8

tobi

Tobi,


eine Idee ohne den malloc.. meist weiss man ja wie viele task man
braucht und auch ca. den stack verbrauch.. dh. man koennte den stack
fuer den jeweiligen task schon global deklarieren. zumal man dann diesen
so oder so als parameter uebergeben muss, kann man immernoch diesen per
malloc allozieren.

anderseits... sollte eine task irgend etwas bloedes tun, kann man, man
dem der task ein rausschmiss gekriegt hat auch noch gleich sein stack
loeschen.
Ich habe es einmal so vorgesehen (ist schon jahre her und auf einem 68k)
dass das system sich merkt welche task memory alloziert hat. Stirbt
dieser oder tut was illegales, wird sein memory wieder frei fuer's
system.

lg roman

Guten Morgen Roman,

Okay, was gehen würde, wäre ein globales array, das die Stacks aller
Tasks aufnimmt, und dessen Größe fest vorgegeben wird.
Dann brauche ich zur Laufzeit nur den Stack-Pointer für jeden Task
passend auf einen freien Bereich entsprechender Größe in diesem Array zu
setzen.
Allerdings muss ich dann das globale Array mit (Anzahl der Tasks *
durchschnittliche Stack-size) initialisieren.
Ich bin mir nicht sicher, ob das Vorteile bringt, zumal die Stack_size
ja global in nano_os.h vorgegeben werden kann.
(Mir ist bewußt, dass ich damit Speicher einsparen kann, aber ich will
mal sehen, wie viel das in der Praxis ausmacht).
Ich werde es testen.

Das Memory Management in meinem OS arbeit übrigens genau nach diesem
Prinzip, nur das dort Speicherblöcke fixer Größe verwendet werden, was
den Algorithmus vereinfacht.
Jeder Task kann hier bis zu einer Obergrenze (MAX_BLOCKS) Speicherblöcke
reservieren, und diese auch wieder freigeben. Diese werden in einem
array verwaltet, das fixnach dem Muster (MAXBLOCKS*BLOCK_SIZE) angelegt
ist.

Ich seh grad, ich hab gestern versehentlich ne alte Version
hochgeladen...korigiere ich nacherher.

hacker-tobi schrieb:
> Thema Signal: Macht der Gewohnheit. Aber es macht auch keinen
> Unterschied, da Signal und ISR() das selbe bewirken. Des wegen auch das
> RETI.

Signal ist halt veraltet, nicht ganz genau das selbe wie ISR und sollte
nicht benutzt werden. Siehe Doku
http://www.nongnu.org/avr-libc/user-manual/group__...

Ausserdem springst Du mit RETI zurück aus einer Funktion (SIGNAL(...)
ist die ISR). Das I-Flag wird gelöscht, obwohl Du noch in der ISR bist.
Weiß ned ob das schlimme Auswirkungen mit sich zieht, ist halt etwas zu
früh (aber nur etwas).


hacker-tobi schrieb:
> @Mar IO: Anmerkung: versuchs mal mit Optimize-Level s.

Japp, habe ich soeben (den Code vom ersten Posting). Was mir da
auffällt, dass in SIGNAL(SIG_OVERFLOW0) (Code-Adresse ab 0x1b0) ziemlich
viel auf den Stack gesichert wird (Register, SREG, Rücksprungadressen)
und in scheduer() (ab 0xa6) nochmals alle Register. Hier kannst Du
sicher etwas einsparren (siehe GOS). Was da auch auffällt, in
scheduler() kommt zuerst ein RETI, dann ein RET (zu dem man natürlich
nicht kommt) und dann in SIGNAL(...) wieder ein RETI.


Ich habe mir bis jetzt nur scheduler() angeschaut und den restlichen
Code überflogen. Was mir dabei aufgefallen ist, dass Du gerne volatile
schreibst. Zu struct und volatile kannst dir mal folgenden Thread
durchlesen (der enthaltende Link ist auch recht interessant):
Beitrag "volatile und struct"

Tobias W. schrieb:
> stimmt, GOS ist in der Tat recht ähnlich.
> Aber nein, die beiden Systeme sind unabhängig voneinander entstanden.
> Ich kannte GOS gar nicht.
> GOS ist ein reiner Scheduler ohne weitere Funktionalität, wenn ich das
> richtig sehe.

Dann hat GOS wohl von dir abgeschaut?

GOS:

#define PUSH(r) asm volatile("push r"#r);
#define POP(r) asm volatile("pop r"#r);

[...]
void TIMER_VECTOR() __attribute__ ( ( signal, naked ) );
ISR(TIMER_VECTOR)
{
  PUSH(31);PUSH(30);PUSH(29);PUSH(28);PUSH(27);PUSH(26);PUSH(25);PUSH(24);
  PUSH(23);PUSH(22);PUSH(21);PUSH(20);PUSH(19);PUSH(18);PUSH(17);PUSH(16);
  PUSH(15);PUSH(14);PUSH(13);PUSH(12);PUSH(11);PUSH(10);PUSH( 9);PUSH( 8);
  PUSH( 7);PUSH( 6);PUSH( 5);PUSH( 4);PUSH( 3);PUSH( 2);PUSH( 1);PUSH( 0);

Deins:

#define PUSH(r) asm volatile("push r"#r)
#define POP(r) asm volatile("pop r"#r)

//****************************************************
//*scheduler()                                       *
//*                                                  *
//*      !!!INTERNAL FUNCTION!!!                     *
//*                                                  *
//* description: does the task switching             *
//* input: none                                      *
//* output: none                                     *
//****************************************************

void scheduler()
{
//save R0-31 to current->stack
PUSH(31);PUSH(30);PUSH(29);PUSH(28);PUSH(27);PUSH(26);PUSH(25);PUSH(24);
PUSH(23);PUSH(22);PUSH(21);PUSH(20);PUSH(19);PUSH(18);PUSH(17);PUSH(16);
PUSH(15);PUSH(14);PUSH(13);PUSH(12);PUSH(11);PUSH(10);PUSH( 9);PUSH( 8);
PUSH( 7);PUSH( 6);PUSH( 5);PUSH( 4);PUSH( 3);PUSH( 2);PUSH( 1);PUSH( 0);
TIMER_REG = CLK1024;

Etwas Ehrlichkeit, bitte!

@Helli: Das Thema hatten wir jetzt schon... sorry ich weiß was ich
geschrieben hab und was nicht.
Und ich sage es nochmal...GOS ist ein reiner Scheduler, Nano OS bietet
ja doch etwas mehr Funktionalität, oder?

hacker-tobi schrieb:
> @Helli: Das Thema hatten wir jetzt schon... sorry ich weiß was ich
> geschrieben hab und was nicht.
> Und ich sage es nochmal...GOS ist ein reiner Scheduler, Nano OS bietet
> ja doch etwas mehr Funktionalität, oder?

Das ist nicht das Problem ... Man muss auch seine Quellen angeben, wenn
man etwas fremdes verwendet hat.

Niemand hätte irgendwas gesagt, wenn du gleich geschrieben hättest, dass
du dich von GOS inspirieren hast lassen ...

Aber eine Lüge ist eine Lüge ...

Und mal davon abgesehen...wenn du dir den Scheduler genauer ansiehst, so
sind doch einige Unterschiede da:

-Ich rufe den Scheduler via Signal() auf, nicht als ISR. Das kommt
daher, dass ich den Scheduler schon vor längerer Zeit geschrieben hab -
für ein Uhrenprojekt- und ihn für Nano OS übernommen habe.

-PUSH und POP und die Struktur sind identisch, aber der Prozessor muss
ja immer das selbe ausführen, um einen Task-Switch auszulösen, ergo ist
das wohl nicht verwunderlich. Ok, die Makrobezeichnungen sind identisch.
Daher sehen sich die Programmteile ähnlich.
Aber das wird sich auch demnächst ändern, da ich die Registeranzahl
variabel gestalten will, wegen der neuen AtTinys, die nur noch 16
Register haben.

-Der Scheduler in Nano OS hat einige Fähigkeiten, die der GOS-Scheduler
nicht hat, wie z.B. die möglichkeit, Tasks für eine definierte Zeit
schlafen zu legen.

Insgesamt verstehe ich den Einwand, das die Scheduler ähnlich sind, aber
es gibt eben doch unterschiede.

Ich hoffe damit ist dieses (aus meiner Sicht -sorry- leidige) Thema
erledigt.

@Helli: Nochmal...ich kann nichts angeben, was ich nicht kenne.

Und mich deswegen der Lüge zu bezichtigen - meinst du nicht, dass das
etwas zu weit geht? Sorry, aber du hast nicht danebengesessen, als ich
das OS geschrieben hab, oder irre ich mich? Also woher willst du wissen,
was ich geschrieben hab und was nicht?

Und wenn ich gos als Quelle benutzt hätte, würde ich es auch angeben.
Warum sollte ich es denn verheimlichen?

Aber ich kann gern die Makrobezeichnungen ändern, und den Programmtext
umstellen, wenn dich die ähnlichkeiteen stören (das meine ich ernst,
nicht als witz).

gruß

tobi

Echt merkwürdig ...

hacker-tobi schrieb:
> Aber ich kann gern die Makrobezeichnungen ändern, und den Programmtext
> umstellen, wenn dich die ähnlichkeiteen stören (das meine ich ernst,
> nicht als witz).

Das hier ist von dir (14.09.2010):

void scheduler()
{
//save R0-31 to current->stack
PUSH(31);PUSH(30);PUSH(29);PUSH(28);PUSH(27);PUSH(26);PUSH(25);PUSH(24);
PUSH(23);PUSH(22);PUSH(21);PUSH(20);PUSH(19);PUSH(18);PUSH(17);PUSH(16);
PUSH(15);PUSH(14);PUSH(13);PUSH(12);PUSH(11);PUSH(10);PUSH( 9);PUSH( 8);
PUSH( 7);PUSH( 6);PUSH( 5);PUSH( 4);PUSH( 3);PUSH( 2);PUSH( 1);PUSH( 0);
TIMER_REG = CLK1024;
//save SREG and SP
if (currentTask >= 0)
  {
  current = tasks[currentTask];
  current->sreg = SREG;
  current->sp = (unsigned char *)(SP + 32);
  }
//switch to next task
do
  {
  currentTask++;
  if (currentTask >= NUMBER)
    {
    currentTask = 0;
    }
  current = tasks[currentTask];

  #ifdef TASK_USE_SIGNAL
  if (current && current->state == TaskStateWaitForLaps)
    {
    if (current->laps > 0)
      current->laps--;
    else
      current->state=TaskStateActive;
    }
  #endif

  }

#ifdef TASK_USE_SIGNAL
while (!(current && current->state==TaskStateActive));
#else
while (!current);
#endif

//restore this task (SREG, SP and R0...31)
if (current)
  {
  TCNT0 = current->prio;
  SREG = current->sreg;
  SP = (unsigned int)(current->sp - 32);
  }
POP( 0);POP( 1);POP( 2);POP( 3);POP( 4);POP( 5);POP( 6);POP( 7);
POP( 8);POP( 9);POP(10);POP(11);POP(12);POP(13);POP(14);POP(15);
POP(16);POP(17);POP(18);POP(19);POP(20);POP(21);POP(22);POP(23);
POP(24);POP(25);POP(26);POP(27);POP(28);POP(29);POP(30);POP(31);
asm volatile("reti");
}

und das hier ist aus einem hochgeladenen Archiv von 2007 von hier:
Beitrag "Re: GOS: einfacher preemptive multitasking scheduler"

void TIMER_VECTOR() __attribute__ ( ( signal, naked ) );
ISR(TIMER_VECTOR)
{
  PUSH(31);PUSH(30);PUSH(29);PUSH(28);PUSH(27);PUSH(26);PUSH(25);PUSH(24);
  PUSH(23);PUSH(22);PUSH(21);PUSH(20);PUSH(19);PUSH(18);PUSH(17);PUSH(16);
  PUSH(15);PUSH(14);PUSH(13);PUSH(12);PUSH(11);PUSH(10);PUSH( 9);PUSH( 8);
  PUSH( 7);PUSH( 6);PUSH( 5);PUSH( 4);PUSH( 3);PUSH( 2);PUSH( 1);PUSH( 0);
  TIMER_REG = CLK1024;
  Task *current = 0;
  if (currentTask >= 0)
  {
    current = tasks[currentTask];
    current->sreg = SREG;
    current->sp = (unsigned char *)(SP + 32);
  }
  do
  {
    currentTask++;
    if (currentTask >= MAX_TASKS)
      currentTask = 0;
    current = tasks[currentTask];
  }
#ifdef TASK_USE_SIGNAL
  while (!(current && current->state==TaskStateActive));
#else
  while (!current);
#endif
  if (current)
  {
    TCNT0 = current->prio;
    SREG = current->sreg;
    SP = (unsigned int)(current->sp - 32);
  }
  POP( 0);POP( 1);POP( 2);POP( 3);POP( 4);POP( 5);POP( 6);POP( 7);
  POP( 8);POP( 9);POP(10);POP(11);POP(12);POP(13);POP(14);POP(15);
  POP(16);POP(17);POP(18);POP(19);POP(20);POP(21);POP(22);POP(23);
  POP(24);POP(25);POP(26);POP(27);POP(28);POP(29);POP(30);POP(31);
  asm volatile("reti");
}

Sind die beiden Codeschnippsel nicht irgendwie identisch? Sogar die
Variablen heißen alle gleich usw ...

Oder hast du GOS auch geschrieben?

Wenn das für eine wissenschaftliche Arbeit wäre, würde ich mir langsam
ernste Gedanken machen

Ach, es gibt auch noch eine andere Möglichkeit ... Der GOS-Entwickler
meinte, er würde seinen Scheduler in den AVRWizard einbauen ...

Hast du den vlt verwendet?

Das würde das erklären ...

Frank M. schrieb im Beitrag #1868712:
> Aber zu behaupten, Du würdest GOS gar nicht kennen, ist dummdreist.

Vlt kennt er GOS wirklich nicht ... Ich hab grad nachgeschaut, das
Multitasking-Dings ist im AVR-Wizard auch eingebaut worden ...

Aber einen Wizard zu verwenden für das, was man selbst machen soll ...
Hoffentlich hat er das wenigstens angegeben ...

Ich habs schonmal gesagt...ich gebe zu, das sich die Scheduler ähnlich
sehen. Von daher verstehe ich den Einwand definitiv.

Und was die Arbeit angeht...dort sind alle benutzen Quellen gelistet.
In diesem Fall war auch der Fachmentor direkt an der Entwicklung
beteiligt.
Ich werde die Arbeit hier veröffentlichen, sobald ich die Freigabe dazu
habe, ok?

Sorry, aber damit ist diese Diskussion von meiner Seite her beendet,
denn sie macht keinen Sinn. Du kannst das OS gern nutzen oder auch nicht
und gern andere fachspezifische Fragen stellen, aber zu diesem Thema
wird von mir nichts mehr kommen, denn so lange ich die Arbeit nicht
veröffentlichen darf, kann ich es dir leider nicht schwarz auf weiß
widerlegen.

Übrigens, der nano OS scheduler ist älter als der von gos, genauer
gesagt von 2005/2006. nur das ich ihn nicht veröffentlicht habe, weil
ich ihn -wie gesagt- in einem Uhrenprojekt eingesetzt habe, dass ich
auch verkauft hab.
Von daher - nein ich habe gos nicht geschrieben, aber weder ist gos von
mir abgekupfert, noch umgekehrt.

Ich finds ehrlich gesagt ein wenig unverschämt, was du da sagst.
Manchmal macht der Ton die Musik.

gruß

tobi

Mal ganz abgesehen davon...wenn ich von gos abgeschrieben hätte, ohne es
anzugeben, dann wär ich wohl kaum so dumm, das hier zu veröffentlichen
;)

Ich würde vorschlagen...wir lassen diese Diskussion jetzt einfach.
Denn sie führt zu gar nichts, oder? Ich werds jetzt jedenfalls nicht
weiter kommentieren. Aber ich werde den Quelltext ändern, wenn du das
willst.

Tobias W. schrieb:
> das mit dem reti kann ich so nicht bestätigen. nimmt man das reti raus,
> wird nicht mehr aus dem Interrupt zurückgesprungen.

Das kann ich mir nicht vorstellen bzw., das ist so richtig, denn Du bist
ja noch im Interrupt drinnen. Der Interrupt ist erst aus, wenn
Signal(...) fertig ist. Wie prüfst Du das eigentlich nach?


Würde mich wundern, wenn ISR(...) nicht funktioniert. Das hat sicherlich
nichts mit den Compiler zu tun. Dieser wirft bei mir übrigens einige
Warnings raus. A

z.B: system/message.c: In function 'queue_read_byte':
      system/message.c:156: warning: 'return' with no value, in function
returning non-void

147 unsigned char queue_read_byte(Queue *qp, uint8_t position, uint8_t delete_message)
148 {
149 sregsys = SREG;
150 cli();
151 uint8_t i;
152 unsigned char tempmsg;
153 if (qp->number == 0 || qp->number <= position || qp->item_size != 1)
154  {
155   SREG = sregsys;
156   return;
157   }
158 //read message
159 tempmsg = qp->message[position];
160 if (delete_message)
161   {
162   //re-organize message queue (FIFO)
163   for (i=position;i<(qp->number)-1;i++)
164     qp->message[i] = qp->message[i+1];
165   qp->number--; 
166   }
167 SREG = sregsys;
168 return tempmsg;
169 }

@Frank: Da gebe ich dir in allen Punkten recht. Aber wie gesagt, ich
kann nichts angeben, was ich nicht kenne ;( Tut mir echt leid.
Ich sehe die Problematik ja auch absolut ein, aber was soll ich denn
noch sagen? Ich werde die Arbeit hier veröffentlichen, wenn ich die
Erlaubnis dazu bekomme, damit jeder das Gedankengut "hinter" nano os
nachvollziehen kann. Und wie gesagt, der nano os scheduler ist älter.
Nur wurde er vorher nie veröffentlicht.
Von daher kann weder ich von gos abgeschrieben haben (denn das wurde ja
erst 2007 veröffentlicht) noch gos von mir(da der scheduler ja gar nicht
veröffentlicht war). Und den AVR Wizard kenne ich, habe ihn aber nie
eingesetzt.

Es ist auch müßig, darüber zu diskutieren, denn das würde sich doch nur
im Kreis drehen.
Vorschlag: Gegenseitiges aufeinander rumhacken bringt doch nichts, wie
wäre es, wenn wir gemeinsam an nano os weiterarbeiten?

gruß

tobi

hacker-tobi schrieb:
> Ich würde vorschlagen...wir lassen diese Diskussion jetzt einfach.
> Denn sie führt zu gar nichts, oder? Ich werds jetzt jedenfalls nicht
> weiter kommentieren. Aber ich werde den Quelltext ändern, wenn du das
> willst.

Ich sag jetzt auch nichts mehr dazu ... Sogar die anderen Funktionen in
dem selben File sind identisch ... Dann würde ich dem Günter Greschenz
mal sagen, dass er nicht deinen Code klauen soll, den du 2005
geschrieben aber nie veröffentlich hast ... der ist offenbar so dumm,
ihn aus deiner Uhr zu stehlen, ihn in seinem AVR-Wizard einzubauen und
öffentlich zur Verfügung zu stellen ... Unten ein Link, und wenn man
dann auf task.c klickt, dann erscheint dein Code ... Ich würd mal einen
Virenscanner installieren, vlt hast du ja einen Trojaner ...

http://greschenz.dyndns.org/avrwiz/

Mehr Kommentare gibt's von mir aus nicht mehr dazu ... Du wirst schon
wissen, was du macht ...

@mario:

kann sein, ok, nicht ganz korrekt ausgedrückt. Er springt natürlich aus
dem Interrupt zurück, aber das I-Bit wird nicht mehr gesetzt, ergo
bleiben Interrupts inaktiv.
Warum, das muss ich in Ruhe ergründen.

Wegen ISR: Ich kanns mir zur Zeit auch nicht erklären. Aber wenn ich ISR
verwende, dann überschreiben sich die Tasks gegenseitig die Register.
Ich denke, da liegt noch was im argen. Aber auch mit dem gos-Scheduler
tritt dieses Phänomen auf. Dass muss ich mir in Ruhe ansehen.

Wegen der Warnung: Okay, da muss ich mal dran, ist ja keine große Sache.
Interessanterweise hat er das bei mir nicht bemängelt. Hast du sonst
noch irgendwelche warnungen?

Frank M. schrieb:
> Aber was ich daraus erkenne, ist, wer von wem abgeschrieben hat, denn
> Deine Version ist eleganter, also erst das SREG zu sichern und nachher
> wieder herzustellen. GOS dagegen macht es plump mit cli() und sei().

Mir gefällt die GOSs Funktion besser. Ich wüsste keinen Grund, wieso man
das SREG sichern sollte. Dass kein sei() später folgt, gefällt mir hier
auch nicht, denn man muss wissen, dass taskCreate(...) die Interrupts
ausschaltet, aber nicht wieder ein. D.h., nach der Funktion läuft das
System nicht mehr so weiter wie davor (taskCreate(...) sollte ja auch
zur Laufzeit eine Task einfügen können). Das taskCreate atomic ist, ist
völlig OK.

Frank M. schrieb:
> Die Interrupts werden mit Herstellen des SREG wieder eingeschaltet.

Stimmt, irgendwie habe ich an das gar nicht mehr gedacht und somit
völlig den Schmarrn geschrieben. Dann gefällt mir die GOS Funktion
besser, weil ich die besser lesen kann.

@Frank: Sorry, wie bereits geschrieben...diese Diskussion ist sinnlos.
Es gab für den Scheduler-Code keine Quelle. Natürlich habe ich Quellen
benutzt, aber die haben sich eher auf die Beschreibung der
Funktionaliltät bezogen und sind auch in der Arbeit erwähnt.
Dies war das Buch von Manfred Schwabl - Programmierung von
Mikrocontrollern und ein Buch zu Betriebssystemgrundlagen. Zusätzlich
einige Wikipedia-Artikel und weitere Internet-Recherchen.
Aus dem Buch von Manfre Schwabl stammen auch die Anregungen für den
Scheduler. Allerdings hat er in Assembler codiert, die C-Umsetzung ist
von mir.
Warum also sollte ich alle diese Quellen angeben, und eine (gos) nicht?

Warum sollte ich einmal Code verbessern, und dann -im Gegensatz zu gos-
statt mit ISR mit Signal arbeiten, und auch andere Kleinigkeiten, wie
z.B. die Initialisierung von current anders machen?
Und warum unterscheidet sich z.B. die komplette Tasksignalisierung
(task_signal, task_wait, task_wait_for_laps)? gos kennt z.B. auch kein
task_anhilate oder ähnliches.
Wenn ich das alles abgeschrieben hätte würde es doch identisch aussehen.
Ich gebe es auch zu, z.B. das konstrukt mit Signal() habe ich gemacht,
weil dies mein erster Scheduler ist, und ich schlicht nicht wusste, das
es auch anders (und besser) geht. Und push/pop sind nunmal
Standardfunktionen. Da können auch andere drauf kommen, die so zu
benennen. Und zum rest...der Prozessor muss nunmal zum Taskwechsel immer
das selbe tun, egal ob der Scheduler nun gos, nanoos oder sonstwie
heißt. Die Schritte sind nunmal immer...interrupts abschalten, register
sreg und SP sichern, neuen Task anwählen, register sreg sp
zurückschreiben und dann interrupts wieder aktivieren.
Und da suich die Verwaltungsinformationen ähneln, sind nunmal auch die
dafür notwendigen Verwaltungsstrukturen zwangsläufig ähnlich.

Und zum Thema rumeiern...das kann ich euch genauso vorwerfen. Ihr
versucht da krampfhaft, mir eine Quelle aus den Rippen zu leiern, die
ich nicht kenne und auch nicht benutzt habe. Ich habe keine Ahnung,
warum sich die Codes ähnlich sind, aber es interessiert mich auch nicht.
Ich werfe ja auch dem gos-schreiber kein Abschreiben vor (und glaube
auch nicht daran), obwohl mein Scheduler eher entstanden ist.
Es wurde auch schon einmal weiter oben in diesem Thread nach den
Ähnlichkeiten gefragt, und diese Frage habe ich auch beantwortet. Aber
dort wurde nur einmal nachgefagt.
Du und heli, ihr probiert es andauernd wieder, und -sorry- aber mehr als
das was ich weiß, kann ich dazu nicht sagen.
Ich werde aber meinen Code umschreiben, damit die Ähnlichkeiten weg
sind, obwohl ichs für unsinnig halte, um damit dieses Thema zu beenden.

So nun habe ich alle Quellen offengelegt, und auch sonst alles. Die
Arbeit selbst folgt, wenn ich sie veröffentlichen darf.

So, ich bin mittlerweile ziemlich entnervt. Um meine nerven zu schonen,
werden weitere Anfragen zu diesem Thema nicht mehr kommentiert.
Andere Fragen  Anregungen  Lob / Kritik werden natürlich weiter
bearbeitet und beantwortet.

gruß

tobi

Jetzt wirds ja völlig abstrus...klar ich bin Günther Greschenz...all
right ;) Komisch, auf meiner Diplomarbeit steht ein anderer
Name...Tobias W. Auf meinem Perso auch ;). Daher auch der nick
(hacker-TOBI)
Leute , lasst es einfach.

@Mario: Es ist so, wie frank sagt. Mit dem SREG wird auch das I-Bit
wieder gesetzt. Daher kein sei(). Okay ich stimme dir zu, das sieht man
nur, wenn man es weiß. Von daher ist gos besser zu lesen ;)
Aber ich denke, ein zuätzliches sei() der lesbarkeit wegen ist hier
sinnfrei() ;)
Hast du noch ne Idee, warum das mit ISR() nicht funktioniert hat?

Übrigens, GOS ist eigentlich auch schon älter, aber anscheinend ging da
der Code verloren...

---HISTORY----------------------------------------------------------------------
*) V0.000 2001 (?)
  first working version for 68000 (PalmPilot)
  (but i lost my old code ...)
*) ...


Was mich bei beiden Codes wundert, wieso SREG nicht auf den Stack
sichern und den gesicherten Stackpointer auf das erste gesicherte
Register (r31) zeigen zu lassen???

hacker-tobi schrieb:
> Hast du noch ne Idee, warum das mit ISR() nicht funktioniert hat?

Nee, bei mir hat er übersetzt, aber ausprobiert habe ich es nicht. Siehe
Anhang von

Beitrag "Re: NeuesOS für AVR Mikrocontroller"

Hi Mario,

stimmt. Aber so fit bin ich (noch) nicht, das ich den code vom 68000
umschreiben könnt, selbst wenn er noch vorhanden geweswen wäre ;) Der
Scheduler für den avr hat mich genug mühe gekostet.

Thema Sichern: Das wär ne Möglichkeit. Aber so richtig sehe ich den
Vorteil jetzt nicht. Das SREG könnte ich auf den Stack schieben, aber so
oder so geht mir dafür 1 byte im Speicher drauf.
Hast du da einen bestimmten Grund?
Stackpointer: Das lässt sich machen.

Frank M. schrieb:
>> Um meine nerven zu schonen,
>> werden weitere Anfragen zu diesem Thema nicht mehr kommentiert.
>
> Als Gründer von einigen in Deutschland ziemlich bekannten
> OpenSource-Projekten ist Dein Verhalten, was Du hier an den Tag legst,
> für mich wie ein Schlag ins Gesicht. Daher ist dieses Thema
> (Copyright/Kupfern/Diplomarbeit) für mich noch lange nicht beendet.

Wie wär's wenn man Günther auf diesen Thread aufmerksam macht und ihn
einfach frägt, ob er den Scheduler geschrieben hat oder nicht?

Aber es stimmt - Die Source-Codes sind identisch und unabhängig
identischen Source-Code zu produzieren ist unmöglich.

Grüße,
Mampf

Ich habe mich auf den kompletten code bezogen, daher von Ähnlichkeiten
gesprochen.
Ansonsten gebe ich dir recht, einzelne Zeilen sind identisch. Das API
hingegen nur in Teilen. Ich verweise da z.B. auf task_wait und
task_signal, welche andere Parameter nutzen, usw.

Und ja, ich werde den code neuschreiben. Dann ist es eindeutig, denn wie
gesagt - ich kann die Einwände völlig verstehen, und nachvollziehen.
Auch die Schlußfolgerungen sind verständlich, aber ich kann nur das
wiedergeben, was ich auch getan habe. Von daher verstehe du bitte auch,
das ich mich gegen derartige Anschuldigungen zur Wehr setze, denn aus
meiner Sicht sind sie nachvollziehbar, aber unberechtigt.
Und las bitte Äußerungen wie "das ist für mich noch lange nicht
erledigt" weg - was sollen denn solche Drohungen? Sorry, aber damit
erreichst du bei mir nichts.
Warum können wir nicht einfach konstruktiv an einer Lösung des Problems
arbeiten?
Was soll ich denn nach deiner Ansicht tun, um das Problem aus der Welt
zu räumen
(die Frage meine ich ernst, denn ich will das Thema friedlich aus der
Welt schaffen)?

gruß

tobi

Mensch Tobi,

sehe es bitte mal von der anderen Seite, einfach als gut gemeinten
Hinweis, dass es hier Probleme mit Urheberrechten geben könnte, vor
denen man dich (noch rechtzeitig) warnt und die du jetzt klären
solltest! Es muss nicht hier sein, aber in deiner Arbeit solltetst du es
tun!

Das hier jemand von jemanden anders "abgeschrieben" hat, ist wirklich zu
offensichtlich (Frank hat ein paar Dinge genannt..., für mich ist auch
die spezielle Formatierung der PUSH/POP-Anweisungen zu prägnant). Der
Zufall wäre zu groß, wenn zwei Leute genau(!) so formatieren!

Klar, wie du auch schon geschrieben hast, gleiches Thema = gleiche
Vorgehensweise, aber nicht von unterschiedlichen Leuten vollkommen
gleiche Variablennamen, Programmstrukturen, Codeformatierungen..., dass
geht einfach nicht! Da hilft es auch nicht, wenn du jetzt einfach den
Code umschreiben willst, dafür ist dieser Thread zu öffentlich!

Es ist doch legitim, wenn du fremde Codefragmente als Grundlage nimmst
und für deine Belange anpasst und erweiterst. Genau das ist doch die
geistige Arbeit die du da reingesteckt hast, an der du gemessen wirst
und die will/wird dir keiner streitig machen. Aber diese Grundlage musst
du als Quelle angeben, selbst wenn diese unter GPL steht.

Sei bitte so ehrlich, sonst kommst du spätestens bei der Einreichung
deiner Arbeit in Teufels Küche.

Wenn du nicht abgeschrieben hast, solltest du wirklich überdenken, woher
in fremden Code deine(!) ursprünglichen Fragmente herkommen können. Hast
du vielleicht doch irgendwo deine Programme und sei es auch nur ganz
kurz, öffentlich gemacht oder hast du einzelnen Leuten den Quelltext
gegeben und kannst du das irgendwie nachweisen (nicht uns, sondern immer
im Hinblick auf deine Arbeit, mit der du einen Titel erreichen willst)?

Überdenke das bitte nochmal!

SREG wird in eine globale Struktur vom Typ task gesichert, die mit
deklaration volatile versehen ist. und wo liegt die? im RAM oder?

@hugo: Das ist ja das Thema...ich hab wirklich nichts abgeschrieben ;(
Die Argumentation ist durchweg verständlich, aber was soll ich denn tun?
Ich will doch nichts zugeben, was ich definitiv nicht getan hab.
Und genauso wie gemeinsamkeiten gibt es eben auch eklatante
Unterschiede. Wir diskutieren hier über vielleicht 40 Zeilen Code in
mehren 100 Zeilen Code insgesamt.

Ob der Code mal rausgegangen ist, das ist eine gute Frage. Der Scheduler
ist 5 in den Grundzügen Jahre alt, ausschließen will ich es nicht, aber
ich möchte hier auch niemand irgendwas unterstellen.
Die Arbeit ist erledigt und abgehakt, darum mach ich mir keine Gedanken.

Aber ich werd den Code umschreiben. Ich denke, damit ist allen geholfen,
und das Problem ist aus der Welt.

Waum sollte eine globale Variable, welche mit VOLATILE versehen ist, auf
dem Stack liegen?

Siehe:

http://www.imb-jena.de/~gmueller/kurse/c_c++/c_volat.html

"Das Schlüsselwort volatile teilt dem Compiler mit, daß die mit name
bezeichnete Variable mit dem Datentyp typ durch Ereignisse außerhalb der
Kontrolle des Programms verändert werden kann.
Der Wert der Variablen muß deshalb vor jedem Zugriff neu aus dem
Hauptspeicher eingelesen werden, d.h. er darf nicht in einem Register
des Prozessors zwischengespeichert werden.
Der Compiler arbeitet bei mit volatile deklarierten Variablen ohne jede
Optimierung, d.h. läßt die entsprechenden Werte bei jedem Zugriff neu
aus dem Hauptspeicher laden und sorgt bei Veränderungen dafür, daß die
neuen Werte ohne Verzögerung dort sofort abgelegt werden."

ergo liegt die Variable auf einer fixen Adresse im Hauptspeicher.

Die Speichersegmentierung beim Atmel sieht dafür den bereich .data vor,
der für Variablen reserviert ist.
Was natürlich nicht ausschließt, das lokale Variablen auf dem Stack
liegen können, aber diese Variable ist eben nicht lokal.

Frank M. schrieb:
> Günters Arbeit ist nicht unter der GPL gekennzeichnet. Daher reicht eine
> Quellenangabe nicht aus.
>
ist mir bewußt und hatte ich nur als weiteres Beispiel gemeint, dass
auch GPL-Software (bzw. OpenSource im allgemeinen) nicht zur sorglosen
"Bedienmentalität" einladen sollte, ohne die Quellen wasserdicht
anzugeben... hatte mich etwas missverständlich ausgedrückt.

Sorry, was das andere Thema angeht, da werde ich nur den Code
umschreiben. Ansonsten gibts da nicht viel zu überdenken, denn da kann
ich ein reines Gewissen haben, tut mir leid. Wenn jemand anderer Meinung
ist - ok.
Aber das ändert nichts daran, dass der Code von mir stammt. sorry.

Ich gebe aber ehrlich zu, das ich vieles zusammenschneidern musste, und
das ich froh bin, dass der Scheduler überhaupt läuft. Manches habe ich
auch per trial&error ermittelt.

gruß

tobi

@Frank: Ja kann man so machen. Ich gebe ehrlich zu, dass war reine
bequemlichkeit. mal sehen, ob ich sreg/sregsys nicht lokal anlege.

Zum Abschluß: Wie kommen wir jetzt mit der leidigen Code-Thematik
übberein? Ich werde den Code umschreiben, aber was muss ich dabei
beachten?
Frank, kannst du mir da helfen?

hacker-tobi schrieb:
> Sorry, was das andere Thema angeht, da werde ich nur den Code
> umschreiben. Ansonsten gibts da nicht viel zu überdenken, denn da kann
> ich ein reines Gewissen haben, tut mir leid. Wenn jemand anderer Meinung
> ist - ok.
> Aber das ändert nichts daran, dass der Code von mir stammt. sorry.
>
... willst du es nicht verstehen? Wenn du nicht abgeschrieben hast (und
du bestehst ja darauf, was dein Recht ist), dann hat der andere
abgeschrieben!

Und das ist der Knackpunkt, du musst dann deine(!) Rechte geltend
machen, sonst kann es ganz leicht passieren das deine Arbeit hinfällig
wird und sich fremde Leute mit deinen Federn schmücken (und u.U.
irgendwann mal Geld damit verdienen). Im schlimmsten Fall meldet sich
der Andere und macht seine Urheberrechteansprüche geltend...

Ich würde es genau aus diesem Grund nicht so leichtfertig abtun, wie
leben (leider) nicht im Software-Sozialismus. Geistige Arbeit wird nicht
als gesellschaftliches Gemeingut angesehen, sondern wird knallhart als
Kapital verwendet.

@hugo:Ich versteh das Grundproblem. Du hast recht, von der Seite hab ich
es noch nicht betrachtet. Ok, was den jetzigen Stand angeht, lasse ich
es auf sich beruhen.
Den neuen Code würde ich gerne als open source nach GNU GPL o.ä.
veröffentlichen. Was gibt es dabei zu beachten?
Ich gestehe ehrlich, das ich mich bis jetzt nicht besonders um Lizenzen
und ähnliches bemüht habe. Mir war es bis jetzt egal, wenn jemand den
Code verwandt hat, auch kommerziell. Ich schreibe das in meiner Freizeit
und weil ich Spass daran habe. Bei Lösungen, die ich selbst verkaufe,
habe ich den code nie veröffentlicht.
Das mag naiv klingen, aber so war bis jetzt mein Denken. Durch diese
Diskussion wurde ich eines besseren belehrt. Aus Fehlern lernt man eben.

@Frank: Ich wills nicht verfremden, ich werds neu schreiben. Und dabei
gleich einige der Anregungen von hier mit aufnehmen. Ich weiß aber
momentan noch nicht, wann ich dazu komme. Ich poste hier, wenn ichs
fertig hab.
Ich bezog das weiterhelfen darauf, wie ich den Code so gestalte, dass es
keine Probleme bezüglich der Verwechslung mit gos mehr gibt. Und da hast
du mir mit der Aussage schon geholfen. Danke.

hacker-tobi schrieb:
> @hugo:Ich versteh das Grundproblem. Du hast recht, von der Seite hab ich
> es noch nicht betrachtet. Ok, was den jetzigen Stand angeht, lasse ich
> es auf sich beruhen.
>
naja, deine Entscheidung, ich würde es nicht so leichtfertig betrachten.
Immerhin hat, wenn deine Aussagen wirklich zutreffen, jemand deinen
Quellcode kopiert und nichtmal unter eine Lizenz gestellt, die ein
ungehindertes Weiterverwenden durch anderer (und damit auch dir selbst)
ermöglicht.

> Den neuen Code würde ich gerne als open source nach GNU GPL o.ä.
> veröffentlichen. Was gibt es dabei zu beachten?
>
du deklariert dies einfach so. Es gibt gewisse Regeln, wie das gemnacht
wird. Wichtig ist, dass du jede Quelltextdatei mit einem entsprechenden
Hinweis versiehst und den vollständigen GPL-Text als Datei mitlieferst
bzw. verweist wo er zu finden ist. Wie man es genau macht, findet man
recht leicht im Internet auf den entsprechenden Seiten. (Viele
OS-Editoren nehmen einem auch die Arbeit ab und haben entsprechedende
Funktionen, mit dem man soetwas per Tastendruck erledigen lassen kann.)

> Ich gestehe ehrlich, das ich mich bis jetzt nicht besonders um Lizenzen
> und ähnliches bemüht habe. Mir war es bis jetzt egal, wenn jemand den
> Code verwandt hat, auch kommerziell. Ich schreibe das in meiner Freizeit
> und weil ich Spass daran habe.
>
sagen wir mal so, Freizeit ist ok, solange man die verbrachte Zeit auch
wirklich als Vergnügen ansieht. Ich mache es teilweise auch so und gebe
z.B. hier einfach Quelltexte (manchmal gedankenlos)) weiter und freue
mich, wenn es andere Leute gebrauchen können --> reines Hobby. Sehe den
Aufschrei, den es hier jetzt in deinem Fall gab, bitte "dir
wohlgesonnen". Immerhin willst du deinen Quelltext für eine Arbeit
verwenden, die schon einen offizielleren Charakter hat (und die
letztendlich auch Geld bedeutet)... und da hört der Spaß auf, die Welt
draussen ist erst mal grundsätzlich böse!

... Frank war schneller :-)

Frank M. schrieb:
> 2. Anerkennung des Sources als Dein rechtliches Eigentum
>
genau das würde ich auch fordern, wenn die Tatsachen wirklich so liegen!
(immerhin schmückt sich hier jemand mit fremden Federn...)

Grüße Uwe Berger

Hallo ???


Kann mir jetzt einmal jemand sagen, um was es hier eigentlich geht ??
Das herumhacken und herumzicken geht langsam auf dem sack.

Geht es jetzt um technische weiter entwicklung oder ob jemand etwas
veroeffentlicht unter GNU und dabei wo moeglich einige Code fragmente
verwendet hat, die schon unter GNU stehen ?? hmm..

Wie es schon Tobi irgendwo geschrieben hat.. geht es um grundlegende
frage von dem Ton "C" oder das was man mit den Ton Musik macht ??


Mal ganz abgesehen davon, das alle taskswitching routinen so ziemlich
gleich aussehen !! zb. Die von Linus, ist verdammt aehnlich mit der von
BSD oder SVR4 !! weil sie alle so oder so das selbe tun muessen!!

Oder Wollt Ihre alle wirklich sagen, das Ihr in euren Codes alle quellen
angeben, von wo und von wem Ihr eure Codes habt ?? Stelle ich mein Code
in ein Oeffentliches Forum, so kann ich doch nicht wirklich auch noch
verlangen von den Usern, das sie mir ein email schicken und copyright
meldungen in den code reinschreiben und und und.. und Wollt ihr
tatsaechlich zurueck gehen bis zum Donald Knuth und dem TAOCP ?!!

Neben bei gesagt.. Wo im Gos, sind semaphoren, wo sind queue's, wo ist
memory mgr. !! Wo sind die Hinweise, das im avr basic interpreter auf
mein code verwendet wird und meine ideen :)

Hoert doch auf euch wie kleine kinder zu benehmen..

lg roman

@ Roman65536

Dein Geschreibsel ist kaum zu ertragen, weder Inhalt noch Form genügen
der Netiquette.

Frank M. schrieb:
> Du rufst aus der ISR die Funktion scheduler() auf und dort machst Du
> einen RETI. Damit machst Du den Stack, den sich der Compiler beim
> Übersetzen der ISR und der Funktion secheduler() selbst gebaut hat,
> kaputt. Besser gesagt: Du baust den Stack, der bei jedem ISR-Aufruf
> aufgebaut wird, nicht wieder korrekt ab.
>
> Vielleicht schaust Du Dir den vom Compiler erzeugten ASM-Code für die
> ISR und für scheduler() mal an und prüfst den auf saubere
> Stackbehandlung.

siehe Beitrag "Re: NeuesOS für AVR Mikrocontroller"

war beim AVR-GCC mit Optimierungsstufe 3

//+++++++++++++++++++++Signal-Handler++++++++++++++++++

SIGNAL (SIG_OVERFLOW0)
{
    1646:  1f 92         push  r1
    1648:  0f 92         push  r0
    164a:  0f b6         in  r0, 0x3f  ; 63
    164c:  0f 92         push  r0
    164e:  11 24         eor  r1, r1
    1650:  8f 93         push  r24
    1652:  9f 93         push  r25
    1654:  ef 93         push  r30
    1656:  ff 93         push  r31
//****************************************************

void scheduler()
{
//save R0-31 to current->stack
PUSH(31);PUSH(30);PUSH(29);PUSH(28);PUSH(27);PUSH(26);PUSH(25);PUSH(24);
    1658:  ff 93         push  r31
    165a:  ef 93         push  r30
    165c:  df 93         push  r29
    165e:  cf 93         push  r28
    1660:  bf 93         push  r27
    1662:  af 93         push  r26
    1664:  9f 93         push  r25
    1666:  8f 93         push  r24
PUSH(23);PUSH(22);PUSH(21);PUSH(20);PUSH(19);PUSH(18);PUSH(17);PUSH(16);
    1668:  7f 93         push  r23
    166a:  6f 93         push  r22
    166c:  5f 93         push  r21
    166e:  4f 93         push  r20
    1670:  3f 93         push  r19
    1672:  2f 93         push  r18
    1674:  1f 93         push  r17
    1676:  0f 93         push  r16
PUSH(15);PUSH(14);PUSH(13);PUSH(12);PUSH(11);PUSH(10);PUSH( 9);PUSH( 8);
    1678:  ff 92         push  r15
    167a:  ef 92         push  r14
    167c:  df 92         push  r13
    167e:  cf 92         push  r12
    1680:  bf 92         push  r11
    1682:  af 92         push  r10
    1684:  9f 92         push  r9
    1686:  8f 92         push  r8
PUSH( 7);PUSH( 6);PUSH( 5);PUSH( 4);PUSH( 3);PUSH( 2);PUSH( 1);PUSH( 0);
    1688:  7f 92         push  r7
    168a:  6f 92         push  r6
    168c:  5f 92         push  r5
    168e:  4f 92         push  r4
    1690:  3f 92         push  r3
    1692:  2f 92         push  r2
    1694:  1f 92         push  r1
    1696:  0f 92         push  r0
 
...

POP( 0);POP( 1);POP( 2);POP( 3);POP( 4);POP( 5);POP( 6);POP( 7);
    171e:  0f 90         pop  r0
    1720:  1f 90         pop  r1
    1722:  2f 90         pop  r2
    1724:  3f 90         pop  r3
    1726:  4f 90         pop  r4
    1728:  5f 90         pop  r5
    172a:  6f 90         pop  r6
    172c:  7f 90         pop  r7
POP( 8);POP( 9);POP(10);POP(11);POP(12);POP(13);POP(14);POP(15);
    172e:  8f 90         pop  r8
    1730:  9f 90         pop  r9
    1732:  af 90         pop  r10
    1734:  bf 90         pop  r11
    1736:  cf 90         pop  r12
    1738:  df 90         pop  r13
    173a:  ef 90         pop  r14
    173c:  ff 90         pop  r15
POP(16);POP(17);POP(18);POP(19);POP(20);POP(21);POP(22);POP(23);
    173e:  0f 91         pop  r16
    1740:  1f 91         pop  r17
    1742:  2f 91         pop  r18
    1744:  3f 91         pop  r19
    1746:  4f 91         pop  r20
    1748:  5f 91         pop  r21
    174a:  6f 91         pop  r22
    174c:  7f 91         pop  r23
POP(24);POP(25);POP(26);POP(27);POP(28);POP(29);POP(30);POP(31);
    174e:  8f 91         pop  r24
    1750:  9f 91         pop  r25
    1752:  af 91         pop  r26
    1754:  bf 91         pop  r27
    1756:  cf 91         pop  r28
    1758:  df 91         pop  r29
    175a:  ef 91         pop  r30
    175c:  ff 91         pop  r31
asm volatile("reti");
    175e:  18 95         reti
scheduler();
}
    1760:  ff 91         pop  r31
    1762:  ef 91         pop  r30
    1764:  9f 91         pop  r25
    1766:  8f 91         pop  r24
    1768:  0f 90         pop  r0
    176a:  0f be         out  0x3f, r0  ; 63
    176c:  0f 90         pop  r0
    176e:  1f 90         pop  r1
    1770:  18 95         reti

... deine letzten Postings lesen sich so, als hättest du den Scheduler
nicht geschrieben und müsstest jetzt erst rausfinden, was der überhaupt
macht und wie er funktioniert ...

Irgendwie glaub ich dir einfach nicht ;-)

hi Helli,

in C weiß ich wie der funktioniert ;) In Assembler bin ich nicht so der
crack. Wie gesagt, manches war trial & error ;)
Ich frage mich nur immer noch, warum der proloque/epiloque notwendig
ist. aber das schau ich mir echt wann anders in ruhe an, jetzt muss ich
erstmal im neuen job ankommen.

übrigens...von günther hab ich nichts gehört bis jetzt. ich warte noch
etwas und dann werd ich meine geänderte version online stellen. ich
denke, ich werde auch romans anregung mit aufnehmen, den stack in ein
globales array zu verlagen, und die stackgrößen variabel zu machen. das
ist ja nicht soviel arbeit.

bis dahin sind weitere anregungen gern wilkomen.

gruß

tobi

hi

also für mich als außenstehenden und jemanden der auch hier und da
programmiert und versucht
ich sehe das so :

er hat ein OS gesucht und versucht  es zu verstehen wie es arbeitet
ihm sind dann einige stellen aufgefallen was man eventuell verbessern
könnte
bzw erweitern ...

das ist lobenswert und würde auch den author von GOS glücklich machen

was mir daran so misfällt:

er "verkauft" es als sein OS trotz dessen es hunterte zeilen sind die
wirklich identisch sind  sogar variablen gleich .. ja sogar kommentare
ich würde vermuten sogar schreibfehler und groß/kleinschreibung

für mich is der typ nen blender der sich hier ma etwas wichtig machen
will



ich hätte es besser gefunden bei der wahrheit zu bleiben ...
er hat GOS erweitert vlt verbessert ... mehr nicht



es aber nach so vielen beweisen immernoch abzustreiten ...
ist etwas .. naja ... dreist

Hi fremder (interessanter name),

ich hoffe, du hast auch gelesen, das mein Scheduler älter ist als GOS.
Aber es ist schon richtig, ich habe im Rahmen einer Diplomarbeit die
Funktionsgrundlagen für ein OS definiert, und daraus ist dann eben Nano
OS entstanden.
Und es sind ca 100 Zeilen, mal abgesehen davon, dass GOS ein reiner
Scheduler ist, und nano os sehr viel mehr Funktionen bietet.

Aber ok, ich kann auch jeden verstehen, der da anders denkt. Das die
Sachlage aus Sicht des Forums eine andere ist, ist klar, und ich kann es
nicht beweisen.

Ich will und werde aber auch dem GOS-Author keinen Vorwurf machen, zumal
ich denke, dass wir evtl. schlicht die gleichen Quellen benutzt haben.
Aber wie auch bereits geschrieben, habe ich den Scheduler nochmal
überarbeitet, damit die identischen Teile weg sind.
Und ich habe mich auch mit dem Author von GOS in Verbindung gesetzt, der
sich aber bis heute nicht gemeldet hat.
Ich warte noch etwas ab, weil ich mich eigentlich mit ihm abstimmen
möchte, bevor ich die neue Version online stelle. Aber wenn da in
nächster Zeit nichts kommt, dann geht das Ding online.
Diesmal zur Sicherheit unter GNU GPL.

Ansonsten noch "happy coding" und gute n8:)

Ich melde mich spätestens wieder, wenn die neue Version online geht.

Nochmal was ganz anderes...jetzt wurde hier soviel über den Scheduler
geredet...wie siehts denn mit den anderen Teilen aus? Hatte da schonmal
jemand gelegenheit, zu testen, und evtl. Anregungen oder Fehler
gefunden?

Insbesondere würde mich der Bereich der Messages interessieren, denn die
Semaphore sind einfach gestrickt, und auch das RAM-Management ist nicht
allzu komplex.

gruß

tobi

Hallo Tobias,

ich finde es schade, dass einige auf dir herumhacken. Es gibt Leute, die
stören sich an jeder Trivialität, selbst an so Dingen wie einem
abgeschriebenen "define ...". Da vergeht einem natürlich die Lust, noch
irgenndwas zu veröffentlichen.

Meine Meinung: Lass Dich nicht von denen entmutigen und gehe Deine Weg
einfach weiter.

Viele Grüße,
Markus

Hallo Tobias,

bitte, bitte, bitte rücke deinen Code anständig ein. Klar gibt es da
verschiedene Stile, aber so bitte nicht.

Hier mal einen Auszug, wie man viel lesbarer formatieren könnte:

uint8_t semaphore_free(Semaphor *s)
{
        sregsys = SREG;
        cli();
        if (s->owner != currentTask) 
  {
          SREG = sregsys;
          return 0;
  }

        s->owner = 0;
        SREG = sregsys;
        return TRUE;
}

//****************************************************
//*semaphore_read(Semaphor *s)                       *
//*                                                  *
//* description: read status of a semaphore          *
//* input: Pointer to Semaphore                      *
//* output: TRUE(free), NULL(error/non free)         *
//****************************************************

uint8_t semaphore_read(Semaphor *s) 
{
        sregsys = SREG;
        cli();
        if (s->owner)
  {
          SREG = sregsys;
          return 0;
  }
        SREG = sregsys;
        return TRUE;
}

//****************************************************
//*semaphore_wait(Semaphor *s)                       *
//*                                                  *
//* description: wait for a semaphore                *
//* input: Pointer to Semaphore                      *
//* output: TRUE(is free), NULL(error)               *
//****************************************************

uint8_t semaphore_wait(Semaphor *s) 
{ 
        //enable multitasking to avoid a deadrun 
        wdt_enable(WDTO_2S); 
        TIMER_ENABLE |= _BV(TOIE0); 
        sei();

        while (s->owner != 0)
          TCNT0 = 0xFF;  //Do a task switch if the semaphore is used; ; Do not set this to any other value than 0xFF, it won't work because we are in a loop!
        return TRUE;
} 

Ach ja, es ist bei Kommentaren generell gut, die Zeile nie länger als 80
Zeichen werden zu lassen. Aber das ist auch nur Kosmetik ;-)

Gruß,
NIco

haha, toll, die Bordsoftware hats verkackt :-D

@Günther:

Erstmal danke für die Rückmeldung. Ich habe mit sleep(ms) das selbe
Problem. Ist ja auch klar ;). Was ich eingebaut habe ist ein funktion
wait_for_laps(), mit der man einen Task eine bestimmte Anzahl von
Scheduler-Runden schlafenlegen kann. Ein genaues timing ist damit
natürlich nicht möglich, die Funktion dient eher dazu, einen Task
"ruhigzustellen", wenn absehbar ist, dass er länger nichts zu tun hat.
Zusätzlich gibt es -wie in GOS auch- Funktionen zum Schlafenlegen und
Wecken eines Tasks, allerdings mit dem Unterschied, das du ein
TaskSignal dafür nutzt, während ich direkt auf den Task selbst arbeite.

In meinen Uhrenprojekten habe ich zur Erzeugung des Grundtakts für die
Uhr den timer2 genutzt, da ich diesen (beim Mega168) mit einem externem
Uhrenquarz betreiben kann.
Also auch bei mir kein sleep(ms) oder sonstwas ;(
Ansonsten geht die Funktionaliät in nano_os allerdings deutlich weiter,
so kann es dynamisch tasks erstellen/verwerfen, und auch Dinge wie
Speichermanagement, Semaphore und Message Queues sind dabei. Gerade für
diese hätte ich gern noch "Funktionsberichte".

Ich habe meinen Scheduler schon neu geschrieben, um die Ähnlichkeiten
weg zu bekommen. Dann gibts hier definitiv kein Thema mehr, hoffe ich.
Den stelle ich dann in einem neuen thread unter GPL zur Verfügung.
Vorher werden noch einiger der hier gesammelten Anforderungen mit
aufgenommen, hauptsächlich die Idee, den Stack in ein globales Array zu
verlagern.

@Nico: Nehme ich mit. Hier hat eben jeder "seinen" Stil. Aber das ist ja
kaum Arbeit, und ich denke, da lässt sich was machen.
Die Formatierung ist auch in Zusammenhang mit der Diplomarbeit
entstanden. Ich gebe dir aber recht, für sich ist sie etwas "schwierig".

@ Günter Greschenz:

Ohne jetzt sehr lange darüber nachgedacht zu haben: Aber wie wäre es,
den einen Timer einfach schneller laufen zu lassen und damit dann die
anderen Timer "emulieren"?

Also wenn ich einen 200-ms-, einen 500-ms- und einen 1000-ms-Timer
brauche, dann initialisiere ich einfach einen 100-ms-Timer und kann
damit alle anderen Auflösungen emulieren, wenn du verstehst, was ich
meine.

Gruß,
Nico

Erstens: Man könnte die Prioritäten weglassen, und einfach alle x
Systemtakte via TimerXX_ovf umschalten.
Dann wäre ein sleep() problemlos machbar, aber es stünden eben auch
keine Prioritäten mehr zur Verfügung.

Man könnte natürlich auch die Task-Umchaltung (in Abhängigkeit von der
Priorität) jeweils erst nach n timerXX_ovf - Interrups auslösen (z.B.
n=1 bei Prio low, 2 bei medium, 3 bei high oder so). Auch dann wäre ein
sleep möglich, auch in Verbindung mit Prioritäten. Aber Priority "low"
wären dan n schon 256*1024 Takte, was dem aktuellen prio high
entspricht. Und vorzeitiges Ausberechen aus den Tasks a la task_switch()
ist ebenfalls tabu, da hier TCNT neu gesetzt wird.

Das ganze sehe dann eben (nur der Kopf) in etwa so aus:

void scheduler()
{
sleep++; //increase variable for sleep-function
act_prio_count++;
if (task->prio <= act_prio_count)
 asm volatile("reti");
else
 {
 akt_prio_count = 0;
 //Contextswitch
 }
}

Evtl gäbe es auch andere Ideen, z.B. in dem man den Compare-Mode
nutzt...

@nico: geht so nicht, denn in beiden OSsen wird das TCNT0 (timer-counter
Register) in Abhängigkeit von der aktuellen Priorität verändert. Das ist
das Grundproblem.

Das Zeitproblem kenne ich....der Compare mode ist einfach:

Sobald TCNT0 einen definierten Wert erreicht, gibts nen Interrupt. Den
kann man natürlich für nen Scheduler nutzen.

Die simpel-Lösung:

Mit jedem Timer0_OVF führt man einen Task-Wechsel aus. Jetzt definiert
man den Compare-Wert auf:

1 für low, 64 für medium und 255 für high.

somit hätten die Tasks 1024, 64*1024 und 255*1024 takte zeit.

Das TCNT0 bliebe unverändert, und damit könnte Timer0_OVF auch für ein
definiertes sleep() genutzt werden.

Wird der Compare-Interrupt ausgelöst, wechselt man (z.B.) in einen
Idle-Task der bis zum nächsten Timer0_OVF nichts tut.


Das Problem ist folgendes: Was macht man bei low und medium-tasks mit
der Zeit bis zum nächsten Timer0_OVF (immerhin 254 bzw. 191 * 1024
Takte)?

Die würden nämlich bei dieser simpelst-Lösung einfach ungenutzt
verpuffen.

Also von Ideal ist das weit entfernt...

Günter Greschenz schrieb:
> da ich mit dem verwendeten konzept ein sehr genaues "sleep(ms)" nicht
> realisieren konnte (die servos flackerten ohne ende) hab es ich dann
> nicht weiterverfolgt.

Verstehe ich das richtig, Du wolltest mittels sleep(ms) mehrere
Soft-PWM-Kanäle erzeugen (z.B. fünf Tasks, die jeweils einen anderen Pin
ansteuern)?

So, nun gehts ja hier doch mal mit der Entwicklung und Ideen weiter.

Daher habe ich mich entschlossen, auch meinen neuen Scheduler hier zu
veröffentlichen.

Was ich getan hab:

-Code der Taskverwaltung neu geschrieben,
-die Stack(s) in ein globales array im RAM verlagert.

To Do:

Die Stacksizes dynamisch veränderbar machen. Sorry, ich hab zur Zeit
einfach zu wenig Zeit. Und wenn dann mach ich das richtig, also inkl.
"best-fit"-Algorithmus, um das array möglichst auszureizen.

Thema Formatierung: Ich weiß nicht, aber irgendwie ist das mein Stil,
code zu schreiben. und das seit Jahren ;) Daher bin ich bis jetzt bei
meiner Formatierung geblieben. Wer sich das anders formatieren will,
kann das gern tun.

Leute,

die Version von eben bitte nicht verwenden. Da ist mir ein grober Fehler
in task_control.c unterlaufen, durch den ihr euch beim dynamischen
Anlegen von Tasks zur Laufzeit den Stack zerschießt.

Nun ists bereinigt. Anbei die funktionierende Variante.

@Bernhard: Ja das ist im Prinzip richtig. Den scheduler in die ISR zu
legen, funktioniert aber nicht ;(
Siehe auch Beiträge vom 24.09.2010 20:37 ff.

Zum "späten" sichern: Das if-Konstrukt ist ein Test auf eine
Stack-Violation, und sollte daher möglichst früh erfolgen. Daher steht
es an erster stelle. Hier werden aber ausschließlich volatiles
verglichen, daher sind keine Operationen auf dem Stack nötig.
Das "TIMER REGISTER =" könnte auch hinter den pushes stehen, aber auch
hier wird am Stack nichts geändert.

@Martin/Sebastian: Stimmt, so sollte es mit dem Compare Match klappen.
Ok wird getestet.

gruß

tobi

Tobi,

was du suchst, glaube ich, zu mindest.. ist die naked isr von avr-libc.

<zitat>
#define ISR_NAKED

 # include <avr/interrupt.h>

ISR is created with no prologue or epilogue code. The user code is
responsible for preservation of the machine state including the SREG
register, as well as placing a reti() at the end of the interrupt
routine.

</zitat>

dh. die pushs vor dem scheduler werden nicht mehr gamacht und dann
sollte es wieder stimmen mit der stack organization. muss aber zugeben,
ich habe die neuste version noch nicht angeschaut..



lg roman

@guenter

eigentlich das selbe.. nur anderst definiert :)

und sogar fuer den reti gibt es ein define .. reti() wenn die
"avr/interrupt.h" included ist.. :)


<zitat>
oh mann ich brauch mal wieder zeit für son hobby, die sw die ich
beruflich baue hat >1000 source files, sowas hübsches kleines wie
gos/nano-os nicht mal 1000 zeilen. seufz...
</zitat>

geht manch einem so.. fuer das haben wir ja so ein hobby... ;)
autopilot fuer modelflieger unter 1000 zeilen .. cooles ziel 8D hihihi..

lg roman

>
> Zum "späten" sichern: Das if-Konstrukt ist ein Test auf eine
> Stack-Violation, und sollte daher möglichst früh erfolgen. Daher steht
> es an erster stelle. Hier werden aber ausschließlich volatiles
> verglichen, daher sind keine Operationen auf dem Stack nötig.
> Das "TIMER REGISTER =" könnte auch hinter den pushes stehen, aber auch
> hier wird am Stack nichts geändert.
>

Schon mal das Assembler-Listening angeschaut? Den Stackverbrauch hast Du
damit enorm gesteigert! Du legst einige Register doppelt ab, genauso wie
SREG.


Wie sieht es eigentlich mit den Warnings aus? queue_read_byte schon
gefixt?

Günter Greschenz schrieb:
> jupp, so in der art, nur halt nicht 5 sondern so viel wie geht, d.h. wie
> pins als "out" schaltbar sind (wollte mal nen kleinen roboter baun :-)
> mit richtigen timern hats sehr gut geklappt, die servos waren saustabil,
> aber halt zu wenig..

Ich hab mir auch schon mal überlegt einen Roboter bzw. einen Roboterarm
zu bauen. Als Servos hätte ich dann OpenServo verbaut. Die Ansteuerung
über I2C finde ich eleganter als über PWM und die Möglichkeit die
Position auszulesen, könnte man auch irgendwie zu nutzen.

http://openservo.com/

@Mar IO: Ich weiß, das hier überflüssige Arbeit entsteht.
Aber wie gesagt, mit scheduler in die ISR und "naked" (wie bei GOS)
funktioniert es nicht ;(
Obwohl es das laut asm-file müsste, denn wie du richtig bemerkt hast,
werden im proloque/epiloque nur einige Register doppelt gesichert bzw.
wiederhergestellt.
Daher bleibt das erstmal so, bis ich mehr zeit habe, mal das "warum" zu
finden. Ich kenne mich auch mit assembler nicht so gut aus, daher
brauche ich zeit, um das asm-file zu analysieren.
Oder hast du da eine Idee, woran das liegen kann?

Ich verweise hierzu auf meinen Beitrag vom 24.09.2010 20:37 ff. dort ist
das Problem beschrieben.

trotz (bzw. gerade wegen) reti wird der Stack auch wieder abgebaut,
siehe meinen Beitrag vom 25.09.2010 18:49.

Sauber ist das derzeit noch nicht, aber wie gesagt, mir fehlt es zur
Zeit an Ideen und Zeit.

@Günter: Was ist der avr-wiz? Sagt mir jetzt so erstmal nichts.
Aber deinen Quelltext von GOS habe ich mir angesehen. Von daher ist mir
klar, worauf du raus willst. Ich weiß nicht, warum der Code bei mir
nicht funktioniert. Ist ja ansonsten nahezu identisch ;)

@mar io nochmal ;) Ich seh grad, mit dem argument, das die Abfrage der
SP-Volation viel Arbeit auf dem Stack verursacht, hast du recht. Ich
kann es aber auch nicht hinter die Registersicherung legen, denn dann
wäre es definitiv zu spät.
Außerdem würde es die Arbeit ja auch nur "verlagern". Mal sehen, ob ich
das evtl. vereinfache oder wieder herausnehme.

So jetzt arbeite ich erstmal weiter...bis heut abend ;)

<zitat>
wenn du das fertig hast: HER DAMIT :-)
mein sohn baut sich grade nen microcopter, der ist bestimmt gut
erweiterbar !
</zitat>

http://diydrones.com/profiles/blogs/announcing-ard...



btw.. die diskusion mit den servos.. zwar sind wir weg von os.. futaba
hat doch auch irgend so ein bus system ?? weiss jemand wie den das geht
??

lg roman

Ja Tobias, ich denke dort irgendwo ist ja der hund versteckt..

denn, je nach optimierungs level, verschiebt sich der stack verbracht
(meinst mehr) den mehr optimierung heisst mehr die register zu nuetzen.
das problem ist, der scheduler muss ja den stack vorbereiten fuer den
task contex switch, inklusive den was vor dem scheduler auf stack war,
sie wie auch danach..
im klar text, im naked, hast du die absolute kontrolle was vorher auf
dem stack war und was danach sein wird. (ausser, man deklariert etwas
locales)
zu dem, der gcc und auch andere compiler, verwenden gewisse register
exklusiv fuer sich. da kann man tun was man will, plus sie werden nicht
gesichert...
siehe r18,19 in der naked version.. meistens findet man dies irgendwo in
der compiler beschreibung. daher ist es immer besser beim multitasking,
alle register als aller erstes auf den stack zu sicher noch bevor
ueberhaupt der scheduler aufgerufen wird (Solaris tut es so) oder gleich
in die task struktur (linux) und zwar im assembler. sind ja nicht viele
assembler commands.. und.. jenachdem .. muss man dies tun fuer alle
interupts. den.. ist das system beschaeftigt mit 1+1 rechnen und es
kommt ein interupt das zb. etwas von uart gekommen ist, auf das ein task
wartet, will man ja das dieser gleich rescheduled wird und sofort auf
die cpu kommt. oder .. man definiert ganz einfach, das kein scheduling
waerend einem interrupt statt findet. ein sehr aehnliche ansatz
verwendet linux. Die interrupts werden aufgerufen wie sie im system
registriert sind, jedoch, die device driver, resp. system setzt ein
flag, das ein rescheduling statt finden soll. nach dem alles fertig ist,
kurz vor der return from interrupt wird gepruefft ob dieses flag gesetzt
ist oder nicht.
dh. die reti springt dann gleich in einen anderen task.

ein andere weg, ist es ueber den longjmp zu arbeiten.. .irgendwo auf dem
net habe ich auch schon solch ein multitasking gesehen.

lg roman

Hi,

ich hab mal eben ne absolute minimalversion des schedulers gebaut, aus
der alles raus geflogen ist, was nicht notwendig ist. aber auch bei
dieser version bleibt es dabei...definiere ich ISR und naked, gibt es
Probleme mit Interferenzen. Aber ich bin mittlerweile so schlau, dass
ich sagen kann, wo die Interferenzen entstehen:

"Schuld" ist die Funktion wait_for_message(), denn die wartet jetzt
schlicht nicht mehr auf Nachrichten, sondern springt zurück, und zwar
unabhängig davon, ob hier eine Nachricht vorliegt oder nicht. Eventuell
ist auch die ähnlich konzipierte Funktion wait_for_semaphore()
betroffen. Und ich kann auch nicht ganz ausschließen, dass dies nicht
der einzige Fehler ist.

Na ja, bei zeiten werd ich mir mal das ASM dieser Funktionen ansehen.

Anbei der "minimal" Scheduler und das passende .s - File

Moinsens Leute,

es ist wie verhext...zur Zeit komm ich nicht dazu, an dem OS irgendwas
zu machen ;(

Ich meld mich, wenns ein update gibt.

gruß

tobi

Hallo Martin,

probiere ich gern aus.

gruß

tobi

Gibts noch weitere Ideen/Anregungen/Kommentare zu dem OS?

Grad was den Bereich Message Queue / Semaphore angeht wäre ich sehr
interessiert.

Tobias W. schrieb:
> (für die 32 GPIO-Register des AVRs)

Ohne GPIO, sind ja nur Register.

Hallo ich bin an dem neuen nanoos sehr interessiert. Ich habe da noch
eine Frage. Läuft dieses OS auch auf dem Atmega8535? Wieviel kb Ram bzs.
Rom benötigt dieses OS?

Danke Uwe.
Was ist mit SIG_PIN_CHANGE0 und PCINTxyy genau gemeint?

Für das NanoOs brauche ich doch keine Pins vom Atmega. Wenn ja warum
denn eigentlich?

jaja, geht mir auch so :-)
mein avrwiz hat >300000 hits/jahr aber 0.0 feedback...

Hallo,

ich hab das NanoOs auf meinem at90s8535 zum laufen gebracht.
Dafür habe ich zunächst nur mal zwei Tasks erzeugt, in der jeweils eine
LED zum blinken gebracht wird. Ich muss sagen, dieses OS lässt sich echt
einfach auf einen anderen AVR portieren. Gibt es für dieses OS eine
Dokumentation ?

hi leo,

welche aenderungen musstest du durchfuehren? bitte sende sie mir damit
ich sie einarbeiten kann.

eine einfache apidoku liegt im Verzeichnis software/doku.eine
vollstaendige doku folgt wenn ich zeit hab.

gruss

tobi

Hallo hacker-tobi,

ich kann dir meine Änderungen erst heute Abend sagen.
Ich habe eigentlich nur in der Headerdatei nano_os.h Änderungen
durchgeführt.
Den Timer für den Time Tick habe ich in der user.c Datei entfernt.
Hat dieses OS auch einen Pool Mechanismus? So wie es aussieht nicht.

Hallo Leo,

dann poste hier einfach mal deine Änderungen in nano_os.h

Die user.c ist hier unwichtig, denn dass ist dein user-code bzw. der
Beispielcode, und hat nichts mit dem OS selbst zu tun.

Pool:
Du meist doch nicht etwa resourcenpools, oder? So etwas auf dem AVR
umzusetzen ist nach meiner Ansicht unnötig, da man die wenigen Resourcen
gut "von Hand" verwalten kann, und Art und Anzahl der Tasks von Anfang
an bekannt sind.

Das OS verfügt über:

-preemptives Multitasking inkl. Prioritäten,
-binäre Semaphore (Mutex),
-Message Queues,
-ein einfaches Speichermanagement (basiert auf einem array im RAM) sowie
-Funktionen zur Task-Kontrolle (anhalten, löschen usw...)

nicht weniger aber auch nicht mehr ;)

gruß

tobi

Ich muss sagen, das NanoOs macht einen echt guten Eindruck.
Besser wie z.B. das femtoos.

Danke ;)

Mich würde mal interessieren, wo genau nach deiner Ansicht die
stärken/schwächen von nano_os im Vergleich zu FemtoOS liegen.
Kannst du das mal kurz zusammenschreiben?

Im Anhang befindet sich das Beispiel für den at90s8535.
Das femoos konnte ich bis jetzt nicht auf meinem at90s8535 zum laufen
bringen. Mit dem nanoos bin ich viel schnell zum Ziel gekommen.

Hallo Leo,

danke dir. Ich werd die Änderungen übernehmen, und dann ein neues File
hochladen.

gruß

tobi

Für was benötigt man das AVR Studio?

ich verwende den avr-gcc-4.3.4 in der Bash-Shell mit einem makefile.

und alles ist gut !

ich ebenso.

was genau ist denn das probmem beim avr studio?

gruss tobi

es sollte reichen wenn du nur nano_os.c in der liste der zu
kompilierenden dateien hast, und die liste der header leer ist, da die
abhaengigkeiten in nanoos.c selbst aufgeloest werden.

gruss tobi

@Bernd: funktioniert jetzt alles?

Hallo Tobi,

DANKE für Deine Nachfrage und meine Antwort ist JA.

Einige Ideen habe ich noch zum NanoOS. Wenn ich damit fertig bin, mag
ich mit Dir gerne darüber diskutieren. Deine E-Mail kenne ich ja
bereits.

DANKE und noch eine schöne Adventszeit... jetzt hier leider ohne Schnee
Bernd

immer her mit den ideen ;)

ps. nano os entstand ja mal aus einer diplomarbeit. diese wurde mit 1.3
benotet :)

damit bin ich jetzt dipl.-inf. ;) !

Danke dir, Uwe.

Hab die Änderungen in nano_os.h übernommen und es auf sourceforge
hochgeladen.

Damit sind wir jetzt bei Version 003, und supporten folgende Hardware:

Atmega32,
AtMega88,
AtMega168
At90s8535

gruß

tobi

Hab grad mal nachgesehen..Heapstart müsste 0x0460 sein, korrekt?

Der RAM beginnt ja bei 0x0060 = 96 Dez, und endet bei 0x85F = 2143 Dez.
Berücksichtigt man den offset, ist HEAPSTART = 2143 -1024 = 0x0460 Hex.

Merke HEAPSTART ist in der Regel genau SRAM/2.

gruß

tobi

Habs hochgeladen.

@Uwe: Hast du meine Änderung bezüglich HEAP_START mal testen können?

Zur Info: Ich arbeite grad an ner Displayansteuerung für Graphic
Displays (basierend auf KS-Kontroller). Ich melde mich, wenn ich da was
habe.

gruß

tobi

Hallo Tobias,
ich habe Dein OS mit win-gcc nach Anpassung der Pfade am makefile und
den "only placebo" Userfunktionen für ein mega32 mit allen Fähigkeiten
übersetzen können. Jetzt möchte ich das natürlich mit Leben füllen...
Dazu 2 verwandte Fragenkomplexe.

1. hat sich mit der Timerproblematik noch was ergeben? Ich meine damit,
wie man genaue Timer z.B. für Servos hinbekommt, die Idle- oder Task
tauglich sind. Ich hätte auch nichts dagegen, einen 2.ten Timer dafür zu
"verschwenden" wenn dieser flexibel nutzbar ist. Ich weis nur leider
nicht, wie man das passend für das OS anstellt. Schön wäre natürlich,
wenn man dem OS sagen kann: "Wecke mich alle 20ms auf" oder "wecke Task
x in 3ms" und der Task dann z.B. in Tiefschlaf geht, also auch nicht im
normalen Scheduler geweckt wird. Eine Art Timeralarmfunktion für Tasks
also, gefüttert z.B. durch eine Eventliste. Irgendwie sowas...

2. ich möchte ein TWI Treiber für das OS bauen, der per ISR Slave mode
macht. Kann ich mir da jetzt einfach ne ISR basteln oder muss ich in
Bezug auf das OS was beachten? Wenn ja, was? Gibt es vielleicht ein
Template für ISRs so wie das User File? Ist das Messagesystem geeignet
um es für die Zeichenübertragung an/von TWI bzw. an die ISR zu
flanschen?

Wie löst man hier überhaupt systemnahe oder zeitkritische Aufgaben am
besten? Als Usertask? Und dann TASK_ENTER_CRITICAL;/TASK_LEAVE_CRITICAL;
?
Ein paar Beispiele wie man das OS mit der Hardware zusammen bringt wären
nicht schlecht, und vielleicht noch ein paar Taskhandling Funktionen
bei/für Event Steuerung würden mir helfen.

LG Rolf

Hi Rolf,

ich bin grad auf Arbeit aber werde dir bis zum WE antworten!

gruß

tobi

Hallo Tobias,
das ist mir soweit klar, trotzdem suche ich eine Möglichkeit bestimmte
Tasks eventgesteuert (per Timer,INT) sofort zu wecken bzw. schlafen zu
legen wie es RT-OSe üblicher Weise anbieten - und nicht abzuwarten bis
der Scheduler den richtigen Task irgendwann weckt. Ich sehe meine
Anfrage auch als Vorschlag das OS in dieser Richtung weiter zu
entwickeln. Ich hatte mir den Source und das Uhrenbeispiel bereits
angesehen.
Aber Danke für die Antwort, ich werde sehen ob ich mit den jetzt
vorhandenen Möglichkeiten mein Ziel erreichen kann. Evtl. geht es mit
der ISR und den Queues auch.
LG Rolf

Hallo Rolf,

Dafür gibt es die Funktionen task_sleep() bzw. task_wake(), welche einen
Task schlafen legen bzw. wecken, und auch einen Taskwechsel auslösen.

Diese Funktionen sind Interrupt-fest, d.h. du kannst sie z.B. in deiner
ISR verwenden, um Tasks schlafen zu legen bzw wieder zu aktivieren.

Allerdings beeinflusst task_wake() die Reihenfolge des Schedulings
selbst nicht. Ergo kannst du einen Task sofort schlafenlegen, aber nicht
sofort wieder aufwecken. Ich habs damals nicht gebraucht, und von daher
nicht implementiert.

Dies wäre aber recht einfach implementierbar, z.B. über eine globale
Variable, in der man dem Scheduler vorgibt, welchen Task er als nächstes
anzusteuern hat.
Im Grunde müsste es sogar funktionieren, einfach active_task_id selbst
zu manipulieren, in der art

active_task_id = t-> ID -1;

innerhalb von task_wake();

Aber ich bin müde und daher ist das nur als Anregung zu sehen.

Wenn ich Zeit hab, implementier ich das gern mal. Oder du darfst es auch
gern implementieren, und ich würde es dann übernehmen, wenn du magst.

Hilft dir das weiter?

gruß

tobi

Hallo Tobias,
Danke, das hilft mir sicherlich aber ich werde Zeit brauchen um das
umzusetzen. Ich denke doch, das es dem OS viel bringen würde auch wenn
Du es vielleicht nicht selbst brauchst. Wenn man schnell auf Daten
reagieren muss (Uart mit hohen Baudraten, Encoderauswertung usw.), macht
es Sinn den betreffenden Task von der ISR aus direkt zu wecken oder man
müsste die ISR quasi "am Scheduler vorbei" viel erledigen lassen - was
wohl nicht im Sinne von ISR's und Taskswitching ist.

Ich will versuchen das OS auf einem Bot einzusetzen und da gibts erst
mal jede Menge anderer Baustellen. Danke also erst mal für die Tips.
Sollte ich es wider Erwarten vor Dir umsetzen, geb ich Dir den Code
natürlich.
LG Rolf

Das freut mich sehr, da kann man ja echt nur den Hut ziehen.
Der Compiler nimmt es auch wie ich grade getestet habe. Damit ist das OS
nun auch echtzeitfähig.
Wau... SUPER! Danke.
LG Rolf

Hast Du noch Infos zum Footprint?

Mit:

void init_user_environment(){
asm("nop"); //only placebo }
void shutdown_user_environment() {
asm("nop"); //only placebo }

und

#define TASK_USE_SLEEP
#define TASK_USE_ANHILATE
#define TASK_USE_MESSAGE
#define TASK_USE_SEMAPHORE
#define TASK_USE_MEM

komme ich auf einem mega32 zu:

Size after:
nano_os.elf  :
section            size      addr
.text              3198         0
.data                 8   8388704
.bss                419   8388712

LG Rolf

Da übersetzt du aber unoptimert, oder?
Und die user.c muss im Grunde komplett leer sein, mal abgesehen von den
Funktionsaufrufen selbst.
Ich meine, der reine Scheduler waren so 1200 Byte auf nem Mega168.

Ich werd demnächst mal alle footprints ermitteln, und auch den
Speicherverbrauch neu berechnen.

PS. Ich habe task_wake() nochmal geändert. Es gibt jetzt einen
zusätzlichen Parameter realtime, der steuert, ob sofort zu dem task
umgeschaltet werden soll, oder ob das Scheduling normal weiterlaufen
soll.

Ich habs auf Sourceforge hochgeladen.

Ich hatte -Os bzw. OPT = s
und MCU = atmega32 und sonst nur die Pfade im makefile angepasst, eine
quasi leere user.c und alle Funktionen in der nano_os.h angeschlatet.
Wie eben beschrieben. Allerings übersetzt mit der aktuellen winavr bzw.
gcc.
Mich wundern etwas eure .text Segmente mit 0 byte da bei mir dort der
Code drin liegt. Wenn ich nicht alles einschalte wie im Beispiel
vorgegeben, komme ich so auf 2,7k codesegemt. Ihr habt wohl bischen doll
optimiert oder? *lach
LG Rolf

Mit den extra Flags aus dem Makefile da, und allen bisherigen
Einstellungen komme ich auf:

Size after:
nano_os.elf  :
section            size      addr
.text               796         0
.data                 2   8388704
.bss                404   8388706

Ob der Code so stramm gezogen noch lauffähig ist, kann ich grade nicht
testen. Da aber quasi kein Usercode da ist, könnte das passen wenn der
gcc gut optimiert. Nur ist das eben auch kein realistischer Usercode.
Das Hex hat 2272 byte.
LG Rolf

Achso.. das Codesegmet liegt dort scheinbar in Data... Sachen gibts...

## Zusatz Flags
CFLAGS += -fno-inline-small-functions
CFLAGS += -fno-split-wide-types
CFLAGS += -fno-tree-scev-cprop
CFLAGS += -fno-move-loop-invariants
CFLAGS += -ffunction-sections -fdata-sections -Wl,--gc-sections
CFLAGS += -Wl,--relax
## -- ende --

Was ist von den Flags im OS zu halten? Spricht was gegen die Nutzung?
LG Rolf

Hallo Uwe,

ich brauche eigentlich nur die Einstellungen in nano_os. h für den
tiy861. Wie viel RAM/FLASH hat der denn?

Kurz zum footprint:da dies ja den reinen Bedarf des OS angeben soll,
bitte nur ohne usercode und mit verwendeten Optimizations angeben.

Ich komme mit gcc opt-level 3 auf etwa 900-2500 Byte, je nach Anzahl der
aktivierten features.
RAM-Bedarf habe ich jetzt nur grob nachgerechnet und ist auch stark von
der Anzahl der Tasks und der Feature-nutzung abhängig, aber grob lässt
sich von max. 250 Byte (alle features aktiv)

+ 9 Byte und STACK_SIZE für jeden task
+ 1 Byte für jeden Semaphor
+ 7 Byte pro Message Queue
+ x Byte für Speicherböcke, Messages usw.

ausgehen.

Der Bedarf an Rechenzeit ist natürlich vom Prozessortakt, der Anzahl und
Nutzung der Features sowie Priorität und Anzahl der Tasks abhängig.
Er bewegt sich gerechnet (also geschätzt g) im Bereich von 1% (16 MHz,
keine Featurenutzung) bis 25% (1 MHz, Features werden massiv genutzt).

gruß

tobi

Hallo Tobias,
also per default sind im include 4 Tasks eingetragen... (aber nicht
angelegt.. egal), dann hab ich meine Einstellungen schon genannt, -Os ,
mega32 , alle Funktionen enabled, als "usercode" die Nops aus dem
Beispiel-Template wie gepostet, und die Size wie sie dem Linker bekannt
sind mit text/bss Segmentangabe. Und dann einmal ohne Uwes Optionen und
einmal mit. Der Code ist ungetestet. Jetzt auch mit der letzten Version
incl. realtime == 1 Abfrage.

Da Du nach -O3 fragst, noch mal meine Werte für O3 statt -Os, alles
andere wie vorher.

Ohne Uwes CFLAGS
Size after:
nano_os.elf  :
section            size      addr
.text              3720         0
.data                 8   8388704
.bss                419   8388712

Mit Uwes CFLAGS
Size after:
nano_os.elf  :
section            size      addr
.text               856         0
.data                 2   8388704
.bss                404   8388706

LG Rolf

Nachtrag:
zum Thema Options bzw. Uwes Flags hab ich hier noch was gefunden...
http://www.tty1.net/blog/2008-04-29-avr-gcc-optimi...
LG Rolf

@Rolf/Uwe: Ich wär sehr daran interessiert zu erfahren, ob der
optimierte Code noch lauffähig ist.

Mein aktueller Code für einen atmega168 ist für die Binäruhr mit den
Features

-"Message Queue",
-"dynamic task management" und
-"Speichermanagement"

also

#define TASK_USE_ANHILATE
#define TASK_USE_MESSAGE
#define TASK_USE_MEM

mit dem original makefile genau 3608 byte groß:

section            size
.text              3600
.data                 8
.bss                  0

Hi Tobias,
Ich warte auf ein Ersatzteil aber hoffe das ich gegen Ende der Woche mit
Tests beginnen kann. Ich werde auf jeden Fall meine Ergebnisse zum Thema
Optionen posten. Bedenke aber, das man für -fno-tree-scev-cprop min. den
GCC 4.3.0. braucht. Ich könnte mir vorstellen, das mancher noch ältere
gcc Versionen preferiert. Ich nutze den gcc version 4.3.3 (WinAVR
20100110)
Da der Parameter aber NO-tree-scev-cprop heisst, denke ich das es eher
negativen Einfluß hat wenn man ihn nutzt... weil er offensichtlich was
abschaltet.
Aber das nur nebenbei.

Die Compileroptionen von Uwe scheinen mir also nicht optimal zu sein.
Wenn man -fno-split-wide-types weg lässt, spart man noch mal 4 Byte im
text Segment. Lässt man -fno-inline-small-functions weg, spart man noch
mal ganze 96 byte - vermutlich schnöde pushs/pops die ggc sonst anlegt.
Weglassen von -Wl,--relax und Anderen erhöht den Code um 6 Byte - das
einzige was wirklich entscheidend auf die Codegröße einwirkt ist:
-ffunction-sections -fdata-sections -Wl,--gc-sections, das wäre also mal
genauer zu hinterfragen.
Die -OS und -O3 machen dabei auch nur Unterschiede einiger weniger Bytes
aus.
Das auch nur nebenbei.
LG Rolf

Noch mal ich...
--gc-sections auf AVRs scheint kritisch zu sein. Da gibts wohl nen Bug
im Linker. Last Post ist von Feb 25, 2011, also aktuell.
http://www.avrfreaks.net/index.php?name=PNphpBB2&f...
Ich glaube nicht, das man das dem OS antuen sollte... Weiteres erst
gegen Ende der Woche.
LG Rolf

Hallo Tobias,
hab noch mal bischen wegen der Linkeroptions recherchiert.
Da ist im Prinzip nichts gegen einzuwenden, allerdings ist grade in
Bezug auf ISRs, Handler (anspringen über selbstgestrickten Pointer) zu
beachten, das diese nicht fälschlicher Weise vom Compiler entfernt
werden. Siehe auch:
http://www.mikrocontroller.net/articles/GCC:_unben...

D.h. die Flags entfernen Code auf Linkerlevel, der nicht direkt
angesprungen wird. Da der Code eh per #define configuriert wird, macht
das wenig Sinn mit den Linkerflags. Will sagen, die Fehler die man damit
provoziert und ggf. debugen muss, stehen für den normalen Anwender in
keinem Verhältnis zum Gewinn an Bytes da man denn unbenutzten Code auch
anders und risikoärmer entfernen kann. Es würde nur was bringen wenn man
aus einem Funktionspaket wie Messaging zwar eine Funktion nutzt aber den
Rest raus haben will.
In Einzelfällen mag das angebracht sein, allgemein würde ich das strikt
ablehnen zumal es auch um so weniger bringt, je mehr Funktionen man
aktiv nutzt. Eine feinere Granulierung von #define würde da ohne die
Fehlerquote anzuhheben mehr nutzen aber selbst da ist fraglich ob sich
der Aufwand wegen ein paar Byte lohnt. Ich sehe das nicht so.
Selbstgeschriebene Programme enthalten auch selten unbenutzen Code, aber
wers braucht... wirds sich schon selbst ins makefile einbauen können :)
Das einzige was ich für mich gern nutzen würde ist CFLAGS  +=
-Wl,--relax aber auch das scheint avr-ld wie bei -Wl,--gc-sections
zumindest nach avrfreaks.net nen Bug zu haben. @Uwe, deine Beteuerung in
Ehren...aber nen einzelnes Programm ist was anderes als ein OS - das
Leute ggf. nutzen ohne sowas noch mal zu verifizieren. Tobias tut gut
daran, sowas konservativ zu sehen.

Da Du den Mega32 schon drin hast, kannst du glaube ich auch den Mega16
noch direkt einbauen, so weit mir bekannt hat der nur einfach bissel
weniger Speicher. 16k Flash, Ramstart ist 0x60 und Ramend 0x45F, also
1KB Ram, sonst baugleich zum mega32. Ob das OS auf nem mega8 Sinn
macht... keine Ahnung.

LG Rolf

Hallo @all,

Ich denke auch, das ich das Makefile zunächst einmal so lasse wie es
ist.
Zusätzlich zu den von rolf angeführten Bedenken frage ich mich auch,
inwieweit Funktionen, welche über Pointer addressiert werden (wie z.B.
die Tasks selbst) "wegoptimiert" werden, da der Compiler deren Aufruf
schlicht nicht erkennt, und sie somit für überflüssige Funktionen hält.

gruß

tobi

Ups...vergessen:

Ich muss auch ehrlich gestehen, dass ich mich mit den Optimierungen des
gcc nicht so gut auskenne, auch von daher bin ich damit lieber erstmal
vorsichtig.

Zum Mega16...kannst du das in Hardware verifizieren? Ich habe aktuell
leider keine Mega16 da.
Der Mega8 ist auch sehr interessant!

gruß

tobi

Hallo Tobi,
nein ich hab leider kein Mega16 zum testen. Aber die Mega Serie
unterscheidet sich zwischen den 3 Typen nicht so dramatisch - sagt
zumindest das Datenblatt. Aber vielleicht ists besser zu warten bis
einer es wirklich austestet. Der mega8 ist arg klein mit 8k Flash... der
Unterschied dürfte eher im Pinout wirken (DIP 28 / 40 Pin) aber das ist
für das OS ohne Bedeutung. Der mega8 und mega16 haben je 1k Ram. Laufen
müsste das OS auch da.

http://www.atmel.com/dyn/resources/prod_documents/... / mega8
http://www.atmel.com/dyn/resources/prod_documents/... / mega16
http://www.atmel.com/dyn/resources/prod_documents/... / mega32

Hier die Datenblätter.

Als Vergleich der Mega644

http://www.atmel.com/dyn/resources/prod_documents/...

mit einer etwas anderen Memory Map.

LG Rolf

Hi,

habe den Mega8/16 mit aufgenommen und auf sourceforge hochgeladen.
Auch gibts jetzt eine Fehlermeldung, wenn ein unbekanntes device
verwendet wird, und ich habe den Parameter "STACK_SIZE" ausgelagert, da
er vom verwendeten Device unabhängig ist.

Ab jetzt gibt es dort auch ein changelog und die "alten" releases als
Historie.

Damit sind wir bei Version 0.06

gruß

tobi

@Rolf/Uwe/anybody ;)

Gibts news? Wie weit sind eure Entwicklungen? Wird noch irgend was
benötigt oder gibts bugs?

hacker-tobi schrieb:
> [..] Wird noch irgend was benötigt [..]

Benötigt nicht unbedingt, aber eine Portierung auf die AVR-XMega-Serie
fände ich echt gut.