EEPROM schreiben lesen

ah ja das im datenblatt habe ich soeben auch gefunden gehabt, nur hilft 
mich dar gerade nicht zuu viel. Gibts da nicht auch irgendiwe so ein 
Tutorial wie das AVR-GCC-Tutorial? Da würde meinem Verständnist stark 
helfen!

Zu Assembler: Grundsätzlich will ich das schon noch lernen, aber jetzt 
erstal uss ich C richtig lernen und beherrschen. Und da der Tiny13 nicht 
mehr als dieses geteilet Sinussignal erzeugen soll, hab ich kein problem 
mit mangeldem Speicher denke ich.

Hi

Du solltest dir aber bewusst sein, dass der EEPROM-Zugriff nicht gerade 
der schnellste ist.

MfG Spess

Hi, ich hatte sowas mal für einen Tiny25 gebastelt, allerdings die Werte 
nicht im EEPROM (Quelltext anbei).

Würde ich nur heute anders machen, bastel dir einfach einen Schwingkreis 
(LC) mit der gewünschten Resonanzfrequenz, den du mit einer einfachen 
PWM der gewünschten Frequenz pulst.

Grade mal versucht auf einem Tiny13 zu kompilieren:

1. TIMSK heisst dort TIMSK0
2. Sind es zu viele Werte für den Speicher.
   (Nur die Hälfte der Sinuswerte nehmen und spiegeln!)


Idee zum EEPROM:

1

 OCR0A = eeprom_read_byte(counter);

Setzt vorraus das die Sinuswerte ab 0x00h im EEPROM liegen, allerdings 
ist dieser NICHT schnell genug um die Daten in der ISR zu liefern!

Uhu Uhuhu wrote:
> Du wirst dich wundern, wie schnell der Tiny13 voll ist...

Ohne jetzt einen Glaubenskrieg (ASM vs. C) anzuzetteln, aber das Problem 
ist diesmal wirklich das DATA Segment und da wirst du nix mit ASM dran 
optimieren können, 64 Byte bleiben 64 Byte und da bekomme zumindest ich 
nur 64 Byte rein^^


PS: Nach Anpassung mit Spiegelung in C:

Program:     234 bytes (22.9% Full)
(.text + .data + .bootloader)

Data:         41 bytes (64.1% Full)
(.data + .bss + .noinit)

Hey super Danke euch.

Den Code von Tim T. finde ich Spitze! Danke!
Zur Arraylänge kann ich sagen, dass die sich vierteln lässt, da ich ja 
mit sin(0) -> sin(90) -> sin(0) schon wieder ne halbwelle habe.
Die Idee mit dem EEProm hatte ich nur um eben den Flash zu entlasten, 
aber wenn das passt, dann ists mir so auch lieber.

Zu meinem Verständis hätte ich aber doch noch ein paar kleine Fragen:
(auch wenn ich den EEPROM in diesem Projekt dann also doch nicht nutzen 
werde will ich doch etwas über ihn lernen...)

-Ihr sag der EEPROM sei zu langsam. Ist denn der Flash schneller, oder 
wird das Array automatisch in den SRAM abgelegt?
- Wie schnell ist denn der EEPROM überhaupt?

-Und allgemein zum EEPROM. Den muss ich ja nicht bei jedem programmstart 
neu schreiben bzw. würde das ja auch keine entlastung für den 
Flash-Speicher sein. Also wie bekäme ich das Array in den EEPROM? Muss 
ich da erst ne Software drauflasen, mit der ich über RS232 o.ä. in den 
EEPROM reinschreibe und dann neu Flashen mit der Software die das dann 
nutzt oder wie ginge sowas in meinem Fall?

gast wrote:
>Zur Arraylänge kann ich sagen, dass die sich vierteln lässt, da ich ja
>mit sin(0) -> sin(90) -> sin(0) schon wieder ne halbwelle habe.
Klar, das kann man mit ner Viertelperiode machen, wird nur wieder etwas 
aufwändiger.

>Die Idee mit dem EEProm hatte ich nur um eben den Flash zu entlasten,
>aber wenn das passt, dann ists mir so auch lieber.
Da das Programm sonst nur 2 Byte im Data Segment belegt, bleiben dir 62 
Byte. Im EEPROM hingegen hast du volle 64 Byte, lohnt also ansich nicht.

>Ihr sag der EEPROM sei zu langsam. Ist denn der Flash schneller, oder
>wird das Array automatisch in den SRAM abgelegt?
Ja der Flash ist schneller und nein, es wird vorher nicht ins SRAM 
kopiert.

>Wie schnell ist denn der EEPROM überhaupt?
Der Zugriff dauert afaik 4 Takte, aufs Flash 2 Takte. Demnach halb so 
schnell. Sollte aber solange du mit CPU-Takt/8 die PWM benutzt gehen, 
sonst könnte es bei großen OCR0A Werten (z.B. 254) Probleme geben da vom 
Compare(254) bis zum Update (255) der OCR0A noch keinen neuen Wert hat.
Ergo ist meine Aussage oben, das der EEPROM nicht schnell genug für die 
Verwendung in der ISR ist, zumindest beim reinen Lesezugriff, als 
relativ zu betrachten^^

