1

Mittwoch, 23. Januar 2008, 14:20

Programm zu gross für Attiny13

Hi
Mein Programm, programmiert mit Bascom scheint zu gross zu werden. Ich habe bis jetzt ein bischen Timer und die Analyse von 2 Eingänge fertig und bin schon bei 76%.
Ich befürchte das der Platz für die eigentliche Lichtsteuerung nicht mehr reicht.

Die Fragen die ich mir und damit euch jetzt stelle:
1. Kann ich Befehle nutzen, die weniger Speicher brauchen?
Habe rel. viele If-Then Abfragen drin. Wie kann man was optimieren?
2. Wo und wie kann ich noch was im Assemblercode optimieren?
3. Würde es was bringen auf C umzusteigen (AVR-Studio)?
4. Kann man noch was optimieren was HWStack und SW Stack oder so angeht?
5. Könnte man Variablen wo anders Speichern?

Pur Assembler möchte ich nicht unbedingt.

MFG
Dany

Daniel wird beschleunigt von seiner ZZR1100

2

Donnerstag, 24. Januar 2008, 00:04

Hallo Dany,

grundsätzlich wird direkte Assembler-Programmierung wohl immer das optimalste Ergebnis liefern - aber allerdings auch nur, wenn man die Sache richtig beherrscht... :evil:
Die Compiler von C und Bascom mögen hier und da etwas suboptimaler arbeiten, aber schlecht sind sie sicher nicht und es sind auch sicher keine bahnbrechenden Unterschiede bei der Code-Größe zu erwarten.

Der Tiny13 ist halt nicht groß, da ist generell Lean Programming angesagt.

Poste doch mal Deinen Code, dann schauen wir, was noch so geht.

Viele Grüße

Torsten
[SIZE=4]www.zuendapp.net - die grösste Zündapp-Community im Internet! :ok:[/SIZE]

3

Donnerstag, 24. Januar 2008, 08:20

Hallo Torsten

Ich werde wohl auf den Tiny25 oder 45 umschwenken. Das löst das Platzproblem erstmal.

Das ganze läuft auch schon auf einem Mega8, weshalb ich den Code verstädlicherweise übernehmen möchte.
Hier ein teil des Codes, den ich auf dem Laptop habe.
Das ganze lastet den Tiny zu etwa 60-70 % aus.

Bringt es z.b. was zu schreiben

FW = 0
if XY = 1 then FW = 1

Statt

fir xy = 1 then
FW = 1
else
FW = 0
endif

Zitat


'******* Systemblinker machen
If Timermerker = 1 Then
Timermerker = 0
17ms = 1
Incr Z10ms
If Z10ms > 6 Then
Incr Z100ms
Zs = 1 ' = 10,2 ms
Z10ms = 0
End If
If Z100ms > 10 Then
Hs = 1
Z100ms = 0 '= 102ms
End If
End If

'******* Motoreingäng abfragen alle 10,2ms
If Zs = 1 Then
Shift In1cg , Right , 2 ' Gesamtzähler durch 4 Teilen
If In1c > In1cg Then 'Vergleich mit Nullenzähler
Fw = 1
Else
Fw = 0
End If
Ffw = 0
If In1c = In1cg Then Ffw = 1
In1c = 0
In1cg = 0
Shift In2cg , Right , 2 'Gesamtzähler durch 4 Teilen
If In2c > In2cg Then 'Vergleich mit Nullenzähler
Bw = 1
Else
Bw = 0
End If
Fbw = 0
If In2c = In2cg Then Fbw = 1
In2c = 0
In2cg = 0
End If

If Mot1 = 0 Then Incr In1c 'Nullen zählen
Incr In1cg 'Gesamt zählen

If Mot2 = 0 Then Incr In2c 'Nullen zählen
Incr In2cg

17ms = 0
Hs = 0
Zs = 0
Loop
'###############################################
' Subroutine für Timer
T0_isr:
'Timerhandling
Timermerker = 1
Return


In dem Timer sollte eigentlich noch ne Servoausgabe gemacht werden. das habe ich aber erstmal gestrichen weils platztechn. nicht passt.

Prinzipiell habe ich nix gegen Assembler, da ich auch SPS programmiere, aber wie ich das obige in Assembler tippen sollte ist mir nicht wirklich klar.

MFG
Dany

Daniel wird beschleunigt von seiner ZZR1100

4

Donnerstag, 24. Januar 2008, 12:40

Hallo Daniel,

