WinAVR und INT Priorität?

Muessen tut man gar nichts ;-) Zum Daten reinbrennen tut es doch auch das CLI-Tool avrdude.

Gruß, Micha

Keine Ahnung :) So tief bin ich nicht eingestiegen. Naja, mal sehen, ob ich dieses WE die Nummer durchziehe...

-ras

--

Ralph A. Schmid

http://www.schmid.xxx/ http://www.db0fue.de/
http://www.bclog.de/

s.u. Hab 40 Jahre härteste Echtzeitanwendungen gemacht, bei denen teilweise nicht mal Zeit/Platz/Geld für ein herkömmliches Betriebssystem möglich war. X sehr spezifische Mini-OS fabriziert. Grösste war mal was, bei der ich statt ca. 512 Stck. 8031 diese mit 32 RTX2000 ersetzt hab. War ne Rohrprüfanlage für Mannesmann, wo der ganze Krempel auch noch direkt im/überm Rollgang montiert war. Dreck, Wasser, Staub, Hitze, Lärm, Stösse und Vibration. Man gönnt sich ja sonst nix. Das ganze übrigens ohne ICEmulatoren (gabs damals nicht, bzw. 512 davon unbezahlbar und nicht positionierbar...) Kostentreu und Termintreu inkl. excellenter Wartbarkeit geliefert! Das Anlagensystem ist 20a lang gebaut worden, bis es endlich etwas vermeintlich besseres gab, was nicht mehr nach Allinger roch :)

Nein, die Kunden waren nicht so begeistert von dem neuen System und mehrere haben noch Nachbauten des alten verlangt :) Besonders der TÜV, der solche (etwas kleinere) RTX Systeme für die Reaktor_Wiederholungsprüfung benutzte. Einige sind auch zum Wettbewerb, aber waren da auch nicht zufrieden.

Was Du beschreibst, ist ok. Segelt bei mir unter einem einfachen IR gesteuerten Multitasking System. Background_task für zB. Bedienerdialog, Ablaufsteuerung etc. Foreground_task zur Abarbeitung des Ringbuffers und eben der ISR für die Füllung des buffers und ggf. Anstoss der FGtsk.

Das kann schon etwas kompliziert werden. Besonders wenn Du mehrere IR hast und mehrere FGtasks. Wenn ich die Freiheit hatte, dann hab ich das lieber mit einem kooperativen Multitasker geregelt (FORTH rulez) als mit IR-gesteuertem Kontextwechsel.

Das man IRS sauberst programmieren muss, ist selbstverständlich.

Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang

--
Wolfgang Allinger, anerkannter Trollallergiker :) reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
(lt. alter usenet Weisheit)

Ich hab mich auch erst gegen arvdude gesträubt und mit Ponyprog gearbeitet. Wenn man es erstmal probiert hat, geht es mit avrdude wesentlich besser. Man kann auch den brun-o-mat als Windows-Bedienoberfläche dazunehmen.

Gruß

Stefan

Es geht auch noch anders, timer IRS schön gleichmässig lang machen und Aufgaben darin abhampeln mit verschiedenen Zeitscheiben. Hab das mal für AEG 60/10 gemacht. 90% der Rechenzeit wurde in der 10ms Timer IRS verbracht: 10ms Aufgaben, 100ms auf 10x10ms, 1sec auf 10x10x10ms usw... In der Background Schleife wurde dann nur noch die Bediener E/A gemacht... Hab mit Speicheroscar das über Tage kontrolliert, 10ms IR dauerte 9..9,3ms, genau wie berechnet. Damals musste man die Kunst Assembler und Befehle zählen gut beherrschen.

Die AEG (damals Konzernmutter) hat bis zum Schluss nicht begriffen, was ich aus deren Scheixxkiste rausgeholt habe.

Sehe ich etwas anders. Ein KoopMT ist das nicht, aber egal, wir meinen vermutlich das gleiche.

Nö, FORTH ist eine extrem nützliche Schicht, da Du interaktiv auf dem Ziel arbeitest:

Bei C hat der Programmierer den Compiler im Kopf, bei Forth hat der Programmierer den Compiler im Target :)

