Assembler Programmierproblem in Workpad

TommyB · 27. Apr. 2013

Ich glaub wir sprechen etwas aneinander vorbei

Ist aber auch kein Wunder, es gibt ja 2 mkII, einen billigen (AVRISP) und einen teuren (JTAGICE). Ich meinte den Letzteren, ich sprach ja auch von debugWire

Das kann der billige nicht. Und wenn man das einmal gehabt hat ist man wie auf Droge, man kann und will nicht mehr ohne

p.S.: Stimmt, es war RSTDSBL. Kommt ja aber aufs Selbe hinaus

Dirk · 27. Apr. 2013

Hi Tommy,

TommyB schrieb:
Ich glaub wir sprechen etwas aneinander vorbei
Ist aber auch kein Wunder, es gibt ja 2 mkII, einen billigen (AVRISP) und einen teuren (JTAGICE). Ich meinte den Letzteren, ich sprach ja auch von debugWire
Das kann der billige nicht. Und wenn man das einmal gehabt hat ist man wie auf Droge, man kann und will nicht mehr ohne

naja ich habe mich nicht auf deinen Beitrag bezogen. Wenn man natürlich DebugWire benötigt, muss man was anderes verwenden.

stinakovits · 27. Apr. 2013

Schönen Abend zusammen,

es ist ja interessant euren Diskussionen zu folgen. Auch wenn ich nur einen Bruchteil derzeit verstehe

Ich bin einen Schritt weiter. Mein Workpad kann offensichtlich das EEPROM direkt brennen. Ich habe rausgefunden wo ich das .eep File angeben kann. Jetzt stellt sich mir die Frage wie ich zu so einem File komme. Wie erstelle ich es? Welche Struktur hat es? Da hab ich bei Tante Google noch keine Antwort gefunden.

Gruß
Manfred

Dirk · 27. Apr. 2013

Hallo Manfred,

es gibt die Assembler-Direktive ESEG, damit teilst du dem Assembler mit, dass alles was auf die Direktive folgt in das Eeprom gehört. Der Assembler erzeugt dann ein .eep File. In der Designzeit kannst du mit .DB und .DW Daten im Eeprom ablegen. ... Zumindest beim Atmel Assembler

Dirk

dino03 · 27. Apr. 2013

Hi Manfred,

stinakovits schrieb:
Jetzt stellt sich mir die Frage wie ich zu so einem File komme. Wie erstelle ich es? Welche Struktur hat es? Da hab ich bei Tante Google noch keine Antwort gefunden.

bei Programmern wirst du viel mit Intel-Hex-Dateien zu tun haben. Die .eep wird auch eine sein. Es gibt auch Hex-Editoren mit denen du direkt Intel-Hex-Dateien bearbeiten kannst. Es ist eigentlich nix weiteres wie eine Tabelle. In der ersten Spalte ist die Anfangsadresse der Zeile. Dann kommen 16 Bytes als Hexwerte und zum Schluß eine Quersumme der Zeile. Zum Schluß ist noch eine Quersumme der Datei. Such mal nach "Intel Hex Format".

Gruß
Dino

TommyB · 28. Apr. 2013

Ich würde mich lieber nicht mit dem Hex Format ansich rum ärgern

Schau lieber nach dass du das direkt im Quelltext mit definierst, sonst wird vermutlich bei jedem Kompilieren die .eep Datei wieder überschrieben / löschen.

In diesem Thread werden Beispiele für Assembler und C genannt

p.S.: Frag doch einfach was du nicht verstehst. Jeder war mal Einsteiger und ich bin mir sicher hier hat keiner ein Problem damit solchen Leuten zu helfen. Zumindest ich nicht

Wie heißt es noch? Es gibt keine dummen Fragen, nur dumme Antworten

LotadaC · 28. Apr. 2013

Die Sache ist die, das bisher keiner von uns was konkretes zu der verwendeten Programmierumgebung und -hardware sagen kann.
Unter dem AVR-Assembler ist's klar:
Die Direktiven ".eseg", ".cseg" und ".dseg" bewirken, daß der folgende Code im Eeprom/Flash/SRAM landet (bei letzterem nur zur Festlegung der Adressen hinter Variablen, da flüchtiger Speicher).
Die Direktive ".org" setzt einen ... Adress-Pointer (im jeweiligen Bereich) auf einen Wert. (Dieser ist natürlich nur für den Compiler relevant, und erzeugt selbst keinen Code (Direktive))
Die Direktiven ".db" bzw ".dw" interpretieren das folgende/die folgenden Argument/e als Byte/Word, und schreiben sie an der entsprechenden Adresse (siehe .org) in den aktiven Speicherbereich (im SRAM können hier wie gesagt nur mit ".Byte" Adressen reserviert, und mit einem label benamst werden).
Der jeweilige interne Adress-Pointer wird dabei automatisch mitgeführt - um die letztendlich verwendeten Adressen muß man sich also selbst nicht kümmern.

Werden auf diese Weise also Daten im Eeprom erzeugt, kann der Compiler auch die entsprechende Datei fürs Brennen erzeugen. Man kann irgendwo einstellen, welche Dateien beim kompilieren erzeugt werden sollen.
Zumindest bei den älteren Versionen des AVRstudio kann man separat auswählen, ob Flash oder Eeprom gebrannt werden sollen, und welche Datei da als Quelle dienen soll.

Aber bezüglich des verwendeten Compilers und Programmers schauen wir da alle in die Glaskugel...

Dirk · 28. Apr. 2013

LotadaC schrieb:
Die Direktiven ".eseg", ".cseg" und ".dseg" bewirken, daß der folgende Code im Eeprom/Flash/SRAM landet

Genau, es wurde auch schon einige male im Forum erklärt, zum Beispiel hier.

Ich gehe einfach mal davon aus, dass der verwendete Assembler dem Original von Atmel entspricht. Falls nicht und er verwendet andere Instruktionen und andere Direktiven ... :hmmmm:

Mal jetzt nicht bezogen auf die letzte Frage: Es muss noch eine andere Möglichkeit geben an die Registerdefinitionen heranzukommen, als sich alle Register die man benötigt selbst zu definieren. Im Notfall einfach das originale Atmel-Includefile, was hier schon einmal gepostet wurde, einbinden. Dies müsste eigentlich funktionieren. Falls nicht, ist der aktuell verwendete Assembler nicht konform zu dem von Atmel.

Dirk :ciao:

stinakovits · 29. Apr. 2013

Schönen Abend zusammen,

