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
Uwe hat mir per Mail mitgeteilt, dass die Änderungen funktionieren.
Damit läuft Nano OS jetzt auf folgenden yC's:
Atmega32,
AtMega88,
AtMega168
At90s8535
Ich habs auch mal in der Code-Sammlung verlinkt.
gruß
tobi
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
So,
jetzt die versprochenen Antworten:
1.)
Du kannst einen 2. timer benutzen; Das OS selbst belegt ja lediglich
timer0.
Auch gibt es eine Funktion task_sleep_for_laps(), welche einen Task für
eine definierte Anzahl an aufrufen aus dem Scheduling nimmt. Die länge
einer solchen Aufrufrunde ist fest, wenn nicht irgendwo das Multitasking
(z.b. mit TASK_ENTER_CRITICAL) unterbrochen wird.
2.)
Du kannst mit einer ISR arbeiten. Dabei musst du allerdings bedenken,
das die ISR Interrupts und damit das Multitasking unterbricht, während
sie abgearbeitet wird.
Die abgefragten Daten kannst du in eine Message Queue schreiben und sie
von dort später wieder auslesen. Genau dafür ist das Queuing ja da.
3.)
Die Programmierung jeder Art von Aufgaben erfolgt genauso, wie bei der
Programmierung ohne Multitasking, mit dem unterschied, dass der Code
hier in einen Task verlagert wird.
Sind Aufgaben zeitkritisch, kann das Multitasking mit
TASK_ENTER_CRITICAL (unterbricht alle Interrupts) oder
MULTITASKING_DISABLE (unterbricht nur das Multitasking) unterbrochen
werden.
Im nano_os quelltext (https://sourceforge.net/projects/nanoos/
) ist in user.c ein Beispiel für eine Binäruhr enthalten, welche Tasten
per ISR abfragt, LEDs über separate Tasks steuert und Timer2 zur
Zeitberechnung nutzt.
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
Hi,
ich habe die Funktionalität implementiert und getestet.
task_wake() schaltet jetzt direkt zum aktiven task um und aktiviert
diesen.
Zusätzlich gibt es eine neue Funktion task_switch(), welche zu einem
bereits aktiven Task umschaltet.
Die neue Version liegt auf Sourceforge bereit.
Anbei ein Beispiel der Binäruhr, welches task_wake() und task_sleep()
unter Einbeziehung von ISR implementiert.
gruß
tobi
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
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.
Hallo Tobi,
ich habe deine aktuellen Quellen bei mir übersetzt und eine (fast) leere
user.c/.h verwendet.
Das Makefile hat noch weitere optimierungs Parameter erhalten !
atmega168
$ avr-size nano_os.hex
text data bss dec hex filename
0 744 0 744 2e8 nano_os.hex
atmega88
$ avr-size nano_os.hex
text data bss dec hex filename
0 692 0 692 2b4 nano_os.hex
atmega32
$ avr-size nano_os.hex
text data bss dec hex filename
0 712 0 712 2c8 nano_os.hex
Hallo Tobi,
den atTiny861, habe ich auch eben noch eingebaut.
Die Quelldateien sende ich Dir noch zu.
atTiny861
$ avr-size nano_os.hex
text data bss dec hex filename
0 526 0 526 20e nano_os.hex
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 Rolf
ich habe bei meine Atmel Projekten lange mit den Compiler- und
Linker-Flags gespielt, bis ich eine minimale Codegröße erreichte.
Der Link kann nun Daten und Codesegmente löschen, die nicht benötigt
werden.
Somit ist bei meinem Angaben einer Codegröße nur wirklich der Code
aufgeführt, der auch aufgerufen wird.
Hier zum Vergleich die Angaben für den atTiny861:
$avr-size nano_os.elf
text data bss dec hex filename
516 2 402 920 398 nano_os.elf
$avr-size nano_os.hex
text data bss dec hex filename
0 518 0 518 206 nano_os.hex
Hier die Makefile Erweiterung zur Optimierung:
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
@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
Und jetz wieder ich ;)
Habe die Anpassungen für den Tiny861 überprüft und mit aufgenommen.
Damit sind wir bei Version 0.05 und supporten folgende Prozessoren:
Atmega32,
AtMega88,
AtMega168
At90s8535
AtTiny861
Das neue File liegt wie immer auf Sourceforge.net
http://sourceforge.net/projects/nanoos/
Die Compiler-Optimierungen kann ich selbst auch frühestens am WE testen.
So lange hier nicht geprüft ist, dass der Code unter allen Umständen
funktioniert, übernehme ich sie noch nicht ins Makefile.
Noch mal zum Tiny861. Ich hab mir mal das Datenblatt angesehen. Reich
bestückt mit Timern ist er ja nicht grad...da das OS einen Timer
braucht, stellt sich die Frage, ob es sinnvoller ist, beim 861 den
Timer0 oder Timer1 zu nutzen:
-Timer 0 ist 16 Bit-fähig, aber bietet weniger Features und weniger
Compare Register
-Timer1 ist ein reiner 8-Bit-Timer (was für nano_os reicht), bietet aber
mehr features (die bei Nutzung für nano_os verloren gehen).
Wie seht ihr das?
gruß
tobi
BTW: Wer hat lust auf sourceforge einen review zu schreiben... ;)
Hallo Tobias,
danke für die Umsetzung, der atTiny861 hat eine PLL für die PWM-Kanäle
und drei PWM, die sollten erhalten bleiben.
Keine Angst mit den Linkeroptionen, ich arbeite nur damit und bisher
läuft jeder Code und alle Programme die ich damit übersetze !
Siehe: Beitrag "Jumbo-LED Uhr"
.
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:_unbenutzte_Funktionen_entfernen
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
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
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.
hacker-tobi schrieb:> @Rolf/Uwe/anybody ;)>> Gibts news? Wie weit sind eure Entwicklungen? Wird noch irgend was> benötigt oder gibts bugs?
Vielleicht könnte man mal das includieren von *.c files rausnehmen. Oder
gibt es einen vernünftigen Grund dafür?
Hallo @all
Hm... neues gibts wenig - mir fehlt etwas die Zeit aber das gibt sich
hoffentlich. Zum Thema .c includieren, ich hab da kein Problem mit und
hätte ich eins, würd ich mir vielleicht die includierten c-files nach .h
umbenennen und gut is. Was ich jedoch anregen möchte ist eine kleine
Internetpräsenz für das OS. Muss ja nicht mal umfangreich sein aber es
würde sicherlich mehr Aufmerksamkeit geben und man kann auch besser die
"Fan-Gemeinde" betreuen und bei Bedarf ausbauen.
Sich die Facts hier in dem Thread zusammen zu suchen ist zwar auch ok
aber besser ginge das sicherlich strukturiert auf einer Webseite. Is
aber nur eine Idee denn ich hab keine Ahnung, wie viel Dir an der
Verbreitung des OS gelegen ist bzw. wieviel Zeit Du da investieren
kannst/willst.
Ich hoffe, ich komme in den nächsten 2 Wochen dazu, das i2c an das OS zu
flanschen.
LG Rolf
Hi,
das Thema c-Files includieren gab es oben irgendwo schonmal.
Ich lasse das bis zum nächsten major Release so wie es ist, denn es
funktioniert problemlos, und ich hab momentan ehrlich gesagt keine Lust,
da jedes File nochmal anfassen zu müssen.
Wenn nochmal ein major Release ansteht, nehm ich es in dem Zug aber mit
auf.
Eine Internetpräsenz gibt es doch:
http://sourceforge.net/projects/nanoos/
Dort findet man alle Files, eine kurze Erläuterung sowie die Features,
einen Bugtracker und release Notes.
Auch Erfahrungsberichte können dort hinterlassen werden, worum ich jeden
herzlich Bitte!
Zum Thema mit den c Files Includieren, das hab ich gelöst. siehe Anhang
Wenn ihr es verwenden wollt ok, der svn ist ja noch leer ;-)
sonst weg damit.
Compilieren tut es mit WinAVR (gcc 4.3.3) und auch MVHTools (gcc 4.5.2)
viel spass
Hallo,
Ich sehe mir gerade die Änderungen von Achill an.
Ich bekomme hier 2 Warnungen, das
init_user_environment() und shutdown_user_environment()
keine Prototypen wären, durch ein
#include "nano_os.h"
#include "user.h"
in user.c lässt sich das umgehen. Dann hab ich in nano_os.h die Zeilen:
//+++++++++++++++++++++GLOBAL DEFINE+++++++++++++++++++
/* set in Makefile !
...
*/
gefunden, im Makefile werden sie nicht gesetzt, auch im Makefile von
Sourceforge tauchen sie nicht auf. Es leuchtet mir zwar der Sinn ein,
die Defines projektabhängig ins eigene Makefile zu packen aber dann
sollten die auch im Beispiel makefile - ggf. auskommentiert -
auftauchen, oder?
Ich hab mir das Ganze jetzt noch im AVR Studio 4 geladen und es scheint
alles gut. Leider bin ich mit meinem Projekt noch nicht viel weiter
gekommen.
Ich bin auf den Grafiktreiber gespannt
LG Rolf
Hi,
ich wolltemal hören,wie der Stand der NanoOS-Projekte so ist.
Zwischendurch bin ich etwas weitergekommen; Das Display-board ist
fertig. Aktuell sitze ich grad an dem Treibermodul.
gruß
tobi
Welchen Vorteil bringt ein solches Multitasking-OS auf so kleinen
Controllern, welche Art von Anwendungen sollen es sein die ein solches
voraussetzen? Ist die klassische Programmierung via Interrupts nicht
viel effektiver? Ein Timer-Interrupt für periodische Aufgaben und
diverse Geräteschnittstellen-Interrupts sind sehr viel sparsamer und
auch schneller, ersparen oft genug sogar ein eigenes Hauptprogramm als
dritter Arbeitsebene. Der große Overhead eines solchen OS, die ständigen
Datenkopieraktionen zur Registersicherung erzeugen vor allem eines:
Wärme...
Hallo Max,
entschuldige die späte Antwort. Ich hab das OS damals geschrieben, um zu
beweisen, das es geht. Praktische Anwendung hat es bei mir z.B. in Form
von Multifunktionsuhren gefunden, bei denen mehrere Tasks gleichzeitig
abgearbeitet werden (z.B. Erfassung der Position, Auslesen von
Infrarotdaten usw für eine Propelleruhr).
Da das OS auch cooperative Multitasking beherrscht, kann ein Task bei
Bedarf auch beliebig lang laufen, oder Rechenzeit vorzeitig abgeben, was
es sehr flexibel macht.
Zusätzlich bestehen Kommunikationsmöglichkeiten, wie z.B. Semaphore.
Auch komplexere Architekturen, wie z.B. Treiber mit einheitlicher
Schnittstelle wären denkbar.
gruß
tobi
Nach langer Zeit geht es weiter.
Zunächst einmal habe ich den Code nur auf die aktuelle AVR-LIBC
angepasst.
Dafür waren nur wenige Anpassungen notwendig.
Derzeit denke ich über weitere Funktionen nach, z.B. counting Semaphore.
Besteht denn von anderer Seite Interesse oder Badarf?
Falls ja schreibt einfach.
gruß
tobi
Hey!
Hab jetzt in der Vielzahl der Threads keinen Download oder Link zur
Veröffentlichung deiner Diplomarbeit gefunden. Gibt es diesen schon,
hast du deine Diplomarbeit bereits veröffentlichen können?
Würde mich sehr freuen, wenn ich deine Arbeit lesen könnte!
Grüße
M
hacker-tobi schrieb:> Die user - Software ist hiervon> ausgenommen.
Das geht nicht. Wenn die lib GPL ist dann muss alles was dagegen gelinkt
wird ebenfalls unter die GPL fallen.
Nimm lieber die LGPL mit zusätzlicher static linking exception Klausel
(zum Beispiel so wie die Runtime von FreePascal lizenziert ist, denn die
wird auch statisch gelinkt, aber die damit gelinkten Anwendungsprogramme
sollen in jedem Falle unberührt von jeglicher Lizenz bleiben.
Lizenzwahl ist nicht ganz ohne und Du solltest das genau bedenken um
nicht den potentiellen Anwendern unnötige Steine in den Weg zu legen,
ihnen Rechtsunsicherheiten oder andere Kopfschmerzen zu bereiten.
Hi zusammen,
das Thema ist 6 Jahre alt.
@Mathias: Ich wüßte nicht mal mehr, ob ich die Arbeit veröffentlichen
dürfte. Die habe ich vor etwa 5 Jahren abgegeben. Das müßte ich erst bei
der Hochschule erfragen und der Aufwand erscheint mir etwas zu hoch,
zumal ich dort keinerlei Kontakte mehr habe.
@Bernd:
"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."
Das bezog sich glaube ich darauf, das er mir nicht mitteilen braucht,
wenn er die User Software anpasst. Ansonsten hast du aber recht .
Thread beobachten
Seitenaufteilung abschalten