Alte Forth Weisheit.

Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang

--
Wolfgang Allinger, anerkannter Trollallergiker :) reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
(lt. alter usenet Weisheit)

Man muss sich ansonsten halt einmal durch die man page arbeiten. Ich habe danach einfach eine zusaetzliche Rule ins Makefile reingeschrieben und seither geht das so: ISP-Kabel einstecken und 'make upload' ausfuehren - fertig. Weniger Bloat duerfte kaum moeglich sein.

Micha

So ist es. Aber eben auch genau das richtige, um etwas schwachbrüstige Hardware bis an die Grenze des damit physikalisch Möglichen auszunutzen.

In der Tat, ein System aus mehreren solcher ISRs ist so ziemlich das komplizierteste und fehlerträchtigste, was einem passieren kann. Definitiv keine Projektkategorie für Einsteiger.

Lustigerweise ist ein System solchen ISRs im Prinzip nix anderes als ein kooperatives MT. Es spart allerdings einen Abstraktionslayer und ist demzufolge um genau den Overhead dieses eingesparten Layers schneller.

Im übrigen wüßte ich nicht, inwiefern FORTH daran etwas ändern können sollte. Ist nur noch eine unnütze Schicht mehr zwischen dem, der weiß, was er will und der Hardware, die das dann tun soll...

Doch. Ich klicke bloß auf ein Icon im AVR Studio. Ein kleines Programm ist dann schon im AVR, während du noch den Parameter für make eintippst...

Aha, ein 743 MB großer Installer mit IDE und GUI qualifiziert sich jetzt also schon als "weniger Bloat". Interessante Perspektive.

Gruß, Johannes

Also der Installer meines Studio hat ca. 120MB. Und ich habe ihn genau einmal installiert, was ca. 5 Minuten gedauert hat und wonach es dann doch tatsächlich satte 0,01% meiner Festplatte belegt hat.

Installiert habe ich also einmal, geflasht hingegen habe ich sicher schon viele tausend Mal, sagen wir mal 5000. Nehmen wir mal an, ich hätte bei jedem dieser Flashvorgänge etwa eine Sekunde gespart, wären das also 5000s. Davon ziehen wir mal die 300 Sekunden für's Installieren ab, dann habe ich immer noch 4700s gespart. Trotz "bloat".

Mal ganz abgesehen davon, daß ich in dem Ding auch die Software schreibe und sie sogar vernünftig debuggen und immerhin einigermaßen brauchbar simulieren kann.

Ack.

Gegenueber was? Also wenn du damit andeuten willst ich brauche 1s, oder noch schlimmer eine Sekunde laenger, um "make upload" aus der History meiner Shell zu holen (gegenueber auf einen Button zu klicken), dann fasse ich das als Beleidigung gegen mich und meine Cherry auf ;-)

Nimm was du willst, ich will dich doch nicht bekehren. Der OP hat sich aber ueber die fette Software beschwert und wollte nur ein Image in den Chip brennen, von Programmieren und Debuggen war da keine Rede. Und genau dafuer ist avrdude gemacht worden und perfekt geeignet, das kann und soll keine Eier legen.

Und wer unbedingt drauf klicken will, der kann sich ja ein Script auf einen Button seines Window managers legen (oder meinetwegen auf eine Kachel bei Windows 8).

Micha

Am 19.09.2012 17:37, schrieb Heiko Nocon:

Das Studio6 ist aber übertrieben lahm geworden (besonders beim Start). Das ganze erinnert mich langsam an Xilinx ISE WebPACK. So langsam hätte ich auch lieber ein Kommandozeilenprogramm, welches "production elf" unterstützt.

Am 20.09.2012 09:59, schrieb Michael Baeuerle:

Kann aber keine "production elf"s brennen oder?

Heiko Lechner schrieb:

Das Makeskript konvertiert das ELF-Binary üblicherweise mit objcopy ins .hex bevor das avrdude-Kommando aufgerufen wird, oder worauf willst Du hinaus?

Gruß Henning