poste doch bitte den vollständigen Code, die Var-Deklarationen und Einbindungen sind ja auch nicht ganz unerheblich...

Assembler hat natürlich klare Vorteile und grade bei den Risc-µC´s ist der Sprachumfang auch noch recht übersichtlich. Aber der Mensch ist eben von Natur aus faul - wenn es da doch so nette, bunte Hochsprachen-Compiler gibt, warum dann mit kryptischen Assembler-Befehlen rumhantieren? :O

Wobei mir aber nicht ganz klar ist, was Assembler mit SPS zu tun haben soll. Strukturierter Text ist doch eher an gängige Hochsprachen angelehnt... naja, AWL ist vielleicht noch etwas ähnlich, zumindest was das Kryptische anbelangt.

Was programmierst Du so? Bei mir sind es vorrangig Elau-Steuerungen (CoDeSys) und verschiedene Visualisierungen (MicroInnovation, Wonderware).

Viele Grüße

Torsten
[SIZE=4]www.zuendapp.net - die grösste Zündapp-Community im Internet! :ok:[/SIZE]

5

Donnerstag, 24. Januar 2008, 13:48

Hi

Das Programm kann ich dir erst heute abend zuschicken (will das nicht zu 100% hier reinstellen).

Ich habe das Progamm so aufgebaut, das ich mir erstmal Systemtimer mache mit denen ich dann Blinker usw aufbauen kann und für die Auswertung der Eingänge brauche.
Dann werden alle Ausgänge erstmal auf Merker gelegt, und dann ganz am Ende ausgegeben. Ich habe mich da ein bischen am Ablauf der SPSen orientiert. Ist das grunsätzlich so ok oder macht man das so garnicht?

SPS Programmiere ich S7 in FUP und AWL und ein bischen Berghoff in FUP.
Wobei das weniger Programmieren ist. Mehr gucken, wenn was nicht geht.
Gelernt habe ich auf S5 (AWL). Mit AWL komme ich sehr gut zurecht. Leider ists Scheixxe wenn man einen Fehler finden muss, da ist FUP besser, deshalb wird soweit es geht alles in FUP gemacht.
In der Schule war auch noch ein Fach Assembler und Microcontroler, fand ich beides nicht schwer.

Ich kloppe das Programm mal komplett in den Mega8 und hoffe das ich unter 4kb bleibe. wenn das passt wird halt ein Tiny45 genommen (ist ja auch nicht viel teurer).

MFG
Dany

Daniel wird beschleunigt von seiner ZZR1100

6

Donnerstag, 24. Januar 2008, 19:29

Hallo Daniel,

wenn Du alles noch über Zwischenmerker programmiert hast und Dir auch noch den Luxus separater Timer gönnst ist mir schon klar, warum Dein Tiny13 auf dem letzten Loch pfeift... :D

PAE lesen am Zyklusbeginn und PAA schreiben am Zyklusende kannst Du Dir eigentlich auch schenken, nein, das wird so definitiv nicht gemacht. Ich fürchte, da bleibt Dir nix anderes übrig als ein wenig knackiger zu programmieren.

Ist nun mal keine SPS, der Kleine - und darüber können wir auch froh sein!

Mit einer SPS wertest Du jedenfalls so schnell keinen R/C-Kanal aus - ich kenne zumindest keine, die Zeitmessungen im Mikrosekundenbereich beherrscht. Meist ist ja der Programmzyklus schon mehrere ms lang... zzz

Viele Grüße

Torsten
[SIZE=4]www.zuendapp.net - die grösste Zündapp-Community im Internet! :ok:[/SIZE]

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Torsten_G« (24. Januar 2008, 19:30)


7

Montag, 28. Januar 2008, 12:01

Hallo

Danke erstmal für die Tips von Torsten

Den durschschlagenden Erfolg hats leider nicht gebracht. Ich werde auf nen Tiny45 umschwenken.

Folgende Sachen haben wir optimiert.

Zitat


''***** Ports definieren
Schreib statt der ganzen Configs mal versuchsweise direkt ins Register:
ddrb = &H00111001

Config Portb.0 = Output
Config Portb.1 = Input
Config Portb.2 = Input
Config Portb.3 = Output
Config Portb.4 = Output
Config Portb.5 = Output

Das bringt
normal 1422 dec zu 1414 dec
optimiert 1212 dec zu 1204 dec

Dann die Variabelndeklaration

Zitat



