Asuro und eeprom

**izaseba** · 11.11.2007, 16:56

Jetzt ist es noch für die Asuro-Lib interessant welcher Vorraussetzungen notwendig sind. Denn die Idee ist ja nun mal schon seit einiger Zeit da einiges im EEPROM abzulegen.

Ich werde mir als nächstes die neueste Asurolib installieren(gut daß Du irgendwo eine Beschreibung gepostet hast, ich habe nähmlich bis jetzt noch keine libs gebaut) und dieses Programm was die Werte für myasuro.h selbst ermitelt.
Dann versuche ich das ganze ein wenig umzuschreiben.
Das einzigste Problemchen ist ja, daß der Zugriff auf eeprom etwas langsammer ist, als Zugiff auf SRAM, ich meine aber das fällt nicht so ins Gewicht.
Anders ist es, wenn die Werte in myasuro.h liegen, da werden sie ja als Konstante behandelt und müssen nicht extra aus Sram oder Eeprom geladen werden.
Mal sehen, werde jetzt mal die lib installieren.

Gruß Sebastian

**damaltor** · 11.11.2007, 17:33

kleiner tipp zum eeprom:

wenn man es einfach haben will, kann man die demo-funktionen aus dem datenblatt des mega8 direkt übernehmen, sie funktionieren ohne anpassung.

**izaseba** · 11.11.2007, 17:40

Hallo Damaltor, leider kann ich Dir nicht folgen, wie meinst Du das mit 'ohne Anpassung'
in avr-gcc gibt es doch fertige Lösungen, die unter eeprom.h zu finden sind,
warum soll man nach dem Dattenblatt gehen, bei Assembler gib ich Dir recht, aber bei C ?

Gruß Sebastian

**damaltor** · 11.11.2007, 18:26

hmm na wenn man den GCC nicht bemühen will

da sind zwei kurze funktionen drin, die man eins zu eins kopieren kann. die nehm ich meistens. aber interessant wäre mal eine interruptgesteuerte ansteuerung des eeproms..

mmh..

ich liebe interrupts... bei mir läuft I2C und UART auch schon mit einem ringpuffer mit je 32 bytes, die dann interruptgesteuert abgeschickt werden...

da müsste auch eeprom-mäßig was machbar sein. werd mich mal dransetzen, falls du sowas möchtest/brauchen kannst.

vorteil: während der eeprom geschrieben wird, kann der prozessor sinnvolleres tun als das ready-bit zu pollen. nachteil: 32bytes sram sind weg (oder jede andere menge die du möchtest...)

**izaseba** · 11.11.2007, 19:02

hmmm,
ich habe mal im Assembleroutput gewühlt und die Implementierung von eeprom_read_word gefunden, hier der Auszug:

Code:

00000206 <__eeprom_read_word_1C1D1E>:
 206:	04 d0       	rcall	.+8      	; 0x210 <__eeprom_read_byte_1C1D1E>
 208:	e0 2d       	mov	r30, r0
 20a:	02 d0       	rcall	.+4      	; 0x210 <__eeprom_read_byte_1C1D1E>
 20c:	f0 2d       	mov	r31, r0
 20e:	08 95       	ret

00000210 <__eeprom_read_byte_1C1D1E>:
 210:	e1 99       	sbic	0x1c, 1	; 28
 212:	fe cf       	rjmp	.-4      	; 0x210 <__eeprom_read_byte_1C1D1E>
 214:	bf bb       	out	0x1f, r27	; 31
 216:	ae bb       	out	0x1e, r26	; 30
 218:	e0 9a       	sbi	0x1c, 0	; 28
 21a:	11 96       	adiw	r26, 0x01	; 1
 21c:	0d b2       	in	r0, 0x1d	; 29
 21e:	08 95       	ret

Es wird, wer hätte das gedacht eeprom_read_byte verwendet und zwar

Code:

00000210 <__eeprom_read_byte_1C1D1E>:
 210:	e1 99       	sbic	0x1c, 1	; 28
 212:	fe cf       	rjmp	.-4      	; 0x210 
214:	bf bb       	out	0x1f, r27	; 31
 216:	ae bb       	out	0x1e, r26	; 30
 218:	e0 9a       	sbi	0x1c, 0	; 28
 21a:	11 96       	adiw	r26, 0x01	; 1
 21c:	0d b2       	in	r0, 0x1d	; 29

Also ganz nach Dattenblatt, es wird am Anfang wohl eepromready gepollt,
da hast Du recht.
Ringpuffer und Interruptsteuerung ist natürlich was feines, kostet aber auch Zeit, vielleicht ist es sinnvoller die eepromdaten beim Programmstart in Ram zu laden, so viele sind es nicht...
Naja ich kämpfe im Moment noch mit der neuen lib
(

Meine liebste Frau hat mir einen neuen Laptop geschenkt \

/ da dachte ich mir Win Nixda(vista) eine Chance zu geben, deswegen ist es doppelt so schwer für mich, als Linux User)

Gruß Sebastian