AFAIK unterstuetzt avrdude selbst kein ELF. Aber das was es haben will kann man ja automatisch aus dem ELF-File erzeugen lassen.

Aus dem GCC faellt ja auch erstmal ein ELF-File raus. Ich lasse das Ganze von make etwa so erledigen:

---------------------------------------------------------------------- # Start of '.bootloader' section (byte address) BOOTADDR = 0x1F800

# Directories INCLUDE = ./include BINDIR = ./bin

# File names TARGET = $(BINDIR)/firmware.elf FLASH_IMAGE_HEX = $(BINDIR)/flash.hex EEPROM_IMAGE_HEX = $(BINDIR)/eeprom.hex

# Target MCU TARGETMCU = atmega1281

# AVR C compiler AVR-CC = avr-gcc

# AVR C compiler flags AVR-CFLAGS = \ -I$(INCLUDE) -mmcu=$(TARGETMCU) -O3 -pipe -std=c99 \ -Werror -Wall -W -Winline -Wmissing-prototypes -fasm

# Converters CONV1 = avr-objcopy

# Flags for converters CONV1FLAGS = -Oihex

# Upload tool ULTOOL = avrdude

# Flags for upload tool ULTOOLFLAGS = -p $$MCU -P /dev/ppui0 -c stk200 -E noreset -V \ -U flash:w:$(FLASH_IMAGE_HEX):i \ -U eeprom:w:$(EEPROM_IMAGE_HEX):i

# Complete build (without documentation) all: $(FLASH_IMAGE_HEX)

# Upload to MCU upload: @echo @echo "Upload firmware to MCU ..." MCU=`echo $(TARGETMCU) | sed -e s/atmega/m/1 -e s/attiny/t/1` ; \ $(ULTOOL) $(ULTOOLFLAGS)

# Create memory images in Intel HEX format $(FLASH_IMAGE_HEX): $(TARGET) $(CONV1) -R .eeprom $(CONV1FLAGS) $(TARGET) $(FLASH_IMAGE_HEX) $(CONV1) -j .eeprom --change-section-address .eeprom=0x0000 \ $(CONV1FLAGS) $(TARGET) $(EEPROM_IMAGE_HEX)

# Create firmware binary #

$(TARGET): $(OBJS) $(AVR-CC) $(AVR-CFLAGS) \ -Wl,--section-start,.bootloader=$(BOOTADDR) \ -Wl,--defsym=__heap_start=0x802200,--defsym=__heap_end=0x80FFFF \ -Wl,-u,vfprintf -Wl,-Map=$(TARGET).map,--cref \ $(OBJS) -lprintf_flt -lm \ -o $(TARGET)

----------------------------------------------------------------------

Wenn man einfach "make" macht entstehen so das ELF-File und die HEX-Files. "make upload" brennt dann hier absichtlich keine Fuses und macht kein Verify, fuer die Produktion wuerde man das aendern und die Rules zum Erstellen des ELF-Files weglassen. Das Funktionsprinzip bleibt das gleiche.

Micha

Am 20.09.2012 12:20, schrieb Henning Paul:

Ich schreibe Fuses und Lockbits mit in das elf. Sieht dann ca. so aus:

#ifdef NDEBUG #include #endif

FUSES = { // .low = (FUSE_CKSEL3 & FUSE_SUT1), // .high = (FUSE_BODLEVEL0 & FUSE_BODLEVEL1 & FUSE_EESAVE & FUSE_SPIEN), // .extended = EFUSE_DEFAULT, };

LOCKBITS = (LB_MODE_3);

Am 20.09.2012 12:22, schrieb Michael Baeuerle:

Siehe meine vorige Antwort an Henning- geht das auch mit Fuses und Lockbits?

Am Thu, 20 Sep 2012 12:37:43 +0200 schrieb Heiko Lechner:

Ja, mit Parameter -U efuse:w:$WERT:m und -U lock:w:$WERT:m. Siehe man page. Dann reicht man die Werte als Konstante rein, für Skripte auch als Parameter.

Marc

Am 20.09.2012 13:42, schrieb Marc Santhoff:

Wie bekomme ich vorher die Fuse- und Lockbits aus dem elf heraus?