>Und allgemein zum EEPROM. Den muss ich ja nicht bei jedem programmstart
>neu schreiben bzw. würde das ja auch keine entlastung für den
>Flash-Speicher sein. Also wie bekäme ich das Array in den EEPROM? Muss
>ich da erst ne Software drauflasen, mit der ich über RS232 o.ä. in den
>EEPROM reinschreibe und dann neu Flashen mit der Software die das dann
>nutzt oder wie ginge sowas in meinem Fall?
Nein, es wäre in der Tat nicht so sinnig den bei jedem Programmstart neu 
zu schreiben. Für das Beschreiben des EEPROMS kannst du im AVR Studio 
unter View -> Memory -> EEPROM die Bytes von Hand setzen und dann beim 
Beschreiben "Use Current Simulator EEPROM" auswählen. Oder du erstellst 
ein EEPROM.hex File das du reinschreibst. Oder du bastelst ein Programm 
was mal eben das Sinustabellen Array ins EEPROM schreibt und löschst den 
EEPROM dann nicht mehr, bzw. liest den EEPROM aus und schreibst ihn in 
ein Hexfile.

Ansonsten zum lernen:

http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#EEPROM
und
http://www.mikrocontroller.net/articles/AVR-Tutorial:_Speicher#EEPROM_2

Uhu Uhuhu wrote:
>Die AVRs sind Harvard-Maschinen - die können keinen Code aus RAM oder
>EEPROM ausführen. http://de.wikipedia.org/wiki/Harvard-Architektur
Stimmt, ist aber für die Fragestellung nicht ganz passend, natürlich 
kann man DATEN aus jeder Datenquelle verarbeiten, nur das PROGRAMM muss 
im Flash stehen. Wo das Array mit den Werten steht ist egal.

Im Datenblatt vom ATTiny bin ich glaube ich auch ein stück schlauer 
geworden. Die daten werden wohl erst aus den EEPROM in ein Register im 
SRAM gespeichert und könnn von dort aus verarbeitet werden. Jetzt 
dämerts auch was man mir vor eingen Jahren mal über Mikrocontroller 
erzählt hatte. (Damals konnte ich mit glück einen Transistor als 
Schalter Verwenden)

Aber nochmal zurück zum Code von Tim T. Kann das sein, dass das keine 
saubere Sinuswelle ergibt? wenn ich das so richtig sehe, dann wird dort 
der Falsche interrupt verwendet. Nämlich der "Timer/Counter Compare 
Match A"-Interrupt. Dies dürfte meiner Meinung nach zu einer Kurve wie 
dem in folgendem Beitrag führen:
Beitrag "Re: PWM-Sinus"
Wenn man stattdessen den "Timer/Counter Overflow"-Interrupt verwendet, 
werden die gleichmäßig breit ausgerechneten Abschnitte der Sinuskurve 
auch gleichmäßig breit wiedergegeben.
Oder liege ich da falsch?

gast wrote:
> Viel Text.

Der Quelltext benutzt die Fast PWM Variante, in der Einstellung das der 
Ausgang bei 0x00 auf 1 und beim Match auf 0 gesetzt wird, der Zähler 
zählt allerdings IMMER bis 0xFF, absolut unabhänig welcher Interrupt 
ausgelöst wird. Der Wert von ORC0A die On-Tastzeit an. Die PWM Periode 
geht immer von 0x00 bis 0xFF und läuft mit einer Frequenz von 
F_CPU/(Vorteiler*256), bei 8MHz und einem Vorteiler von 8 etwa 
3906,25Hz. Und da ich hintereinander die 78 Werte ausgebe, jeder braucht 
eine PWM-Periode, teilt sich dabei diese Frequenz nochmals durch 78 und 
ich komme auf etwa 50,08 Hz.

Der Timer Compare Match A wird ausgelöst wenn Zähler = OCR0A.
Der Timer Overflow wird ausgelöst wenn Zähler = 0xFF.
Auswirkungen auf das Zählerverhalten haben diese Interrupts nicht.

Wenn man wie du es vorschlägst den Overflow Interrupt benutzt, kommt 
dieser immer nach der gleichen Zeit beim überlauf von 0xFF nach 0x00, 
nur ist das ansich schon zu spät um ORC0A noch vor dem nächsten 
Durchlauf zu ändern (die komplette ISR muss vorher durchlaufen werden), 
da der Wert von OCR0A intern schon bei BOTTOM (0x00) übernommen wird.
Bei meiner Variante wird der nächste 0RC0A Wert schon beim Compare 
geschrieben, man hat somit mehr Zeit (höchster Wert der Sinustabelle war 
glaubich 254). Somit hat man (256-254)*Vorteiler -> 16 Takte Zeit bis 
der Wert aus dem ORC0A intern übernommen wird.