Dim 17ms As Bit , Zs As Bit , Hs As Bit, 'Systemmerker
Dim Timermerker As Bit, 'Timer undso
Dim Fw As Bit , Ffw As Bit , Bw As Bit , Fbw As Bit 'Forward/Backwardmerker
Dim Mbrlicht As Bit , Mstlicht As Bit 'Lichtmerker
'Bytes
Dim Z10ms As Byte , Z100ms As Byte
Dim M0 As Byte , Mb As Byte , Modus As Byte
Dim Blint As Byte , Blpwm As Byte , Stlint As Byte

Hier der Tip von Torsten:
Versuch mal, ein Systembyte bitweise aufzudröseln:
DIM Sysflag as byte
und an die Bits kommst Du wie bei den Ports auch:
Sysflag.0 = Irgendwas

Was mich aber echt verwundert, ist, das Bascom im Report immer 8 Bit mit einer Hex Adresse deklariert, als ob er selbstständig immer 8 Bit in einem Byte speichert. Kann das sein?

Wenn sonst noch jemand Ideen hat, dann nur raus damit

MFG
Dany

Daniel wird beschleunigt von seiner ZZR1100

8

Dienstag, 29. Januar 2008, 00:58

Sich wegen 30cent pro Chip jetzt soooo anzustrengen halte ich für unnötig.
Nimm den 45er und gut is ;)

Grüße
Malte

Space

RCLine User

Wohnort: Hasloh b. Hamburg

  • Nachricht senden

9

Dienstag, 29. Januar 2008, 16:21

Die Option $noramclear am Programanfang bringt noch nennenswerte bytes.

An der Variablen Deklaration kann man nichts sparen. Der Compiler nutzt die Deklaration beim kompilieren ja nur als Verweis auf eine Speicheradresse welche er dann direkt in die Adresse übersetzt.

Bitvariablen kosten Programmspeicher. Wenn mit Flags gearbeitet werden soll, dann einfach ein ganzes Byte vorsehen (wenn SRAM vorhanden).

Für den ISR mit der Option NOSAVE arbeiten.
Da einem das um die Ohren fliegen kann, sollte man wissen welche Register im ISR von Bascom wirklich verwendet werden und somit gerettet werden müssen. Am einfachsten geht das mit einem AVR Disassembler. Die ISR Routine mit 2-3 markanten "nop" einklammern, also 3 hinter dem Sprungziel und 3 vor dem Return, und suchen welche Register innerhalb der Markierung im Dissasemblat wirklich verwendet und mittels PUSH POP gerettet werden müssen.

Aber grundsätzlich bin ich Maltes Meinung. Der Aufwand lohnt für einen Hobbybastler mit Kleinststückzahlen nicht.

Thomas
Gruß

Thomas

10

Mittwoch, 30. Januar 2008, 12:10

Und wenn man WIRKLICH Bytes sparen will, führt an Assembler (am besten mit Erfahrung im Bytefrickeln) kein Weg vorbei.

Grüße
Malte

11

Mittwoch, 30. Januar 2008, 13:31

Moin.

Ich lerne noch, und will gerne mehr wissen.

Von den Tips von Space habe ich auf Anhieb erstmal nur 20 % verstanden, aber ich werde das mal testen und ein bischen nach den Begriffen googlen.

Mich hat verwundert, das man mit den Tinys Motorregler bauen kann, aber ich dann nichtmal den Code für so ne popelige Lichtsteuerung drauf bekomme.
Ausserdem interessiert es mich wie man Sachen vereinfachen kann um Platz und Zeit zu sparen.

Hätte ja auch können sein, das man, wenn mans in C schreibt nochmal ordentlich was an Platz spart, weil man sich dann einge Sachen sparen kann ( Und-vergleiche statt if-abfragen oder sowas).

Wie auch immer, die Tiny45 werden demnächst bestellt und dann habe ich wohl auch genug Platz für weiteren Schnickschnack.

MFG
Dany

Daniel wird beschleunigt von seiner ZZR1100

12

Mittwoch, 30. Januar 2008, 19:21

Nun ja, die Motorsteller gehen mit Würgen in einen Mega 8, der 8KB Code aufnehmen kann

Die Optimierungsmöglichkeiten mit Bascom sind doch arg beschränkt, mit C hat man zwar schon mehr Möglichkeiten und bessere Kontrolle, allerdings ist je nach Aufgabe Assembler noch mal nur halb so groß.
Was man mit Assembler auch spart ist der Overhead von ca 200Bytes (wenn ich recht entsinne), der schon für ein leeres C-Programm generiert wird.

Grüße
Malte