danke für eure zahlreiche Hilfe. Leider funktionieren die ganannten und von mir auch im Netz gefundenen Direktiven nicht. Wäre ja zu schön gewesen. Da mich das jetzt etwas anko... hab ich mal ein Mail an den Support des Herstellers geschrieben. Bin gespannt was ich für eine Antwort bekomme.

Das Einbinden der korrekten .inc Datei für den ATtiny13 werde ich mir bei Gelegenheit auch genauer anschauen. Das ist aber momentan ein nebensächliches Problem.

Gruß
Manfred

dino03 · 29. Apr. 2013

Hi Manfred,

stinakovits schrieb:
Leider funktionieren die ganannten und von mir auch im Netz gefundenen Direktiven nicht. Wäre ja zu schön gewesen. Da mich das jetzt etwas anko... hab ich mal ein Mail an den Support des Herstellers geschrieben. Bin gespannt was ich für eine Antwort bekomme.

Das Einbinden der korrekten .inc Datei für den ATtiny13 werde ich mir bei Gelegenheit auch genauer anschauen. Das ist aber momentan ein nebensächliches Problem.

Beim AVR-Studio sieht das in Assembler eigentlich immer so aus ...

Code:

; ==============================
; ========== ATmega168 =========
; ==============================
;
.include "m168def.inc"	;Definitionsdatei laden

... das hat bei mir noch nie Probleme gegeben.

Wenn natürlich Leute versuchen ihre eigene Entwicklungsumgebung zu stricken und dabei Fehler reinbauen oder an der normalen Arbeitsweise vorbei basteln ist das immer ziemlich ärgerlich.

Und so sieht es dann in der .inc aus ...

Code:

;***** THIS IS A MACHINE GENERATED FILE - DO NOT EDIT ********************
;***** Created: 2010-08-20 14:22 ******* Source: ATmega168.xml ***********
;*************************************************************************
;* A P P L I C A T I O N   N O T E   F O R   T H E   A V R   F A M I L Y
;* 
;* Number            : AVR000
;* File Name         : "m168def.inc"
;* Title             : Register/Bit Definitions for the ATmega168
;* Date              : 2010-08-20
;* Version           : 2.35
;* Support E-mail    : avr@atmel.com
;* Target MCU        : ATmega168
;* 
;* DESCRIPTION
;* When including this file in the assembly program file, all I/O register 
;* names and I/O register bit names appearing in the data book can be used.
;* In addition, the six registers forming the three data pointers X, Y and 
;* Z have been assigned names XL - ZH. Highest RAM address for Internal 
;* SRAM is also defined 
;* 
;* The Register names are represented by their hexadecimal address.
;* 
;* The Register Bit names are represented by their bit number (0-7).
;* 
;* Please observe the difference in using the bit names with instructions
;* such as "sbr"/"cbr" (set/clear bit in register) and "sbrs"/"sbrc"
;* (skip if bit in register set/cleared). The following example illustrates
;* this:
;* 
;* in    r16,PORTB             ;read PORTB latch
;* sbr   r16,(1<<PB6)+(1<<PB5) ;set PB6 and PB5 (use masks, not bit#)
;* out   PORTB,r16             ;output to PORTB
;* 
;* in    r16,TIFR              ;read the Timer Interrupt Flag Register
;* sbrc  r16,TOV0              ;test the overflow flag (use bit#)
;* rjmp  TOV0_is_set           ;jump if set
;* ...                         ;otherwise do something else
;*************************************************************************

#ifndef _M168DEF_INC_
#define _M168DEF_INC_


#pragma partinc 0

; ***** SPECIFY DEVICE ***************************************************
.device ATmega168
#pragma AVRPART ADMIN PART_NAME ATmega168
.equ	SIGNATURE_000	= 0x1e
.equ	SIGNATURE_001	= 0x94
.equ	SIGNATURE_002	= 0x06

#pragma AVRPART CORE CORE_VERSION V2E


; ***** I/O REGISTER DEFINITIONS *****************************************
; NOTE:
; Definitions marked "MEMORY MAPPED"are extended I/O ports
; and cannot be used with IN/OUT instructions
.equ	UDR0	= 0xc6	; MEMORY MAPPED
.equ	UBRR0L	= 0xc4	; MEMORY MAPPED
.equ	UBRR0H	= 0xc5	; MEMORY MAPPED
.equ	UCSR0C	= 0xc2	; MEMORY MAPPED
.equ	UCSR0B	= 0xc1	; MEMORY MAPPED
.equ	UCSR0A	= 0xc0	; MEMORY MAPPED
.equ	TWAMR	= 0xbd	; MEMORY MAPPED
.equ	TWCR	= 0xbc	; MEMORY MAPPED
.equ	TWDR	= 0xbb	; MEMORY MAPPED
.equ	TWAR	= 0xba	; MEMORY MAPPED
.equ	TWSR	= 0xb9	; MEMORY MAPPED
.equ	TWBR	= 0xb8	; MEMORY MAPPED
.equ	ASSR	= 0xb6	; MEMORY MAPPED
.equ	OCR2B	= 0xb4	; MEMORY MAPPED
.equ	OCR2A	= 0xb3	; MEMORY MAPPED
.equ	TCNT2	= 0xb2	; MEMORY MAPPED
.equ	TCCR2B	= 0xb1	; MEMORY MAPPED
.equ	TCCR2A	= 0xb0	; MEMORY MAPPED
.equ	OCR1BL	= 0x8a	; MEMORY MAPPED
.equ	OCR1BH	= 0x8b	; MEMORY MAPPED
.equ	OCR1AL	= 0x88	; MEMORY MAPPED
.equ	OCR1AH	= 0x89	; MEMORY MAPPED
.equ	ICR1L	= 0x86	; MEMORY MAPPED
.equ	ICR1H	= 0x87	; MEMORY MAPPED
.equ	TCNT1L	= 0x84	; MEMORY MAPPED
.equ	TCNT1H	= 0x85	; MEMORY MAPPED
.equ	TCCR1C	= 0x82	; MEMORY MAPPED
.equ	TCCR1B	= 0x81	; MEMORY MAPPED
.equ	TCCR1A	= 0x80	; MEMORY MAPPED
.equ	DIDR1	= 0x7f	; MEMORY MAPPED
.equ	DIDR0	= 0x7e	; MEMORY MAPPED
.equ	ADMUX	= 0x7c	; MEMORY MAPPED
.equ	ADCSRB	= 0x7b	; MEMORY MAPPED
.equ	ADCSRA	= 0x7a	; MEMORY MAPPED
.equ	ADCH	= 0x79	; MEMORY MAPPED
.equ	ADCL	= 0x78	; MEMORY MAPPED
.equ	TIMSK2	= 0x70	; MEMORY MAPPED
.equ	TIMSK1	= 0x6f	; MEMORY MAPPED
.equ	TIMSK0	= 0x6e	; MEMORY MAPPED
.equ	PCMSK1	= 0x6c	; MEMORY MAPPED
.equ	PCMSK2	= 0x6d	; MEMORY MAPPED
.equ	PCMSK0	= 0x6b	; MEMORY MAPPED
.equ	EICRA	= 0x69	; MEMORY MAPPED
.equ	PCICR	= 0x68	; MEMORY MAPPED
.equ	OSCCAL	= 0x66	; MEMORY MAPPED
.equ	PRR	= 0x64	; MEMORY MAPPED
.equ	CLKPR	= 0x61	; MEMORY MAPPED
.equ	WDTCSR	= 0x60	; MEMORY MAPPED
.equ	SREG	= 0x3f
.equ	SPL	= 0x3d
.equ	SPH	= 0x3e
.equ	SPMCSR	= 0x37
.equ	MCUCR	= 0x35
.equ	MCUSR	= 0x34
.equ	SMCR	= 0x33
.equ	ACSR	= 0x30
.equ	SPDR	= 0x2e
.equ	SPSR	= 0x2d
.equ	SPCR	= 0x2c
.equ	GPIOR2	= 0x2b
.equ	GPIOR1	= 0x2a
.equ	OCR0B	= 0x28
.equ	OCR0A	= 0x27
.equ	TCNT0	= 0x26
.equ	TCCR0B	= 0x25
.equ	TCCR0A	= 0x24
.equ	GTCCR	= 0x23
.equ	EEARH	= 0x22
.equ	EEARL	= 0x21
.equ	EEDR	= 0x20
.equ	EECR	= 0x1f
.equ	GPIOR0	= 0x1e
.equ	EIMSK	= 0x1d
.equ	EIFR	= 0x1c
.equ	PCIFR	= 0x1b
.equ	TIFR2	= 0x17
.equ	TIFR1	= 0x16
.equ	TIFR0	= 0x15
.equ	PORTD	= 0x0b
.equ	DDRD	= 0x0a
.equ	PIND	= 0x09
.equ	PORTC	= 0x08
.equ	DDRC	= 0x07
.equ	PINC	= 0x06
.equ	PORTB	= 0x05
.equ	DDRB	= 0x04
.equ	PINB	= 0x03


; ***** BIT DEFINITIONS **************************************************

; ***** USART0 ***********************
; UDR0 - USART I/O Data Register
.equ	UDR0_0	= 0	; USART I/O Data Register bit 0
.equ	UDR0_1	= 1	; USART I/O Data Register bit 1
.equ	UDR0_2	= 2	; USART I/O Data Register bit 2
.equ	UDR0_3	= 3	; USART I/O Data Register bit 3
.equ	UDR0_4	= 4	; USART I/O Data Register bit 4
.equ	UDR0_5	= 5	; USART I/O Data Register bit 5
.equ	UDR0_6	= 6	; USART I/O Data Register bit 6
.equ	UDR0_7	= 7	; USART I/O Data Register bit 7

; UCSR0A - USART Control and Status Register A
.equ	MPCM0	= 0	; Multi-processor Communication Mode
.equ	U2X0	= 1	; Double the USART transmission speed
.equ	UPE0	= 2	; Parity Error
.equ	DOR0	= 3	; Data overRun
.equ	FE0	= 4	; Framing Error
.equ	UDRE0	= 5	; USART Data Register Empty
.equ	TXC0	= 6	; USART Transmitt Complete
.equ	RXC0	= 7	; USART Receive Complete

; UCSR0B - USART Control and Status Register B
.equ	TXB80	= 0	; Transmit Data Bit 8
.equ	RXB80	= 1	; Receive Data Bit 8
.equ	UCSZ02	= 2	; Character Size
.equ	TXEN0	= 3	; Transmitter Enable
.equ	RXEN0	= 4	; Receiver Enable
.equ	UDRIE0	= 5	; USART Data register Empty Interrupt Enable
.equ	TXCIE0	= 6	; TX Complete Interrupt Enable
.equ	RXCIE0	= 7	; RX Complete Interrupt Enable

; UCSR0C - USART Control and Status Register C
.equ	UCPOL0	= 0	; Clock Polarity
.equ	UCSZ00	= 1	; Character Size
.equ	UCPHA0	= UCSZ00	; For compatibility
...
..
.
usw

Aber das hast du dir bestimmt schon selber angesehen.

In Bascom gibt es dann vergleichbares mit der m168def.dat Datei ...

Code:

[DEVICE]
FILE=M168DEF.DAT        ; file name
pdf=ATmega48_88_168.pdf
pdfurl=http://www.atmel.com/dyn/resources/prod_documents/doc2545.pdf
device = ATmega168         ; command line for STK500
up = M168               ; shortname for micro
RAMSTART = $100         ; start of SRAM memory
_CHIP= 34               ; FOr backwards compatibility
RAMEND	= $4FF	        ; Highest internal data memory (SRAM) address.
FLASHEND = $1FFF	;  Highest program memory (flash) address
E2END   = $1FF          ; eprom end
FlashSizeText = 16 KB
SRAM = 1024           ; SRAM size
EEPROM = 512           ; EEPROM size
XRAMINDEX = 0           ; default no XRAM selected
XRAM = 0                ; do not allow XRAM
WAITSTATE=0             ; no wait state
WAITSTATEENABLE=0       ; not enable setting the wait state
XRAMACCESS=0            ; no external memory access selected
XRAMACESSENABLE=0       ; external memory access can not be selected
UBRR = 4096             ; calculation of baudrate
TINY= 0                  ; no tiny micro without sram
MOVW=1                  ; micro has movw instruction 
HWMUL=1                 ; this chip has hardware multiplication
ROMSIZE = 16384         ; size of rom in bytes
SPI_CLock=B,5           ; HW SPI clock pin
SPI_MISO=B,4            ; HW SPI MISO pin
SPI_MOSI= B,3           ; HW SPI MOSI pin
SPI_SS=B,2              ; HW SPI SS pin
INTADR = 2              ; multiple of 2 words
MEGAJMP=1               ; Mega part
MEGAPROG=1              ; program with pages method
MEGAPAGE=6              ; number of pages
PROGWAITMS=0            ; delay for programming
WRAP=0                  ; address wrap
DEVID=1E9406            ; device ID
AIN0_PORT=PORTD         ; analog comparator port
AIN0_PIN=6              ; analog comparator pin
T0_PULSE=PORTD.4        ; pulse generator TIMER 0
T1_PULSE=PORTD.5        ; pulse generator TIMER 1
OCR1A_PORT=PORTB.1      ; Output compare TIMER1A
INT=EIMSK, INT0 , EIFR, INT0 , EIMSK, INT1 , EIFR, INT1 , PCICR, PCIE0 , PCIFR, PCIE0, PCICR, PCIE1 , PCIFR, PCIE1,PCICR, PCIE2 , PCIFR, PCIE2,WDTCSR, WDIE,WDTCSR, WDIF ,TIMSK2, OCIE2A, TIFR2, OCIE2A,TIMSK2, OCIE2B, TIFR2, OCIE2B,TIMSK2, TOIE2, TIFR2, TOIE2,TIMSK1,ICIE1 , TIFR1, ICIE1 ,TIMSK1,OCIE1A , TIFR1, OCIE1A,TIMSK1,OCIE1B , TIFR1, OCIE1B,TIMSK1,TOIE1 , TIFR1, TOIE1,TIMSK0, OCIE0A , TIFR0 , OCIE0A,TIMSK0, OCIE0B , TIFR0 , OCIE0B,TIMSK0, TOIE0 , TIFR0 , TOIE0,SPCR, SPIE , SPSR , SPIF,UCSR0B, RXCIE0 , UCSR0A ,RXCIE0, UCSR0B, UDRIE0 , UCSR0A ,UDRIE0 ,UCSR0B, TXCIE0, UCSR0A , TXCIE0,ADCSRA , ADIE , ADCSRA , ADIF,EECR , EERIE , EECR , EERIE,ACSR , ACIE , ACSR , ACI,TWCR , TWIE , TWCR , TWINT,SPMCSR , SPMIE , SPMCSR , 5
ADFR=160                 ; AD converter free running mode
ADC_REFMODEL=1          ; AD converter  reference
ADC_MUX=4,ADMUX.0-3
CheckSBIC=0             ; do not check SBIC with JMP CALL
SCL=PORTC.5
SDA=PORTC.4
uarts=1 ; 1 uart in this chip
uart1=5 ; extended uart
avr910_devcode=94

ints=2                    ; ext ints
int1=INT0,EIMSK.0,4       ; intname, enable register and bit, number of modes
int1m1=LOW LEVEL,EICRA.0-0,EICRA.1-0    ;first mode, bits to set and value
int1m2=CHANGE,EICRA.0-1,EICRA.1-0
int1m3=FALLING,EICRA.0-0,EICRA.1-1
int1m4=RISING,EICRA.0-1,EICRA.1-1
int2=INT1,EIMSK.1,4       ; intname, enable register and bit, number of modes
int2m1=LOW LEVEL,EICRA.2-0,EICRA.3-0    ;first mode, bits to set and value
int2m2=CHANGE,EICRA.2-1,EICRA.3-0
int2m3=FALLING,EICRA.2-0,EICRA.3-1
int2m4=RISING,EICRA.2-1,EICRA.3-1
WD=MCUSR.WDRF
NEWPORT=1

Powermodes=5
SE=SMCR.0
Pm1=Idle,SMCR.SM0-0,SMCR.SM1-0,SMCR.SM2-0
Pm2=Powerdown,SMCR.SM0-0,SMCR.SM1-1,SMCR.SM2-0
Pm3=Standby,SMCR.SM0-0,SMCR.SM1-1,SMCR.SM2-1
Pm4=ADCnoise,SMCR.SM0-1,SMCR.SM1-0,SMCR.SM2-0
Pm5=Powersave,SMCR.SM0-1,SMCR.SM1-1,SMCR.SM2-0

WDVALUE=16,32,64,128,256,512,1024,2048,4096,8192

[PROG]
chipname=MEGA168

readLB=3,58,00,FF,xx,65,43,21
writeLB=3,AC,FF,FF,xx,65,43,21

21-11=No memory lock features enabled for parallel and serial programming
21-10=Further programming of the flash and eprom is disabled in parallel and serial programming mode. The fuse bits are locked in both serial and parallel mode
21-00=Further programming and verification of the flash and eeprom is disabled in parallel and serial programming mode. The fuse bits are locked in both serial and parallel programming mode

43-11=No restrictions for SPM or LPM accessing the application section
43-10=SPM is not allowed to write to the application section
43-00=SPM is not allowed to write to the application section. Interupt vectors are placed in the boot loader section, ints are disabled while executing from the app section
43-01=LPM executing from the boot loader section is not allowed to read from the appliation section. If interrupts vectors are placed in the boot loader section interrupts are disabled while executing from the application section

65-11=No restrictions for SPM or LPM accessing the boot loader section
65-10=SPM is not allowed to write to the boot loader section
65-00=SPM is not allowed to write to the boot loader section and LPM executing from the application section is not allowed to read from the boot loader section. If int vectors are placed in the application section, ints are disabled while executing from the boot loader section
65-01=LPM executing from the application section is not allowed to read from the boot loader section. If int vectors are placed in the app section, ints are disabled while executing from the boot loader section

readFS=3,50,00,FF,C,B,KLA987
writeFS=3,AC,A0,FF,C,B,KLA987

KLA987-000000=Ext. Clock; Start-up time PWRDWN/RESET: 6 CK/14 CK + 0 ms; [CKSEL=0000 SUT=00]
KLA987-010000=Ext. Clock; Start-up time PWRDWN/RESET: 6 CK/14 CK + 4.1 ms; [CKSEL=0000 SUT=01]
KLA987-100000=Ext. Clock; Start-up time PWRDWN/RESET: 6 CK/14 CK + 65 ms; [CKSEL=0000 SUT=10]
KLA987-000010=Int. RC Osc. 8 MHz; Start-up time PWRDWN/RESET: 6 CK/14 CK + 0 ms; [CKSEL=0010 SUT=00]
KLA987-010010=Int. RC Osc. 8 MHz; Start-up time PWRDWN/RESET: 6 CK/14 CK + 4.1 ms; [CKSEL=0010 SUT=01]
KLA987-100010=Int. RC Osc. 8 MHz; Start-up time PWRDWN/RESET: 6 CK/14 CK + 65 ms; [CKSEL=0010 SUT=10]; default value
KLA987-000011=Int. RC Osc. 128kHz; Start-up time PWRDWN/RESET: 6 CK/14 CK + 0 ms; [CKSEL=0011 SUT=00]
KLA987-010011=Int. RC Osc. 128kHz; Start-up time PWRDWN/RESET: 6 CK/14 CK + 4.1 ms; [CKSEL=0011 SUT=01]
KLA987-100011=Int. RC Osc. 128kHz; Start-up time PWRDWN/RESET: 6 CK/14 CK + 65 ms; [CKSEL=0011 SUT=10]
KLA987-000100=Ext. Low-Freq. Crystal; Start-up time PWRDWN/RESET: 1K CK/14 CK + 0 ms; [CKSEL=0100 SUT=00] 
KLA987-010100=Ext. Low-Freq. Crystal; Start-up time PWRDWN/RESET: 1K CK/14 CK + 4.1 ms; [CKSEL=0100 SUT=01] 
KLA987-100100=Ext. Low-Freq. Crystal; Start-up time PWRDWN/RESET: 1K CK/14 CK + 65 ms; [CKSEL=0100 SUT=10] 
KLA987-000101=Ext. Low-Freq. Crystal; Start-up time PWRDWN/RESET: 32K CK/14 CK + 0 ms; [CKSEL=0101 SUT=00] 
KLA987-010101=Ext. Low-Freq. Crystal; Start-up time PWRDWN/RESET: 32K CK/14 CK + 4.1 ms; [CKSEL=0101 SUT=01] 
KLA987-100101=Ext. Low-Freq. Crystal; Start-up time PWRDWN/RESET: 32K CK/14 CK + 65 ms; [CKSEL=0101 SUT=10] 
KLA987-000110=Ext. Full-swing Crystal; Start-up time PWRDWN/RESET: 258 CK/14 CK + 4.1 ms;[CKSEL=0110 SUT=00] 
KLA987-010110=Ext. Full-swing Crystal; Start-up time PWRDWN/RESET: 258 CK/14 CK + 65 ms; [CKSEL=0110 SUT=01] 
KLA987-100110=Ext. Full-swing Crystal; Start-up time PWRDWN/RESET: 1K CK /14 CK + 0 ms; [CKSEL=0110 SUT=10] 
KLA987-110110=Ext. Full-swing Crystal; Start-up time PWRDWN/RESET: 1K CK /14 CK + 4.1 ms;[CKSEL=0110 SUT=11] 
KLA987-000111=Ext. Full-swing Crystal; Start-up time PWRDWN/RESET: 1K CK /14 CK + 65 ms; [CKSEL=0111 SUT=00] 
KLA987-010111=Ext. Full-swing Crystal; Start-up time PWRDWN/RESET: 16K CK/14 CK + 0 ms; [CKSEL=0111 SUT=01] 
KLA987-100111=Ext. Full-swing Crystal; Start-up time PWRDWN/RESET: 16K CK/14 CK + 4.1 ms;[CKSEL=0111 SUT=10] 
KLA987-110111=Ext. Full-swing Crystal; Start-up time PWRDWN/RESET: 16K CK/14 CK + 65 ms; [CKSEL=0111 SUT=11] 
KLA987-001000=Ext. Crystal Osc.; Frequency 0.4-0.9 MHz; Start-up time PWRDWN/RESET: 258 CK/14 CK + 4.1 ms; [CKSEL=1000 SUT=00] 
KLA987-011000=Ext. Crystal Osc.; Frequency 0.4-0.9 MHz; Start-up time PWRDWN/RESET: 258 CK/14 CK + 65 ms; [CKSEL=1000 SUT=01] 
KLA987-101000=Ext. Crystal Osc.; Frequency 0.4-0.9 MHz; Start-up time PWRDWN/RESET: 1K CK /14 CK + 0 ms; [CKSEL=1000 SUT=10] 
KLA987-111000=Ext. Crystal Osc.; Frequency 0.4-0.9 MHz; Start-up time PWRDWN/RESET: 1K CK /14 CK + 4.1 ms; [CKSEL=1000 SUT=11] 
KLA987-001001=Ext. Crystal Osc.; Frequency 0.4-0.9 MHz; Start-up time PWRDWN/RESET: 1K CK /14 CK + 65 ms; [CKSEL=1001 SUT=00] 
KLA987-011001=Ext. Crystal Osc.; Frequency 0.4-0.9 MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 0 ms; [CKSEL=1001 SUT=01] 
KLA987-101001=Ext. Crystal Osc.; Frequency 0.4-0.9 MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 4.1 ms; [CKSEL=1001 SUT=10] 
KLA987-111001=Ext. Crystal Osc.; Frequency 0.4-0.9 MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 65 ms; [CKSEL=1001 SUT=11] 
KLA987-001010=Ext. Crystal Osc.; Frequency 0.9-3.0 MHz; Start-up time PWRDWN/RESET: 258 CK/14 CK + 4.1 ms; [CKSEL=1010 SUT=00] 
KLA987-011010=Ext. Crystal Osc.; Frequency 0.9-3.0 MHz; Start-up time PWRDWN/RESET: 258 CK/14 CK + 65 ms; [CKSEL=1010 SUT=01] 
KLA987-101010=Ext. Crystal Osc.; Frequency 0.9-3.0 MHz; Start-up time PWRDWN/RESET: 1K CK /14 CK + 0 ms; [CKSEL=1010 SUT=10] 
KLA987-111010=Ext. Crystal Osc.; Frequency 0.9-3.0 MHz; Start-up time PWRDWN/RESET: 1K CK /14 CK + 4.1 ms; [CKSEL=1010 SUT=11] 
KLA987-001011=Ext. Crystal Osc.; Frequency 0.9-3.0 MHz; Start-up time PWRDWN/RESET: 1K CK /14 CK + 65 ms; [CKSEL=1011 SUT=00] 
KLA987-011011=Ext. Crystal Osc.; Frequency 0.9-3.0 MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 0 ms; [CKSEL=1011 SUT=01] 
KLA987-101011=Ext. Crystal Osc.; Frequency 0.9-3.0 MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 4.1 ms; [CKSEL=1011 SUT=10] 
KLA987-111011=Ext. Crystal Osc.; Frequency 0.9-3.0 MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 65 ms; [CKSEL=1011 SUT=11] 
KLA987-001100=Ext. Crystal Osc.; Frequency 3.0-8.0 MHz; Start-up time PWRDWN/RESET: 258 CK/14 CK + 4.1 ms; [CKSEL=1100 SUT=00] 
KLA987-011100=Ext. Crystal Osc.; Frequency 3.0-8.0 MHz; Start-up time PWRDWN/RESET: 258 CK/14 CK + 65 ms; [CKSEL=1100 SUT=01] 
KLA987-101100=Ext. Crystal Osc.; Frequency 3.0-8.0 MHz; Start-up time PWRDWN/RESET: 1K CK /14 CK + 0 ms; [CKSEL=1100 SUT=10] 
KLA987-111100=Ext. Crystal Osc.; Frequency 3.0-8.0 MHz; Start-up time PWRDWN/RESET: 1K CK /14 CK + 4.1 ms; [CKSEL=1100 SUT=11] 
KLA987-001101=Ext. Crystal Osc.; Frequency 3.0-8.0 MHz; Start-up time PWRDWN/RESET: 1K CK /14 CK + 65 ms; [CKSEL=1101 SUT=00] 
KLA987-011101=Ext. Crystal Osc.; Frequency 3.0-8.0 MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 0 ms; [CKSEL=1101 SUT=01] 
KLA987-101101=Ext. Crystal Osc.; Frequency 3.0-8.0 MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 4.1 ms; [CKSEL=1101 SUT=10] 
KLA987-111101=Ext. Crystal Osc.; Frequency 3.0-8.0 MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 65 ms; [CKSEL=1101 SUT=11] 
KLA987-001110=Ext. Crystal Osc.; Frequency 8.0- MHz; Start-up time PWRDWN/RESET: 258 CK/14 CK + 4.1 ms; [CKSEL=1110 SUT=00] 
KLA987-011110=Ext. Crystal Osc.; Frequency 8.0- MHz; Start-up time PWRDWN/RESET: 258 CK/14 CK + 65 ms; [CKSEL=1110 SUT=01] 
KLA987-101110=Ext. Crystal Osc.; Frequency 8.0- MHz; Start-up time PWRDWN/RESET: 1K CK /14 CK + 0 ms; [CKSEL=1110 SUT=10] 
KLA987-111110=Ext. Crystal Osc.; Frequency 8.0- MHz; Start-up time PWRDWN/RESET: 1K CK /14 CK + 4.1 ms; [CKSEL=1110 SUT=11] 
KLA987-001111=Ext. Crystal Osc.; Frequency 8.0- MHz; Start-up time PWRDWN/RESET: 1K CK /14 CK + 65 ms; [CKSEL=1111 SUT=00] 
KLA987-011111=Ext. Crystal Osc.; Frequency 8.0- MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 0 ms; [CKSEL=1111 SUT=01] 
KLA987-101111=Ext. Crystal Osc.; Frequency 8.0- MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 4.1 ms; [CKSEL=1111 SUT=10] 
KLA987-111111=Ext. Crystal Osc.; Frequency 8.0- MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 65 ms; [CKSEL=1111 SUT=11] 
KLA987-000001=reserved
KLA987-010001=reserved
KLA987-100001=reserved
KLA987-110000=reserved
KLA987-110001=reserved
KLA987-110010=reserved
KLA987-110011=reserved
KLA987-110100=reserved
KLA987-110101=reserved

B-0=CLOCK Output enabled
B-1=CLOCK Output disabled
C-0=Divide Clock by 8 Enabled
C-1=Divide Clock by 8 Disabled




readFSH=3,58,08,FF,K,J,I,H,G,DEF
writeFSH=3,AC,A8,FF,K,J,I,H,G,DEF
DEF-000=Reserved
DEF-001=Reserved
DEF-010=Reserved
DEF-011=Reserved
DEF-100=Brown Out 4.3V
DEF-101=Brown Out 2.7V
DEF-110=Brown Out 1.8V
DEF-111=Brown Out Disabled
G-0=Preserve EEPROM when chip erase
G-1=Erase EEPROM when chip erase
H-0=WDT always on
H-1=WDT enabled by WDTCR
I-0=SPI enabled
I-1=SPI disabled
J-0=debugWIRE Enabled
J-1=debugWIRE Disabled
K-0=PIN PC6 is IO pin
K-1=PIN PC6 is RESET

readcalibration=3,38,FF,00
readcalibrationCount=1

readFSE=3,50,08,00,xxxxx,RS,Q
writeFSE=3,AC,A4,00,xxxxx,RS,Q
Q-0=Select BOOT vector
Q-1=Select RESET vector (0000)
RS-00=Bootsize 1024 words
RS-01=Bootsize 512 words
RS-10=Bootsize 256 words
RS-11=Bootsize 128 words

[IOEXT]
UDR0=$C6	; - USART0 -
UDR=$C6
UBRR0H=$C5
UBRRH=$C5
UBRRHI=$C5
UBRR0L=$C4
UBRRL=$C4
UBRR=$C4
UCSR0C=$C2
UCSRC=$C2
UCSR0B=$C1
UCR=$C1
UCSR0A=$C0
USR=$C0

TWAMR=$BD		; - TWI -
TWCR=$BC
TWDR=$BB
TWAR=$BA
TWSR=$B9
TWBR=$B8

ASSR=$B6		; - ASYNC TIM(2) -
OCR2B=$B4		; - TIM2 -
PWM2B=$B4		; - TIM2 -
COMPARE2B=$B4		; - TIM2 -
OCR2A=$B3
COMPARE2A=$B3
PWM2A=$B3
TCNT2=$B2
TIMER2=$B2
COUNTER2=$B2
TCCR2B=$B1
TCCR2=$B1
TCCR2A=$B0

OCR1BH=$8B		; - TIM1 -
OCR1BL=$8A
OCR1AH=$89
OCR1AL=$88
ICR1H=$87
ICR1L=$86
TCNT1H=$85
TCNT1L=$84
...
..
.
usw

Gruß
Dino

stinakovits · 01. Mai 2013

Wenn ich mir jetzt das AVR Studio runterlade und den original MKII, der so um die 40 Euro kostet, kaufe, brauche ich eine externe Spannungsversorgung zum programmieren. Ist das korrekt? Auch habe ich gesehen, dass der ein 6pol. Kabel hat. Selbst wenn ich mit einen Adapter auf 10pol. baue brauche ich trotzdem eine eigene Spannungsversorgung. Die Spannung vom USB kann wohl nicht verwendet werden?

Gruß
Manfred

LotadaC · 01. Mai 2013

Ja, der AVRISPmkII besitzt einen 6poligen Header. Hier in Dinos Thread sollten ja mal alle möglichen Header zusammengetragen werden, und noch etwas mehr...
Der Programmer besitzt eine 6polige (kodierte->Nase) Schneid-Klemm-Pfostenbuchse an einem Flachbandkabel (aka Hosenträger). Die Pfostenbuchse am anderen Ende (1:1) steckt im Gehäuse auf einer 2x3-poligen Stiftleiste (kein Wannenstecker). Man könnte sich also problemlos sein eigenes Kabel konfektionieren (mich hatten damals Micromatches interessiert - leider wäre dann aber bei jedem Wechsel das Gehäuse zu öffnen. Insofern wäre eine Adapterlösung praktischer. Abgesehen davon ist die Stiftleiste im Gehäuse nicht verpolsicher.
Leider scheints auch keine 6poligen Schneid-Klemm-Wannenstecker zu geben...

Und ja, der Programmer stellt über den Vtg-Pin keine Spannung bereit. Dieser Pin dient dazu, daß der Programmer erkennt, welche Spannung der Ziel-Prozessor verwendet - die kann ja durchaus 3,3V oder sogar 1,8V betragen - und seine Logikpegel dementsprechend anpaßt.
Du kannst beim Programmieren also einfach die (eh nötige) Versorgung der Target-Schaltung verwenden.
(Ich habe schon mal irgendwo von einer Modifikation gelesen, wo im Gehäuseinneren eine Verbindung von Vusb nach Vtg hergestellt wurde oder so (ggf abschaltbar?) - aber davon halte ich nicht viel.)

Theoretisch kann man aus dem USB eines PC durchaus 5V zur Versorgung einer Schaltung verwenden - allerdings sollte(!) dem PC der Strombedarf mitgeteilt/erbeten werden. Da gibts eigentlich vorgaben für (an die sich aber nicht alle halten).

Hmm... vielleicht wäre mal folgendes Projekt interessant: Mikrocontrollerschaltung, die sich am USB anmeldet (Bus-powered), und einen entsprechenden Strombedarf anmeldet/erbittet, dann mittels Schaltwandler(n) ggf Zielspannungen generieren kann, außerdem gewissermaßen als Hub den Anschluß anderer USB-Geräte erlaubt, insbesondere halt des Programmers.

TommyB · 02. Mai 2013

Ich kann jetzt nicht für den mkII sprechen, aber bei dem Drachen ist es so:

Das Programmiergerät weiß ja nicht mit welcher Spannung deine Hardware (was auch immer du gebastelt hast) arbeitet. Außerdem ist die Spannung die am USB anliegt auch nicht grade optimal (deswegen hat der AVR Dragon auch ein kleines "Netzteil" integriert was saubere +5V liefert). Ich hatte selber mal ein Board, da ist die Spannung (kurzzeitig) sogar unter 4V eingebrochen, obwohl das laut USB Spec.'s nicht passieren darf.

So, es ist ja ISP, also In System Programmable. Sprich du legst Strom an deine Schaltung an und programmierst die dann mit dem 6poligem Kabel (oder 10, kommt aber auf das Selbe heraus, die anderen Pins sind eh nur Masse).

Endlich komm ich zum Punkt

Die AVR (oder generell fast alle Logik IC's) erlauben nur Spannungen an den Signal- oder Datenpins die gleich oder kleiner der Betriebsspannung sind. Würde also das Programmiergerät jetzt von 5V ausgehen, du betreibst deine Schaltung aber mit 3,3V, könnte dir das Anschließen schon den Controller schrotten. Anders herum könnte es sein dass der Controller wegen dem zu schwachem Pegel (+ Flankensteilheit bliblablubb) die Signale nicht erkennt. Deswegen hat (zumindest der Drachen) die Spannungsleitung. Die dient nur dazu dem internem Pegelwandler zu sagen auf welche Spannung er die Signale legen muss.

Beim Drachen hast du zumindest noch eine Stiftleiste, da kannst du stabile 5V abgreifen. Allerdings kann davon nicht viel Strom gezogen werden. Ist aber auch kein Wunder, USB selbst erlaubt ja höchstens 500mA, also ca. 2,5W. Davon geht noch der Strom ab der der Drachen braucht und die Verluste... Mehr als 100mA würd ich da nicht ziehen.

ISP ist halt In System. Also sollte das System auch die Spannungsversorgung übernehmen

Die Programmer selber versorgen sich eigentlich alle über USB.

Edit: Ach menno, LotadaC war schneller ^^

stinakovits · 02. Mai 2013

Hallo ihr beiden,

danke für die Erklärungen. Ist ein Spitzenforum hier - echt!
Ich lerne jeden Tag Neues. Gefällt mir.

Jetzt mal eine ganz spezifische Hardwarefrage. Gehört vielleicht nicht ganz hier her. Aber ich versuchs mal

Dieses ISP ist ja ganz gut (derzeit brenne ich die Controller nicht in einer Schaltung sondern in einem extra Sockel der ausschließlich mit dem Brenner verbunden ist), jedoch wie realisiert man das hardwaretechnisch brauchbar. Hab zwar hier im Forum schon gestöbert aber nichts gefunden. Oder es einfach übersehen.
Beispielsweise steuere ich mit den Ports direkt LEDs über einen Vorwiderstand von, sagen wir mal, 180 Ohm an. Jetzt möchte ich programmieren und schließe den Brenner direkt an die Pins des Controllers an. Somit wird der Brenner zwar direkt den Controller bedienen aber auch gleichzeitig die LED die am Controller hängt und die zieht schon mal 10mA. Hm, hab ich hier ein Verständnisproblem oder müsste ich erst mal durch schaltungstechnische Kniffe eine Entkopplung von Controller und Verbraucher (LED) herstellen?

Gruß
Manfred

Dirk · 02. Mai 2013

Hallo Manfred,

ideal wäre es, wenn du die IO-Pins für ISP nicht mit externer Hardware belegst, sondern ausschließlich für ISP nutzt. Dies ist natürlich nicht immer möglich, gerade auch bei Mikrocontrollern mit wenig IOs. Hier wird dir nichts anderes übrig bleiben, als die Peripherie von den Signalen des Programmers (SCK, PDI, PDO, RESET\) zu entkoppeln. Es kommt nun auf die angeschlossene Hardware drauf an. Bei LEDs mit Vorwiderstand, könntest du diese ggf. mit Jumper zum Programmieren "abhängen" oder mit Kleinsignaltransistoren (BC337-40 ö.ä) treiben, die dann nur mit dem Basisstrom die ISP-Signale belasten. Vielleicht wäre auch eine Lösung, die kritischere Peripherie (LEDs mit höherem Strom) an andere Pins zu legen und an den ISP-Pins andere Hardware anzuschließen, bei der es reicht, mit Widerständen zu entkoppeln.

Dirk :ciao:

stinakovits · 02. Mai 2013

Hallo Dirk,

die Antwort habe ich erwartet/befürchtet. Aus technischer Sicht ist sie ja auch logisch. Da beim ATtiny13 nur 5 Pins vom PortB wirklich nutzbar sind und die Schaltung möglichst winzig sein muss um in einem Schrumpfschlauch unter zu kommen, bleibt für dieses Projekt nur der externe Weg. Na ja, auch nicht schlimm.

Gruß
Manfred

TommyB · 02. Mai 2013

Genau aus solchen Gründen nutze ich den Drachen, da hab ich das Problem nämlich nicht.

debugWire belegt nur den Reset Pin am IC der eh meistens unbenutzt ist oder sehr leicht via einem Jumper vom System getrennt werden kann. Darüber kannst du wie im Simulator auch in den Code springen und der Controller wird auch geflasht (nur die Fuses setzen geht darüber nicht).

Sonst hat Dirk selbstverständlich recht. Wobei ich früher auch schon LEDs an den ISP Pins angeschlossen hatte (direkt, mit Vorwiederstand) und das Flashen hat trotzdem geklappt. Aber ich würd meine Hand nicht dafür ins Feuer legen dass das in jedem Fall so geht. Aber wenn die nachher eh über einen Transistor o.Ä. gesteuert werden sollte das auch egal sein.

p.s.: Ich glaube ich spreche für alle hier wenn ich sage "Danke für die Blumen"

dino03 · 02. Mai 2013

Hi Manfred,

stinakovits schrieb:
Beispielsweise steuere ich mit den Ports direkt LEDs über einen Vorwiderstand von, sagen wir mal, 180 Ohm an. Jetzt möchte ich programmieren und schließe den Brenner direkt an die Pins des Controllers an. Somit wird der Brenner zwar direkt den Controller bedienen aber auch gleichzeitig die LED die am Controller hängt und die zieht schon mal 10mA. Hm, hab ich hier ein Verständnisproblem oder müsste ich erst mal durch schaltungstechnische Kniffe eine Entkopplung von Controller und Verbraucher (LED) herstellen?

naja ... man darf auch nicht alles auf die Goldwaage legen

Also ... 180 Ohm für ne LED an nem Atmel ist schon echt heftig. Ich nehme bei mir superhelle LEDs - da reicht dann schon nen 1k5 bis 2k2 Widerstand. Oder wenn du normale LEDs nimmst dann kommst du bei 5V auch mit nem Vorwiderstand von 1k oder 1k5 aus. Damit hast du keine Probleme mit dem ISP. Die einzigen Probleme die du bekommst sind welche mit uralten LEDs aus 15-20 Jahre alten Geräten. Da haben die LEDs noch mehr Strom gefressen. Das Zeitalter ist aber eigentlich um.

Atmel schlägt ja von den ISP-Pins zu anderen ICs die das beeinflussen können 1k Widerstände vor. Wenn du also nen 1k Vorwiderstand für ne LED nimmst, dann mußt du ja noch gegenüber nem IC mit Ausgangstreiber mindestens die 1,2V Reserve von einer roten LED dazurechnen. Sehe ich also kein Problem.

Du mußt lediglich aufpassen das du an den ISP-Pins nix dran hast was sie kurzschließen kann (Taster) oder was kaputtmachen kann (Motortreiber, Relais).

Gruß
Dino

stinakovits · 18. Mai 2013

Hallo zusammen,

endlich ist es soweit. Habe den original AVRISP MKII bekommen und gleich meinen Code ins Studio 6 transferiert. Nach doch einigen Anpassungen an die neue Entwicklungsumgebung läuft nun das Programm so wie ich mir das vorstelle. Workpad und den MKII Nachbau verbuche ich als Lehrgeld. Das Flashen funktioniert nun mindestens doppelt so schnell. Der Debugger vom Studio ist Gold wert. Besonders für Anfänger

Auch wenn ich sicher nur einen Bruchteil der Funktionen verwende hat sich der Wechsel ausgezahlt!

Habe schon vieles im Studio erforscht. Trotzdem bleibt noch die ein oder andere Frage

1.) Wenn ich auf Device-Programming klicke und dann auf Memories wird mir unter Flash immer eine .elf Datei als Auswahl vorgeschlagen. Die gibt es aber nicht. Die .hex muss ich immer händisch auswählen. Kann man das irgendwo als Vorgabe einstellen?
2.) Auch das Studio löscht beim Flashen automatisch das EEPROM. Finde nichts wo ich das abstellen könnte. Gibt es da eine Lösung?
3.) Noch was ungutes habe ich herausgefunden. Steht im Programm irgendwo Code der das EEPROM zur Laufzeit beschreibt, spinnt das Studio. Es beschreibt beim Flashen das EEPROM ziemlich unkontrolliert mit Daten. Manchmal Bereiche nur mit einer 0, manchmal mit Daten. Oft werden die Daten die durch die .eep Datei ins EEPROM kopiert werden einfach an einer anderen Position im EEPROM nochmal geschrieben. Manchmal auch nur Teile davon. Sehr komisch. Nehme ich den Code der zur Laufzeit das EEPROM beschreibt aus dem Programm raus, ist alles in Ordnung. Da bin ich nur durch Zufall drauf gekommen als ich nach dem Flashen mir das EEPROM ausgelesen habe. Hat da wer eine Idee dazu?

Gruß
Manfred

dino03 · 18. Mai 2013

Hi Manfred,

stinakovits schrieb:
2.) Auch das Studio löscht beim Flashen automatisch das EEPROM. Finde nichts wo ich das abstellen könnte. Gibt es da eine Lösung?

das hatten wir hier im Forum schonmal. Ich weiß aber nicht mehr von wem. Die Lösung war eine Fuse-Einstellung die das EEPROM gegen Löschung blockiert. Dann kann es vom Progger nicht mehr zusammen mit dem Flash gelöscht werden.

Gruß
Dino

Assembler Programmierproblem in Workpad

Team Bitschubse

Administrator

Mitglied

Administrator

Aktives Mitglied

Team Bitschubse

Sehr aktives Mitglied

Administrator

Mitglied

Aktives Mitglied

Mitglied

Sehr aktives Mitglied

Team Bitschubse

Mitglied

Administrator

Mitglied

Team Bitschubse

Aktives Mitglied

Mitglied

Aktives Mitglied