Achso ja... Ok hast mich überredet. Ich hab aus irgendeinem Grund 
gedanklich bei jedem Komparematch den Counter gelöscht, was aber 
irgendwie keinen Sinn gibt. Naja Fehler passieren.
Aber danke für deine ausführliche Antwort.

Dass und wann OCR0A übernommen wird wusste ich gar nicht.

Tim T. schreib:
>
>Program:     234 bytes (22.9% Full)
>(.text + .data + .bootloader)
>
>Data:         41 bytes (64.1% Full)
>(.data + .bss + .noinit)

Wie kommst du zu diesen Angaben? ich benutze WinAVR und war der festen 
Überzeugung das hast das schon mal angezeitg aber ich weiß einfach nicht 
wie?!

gast wrote:
>Achso ja... Ok hast mich überredet. Ich hab aus irgendeinem Grund
>gedanklich bei jedem Komparematch den Counter gelöscht, was aber
>irgendwie keinen Sinn gibt. Naja Fehler passieren.
>Aber danke für deine ausführliche Antwort.
Kein Akt, hatte selber als ich das Programm gebastelt hab den Denkfehler 
mit dem Timer Overflow gemacht.

>Dass und wann OCR0A übernommen wird wusste ich gar nicht.
http://www.atmel.com/dyn/resources/prod_documents/doc8126.pdf
Seite 73 in der Tabellenspalte "Update of OCRx at"

Komischerweise übernimmt der Tiny13 das OCRx laut der Tabelle im 
Datenblatt schon beim erreichen von TOP (0xFF) in Mode 3.
Der Tiny25 in Mode 3 allerdings erst bei BOTTOM (0x00):
http://www.atmel.com/dyn/resources/prod_documents/doc2586.pdf
Seite 82.
Kurzer Vergleich mit 5 Weiteren Datenblättern ergab das alle bei BOTTOM 
aktualisieren, demnach geh ich von einem Druckfehler im Datenblatt des 
Tiny13 aus...

> Wie kommst du zu diesen Angaben? ich benutze WinAVR und war der festen
> Überzeugung das hast das schon mal angezeitg aber ich weiß einfach nicht
> wie?!

AVR Studio -> View -> Toolbars -> Build Output (Haken davor machen)
Wenn da ein Haken ist, einfach auf Build im Unteren Fenster gehen, nach 
dem Build stehen die Infos dann da.

> AVR Studio -> View -> Toolbars -> Build Output (Haken davor machen)
> Wenn da ein Haken ist, einfach auf Build im Unteren Fenster gehen, nach
> dem Build stehen die Infos dann da.

Der Haken ist gesetzt und unter build steht bei mir nur

Build started 6.1.2009 at 09:34:22
avr-gcc  -mmcu=attiny13 -Wall -gdwarf-2  -DF_CPU=4000000  -Os 
-fsigned-char -Wp,-M,-MP,-MT,test.o,-MF,dep/test.o.d  -c  ../test.c
avr-gcc -mmcu=attiny13  test.o    -o test.elf
avr-objcopy -O ihex -R .eeprom  test.elf test.hex
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" 
--change-section-lma .eeprom=0 -O ihex test.elf test.eep
c:\Programme\AVR\WinAVR\bin\avr-objcopy.exe: --change-section-lma 
.eeprom=0x00000000 never used
Build succeeded with 0 Warnings...

Da werde ich wohl noch Google nach unbekannt durchforsten müssen...
Trotzdem aber vielen vielen Dank.

gast wrote:
> Da werde ich wohl noch Google nach unbekannt durchforsten müssen...
> Trotzdem aber vielen vielen Dank.

Naja, ganz so schlimm ist es ja nicht: 
Beitrag "AVR Memory Usage ausgeben lassen"

Ansonsten mal in dein Makefile ob dort

## Build
all: $(TARGET) xxx.hex xxx.eep xxx.lss size

und

size: ${TARGET}
  @echo
  @avr-size -C --mcu=${MCU} ${TARGET}

drin steht.

wahrscheinlich mach ichs falsch aber es funktioniert bei mir nicht. 
Warum auch immer.
Wenn ich das makefile Exportiere und da dann diese Zeilen einfüge (die 
1. zwei sind schon vorhanden, die unteren nicht), dann noch das Exterene 
Makefile verwenden und Compilieren. Und schon gibt er mir ne 
Fehlermeldung:
Makefile:69: *** missing separator.  Stop.
Das ist die Zeiel: @echo

Suche ich allerdings irgendwoanders das Standardmakefile (gefunden in 
...\WinAVR\sample\ ) dann passiert nix und nutze kein externes Makefile, 
dann passiert nix.

Ärgert mich jetz langsam!