Kommunikation über 1 Kabel

Ne ich hatte schon alles auf dem Schirm (im wahrstem Sinne des Wortes).
Ich hatte nur zu viel drauf. Ich hatte 1 Byte vermutet, gesendet wurden aber 2.
Denn war auch noch alles inventiert (RS232 ist 0 +15V, 1 -15V) und das erste gesendete Byte war 0x00, da dachte ich dass da irgendeine Pause drin war. Jetzt ist alles ok, arbeite grade am Programm für den Controller :)
 
Stimmt, hab mir grad (nochmal) das erste Bild angesehen - Idle, dann lauter nullen (Startbit=0, Datenbits=0, (daraus folgt->) Paritätsbit=0), hast Du mit "???" gekennzeichnet. "S" ist hier noch das Stopbit des ersten Bytes. "1" =low das Startbit des 2ten Bytes usw. Dann passen die Zeiten auch zu den neueren Bildern. Das 2te Byte kann ich auf'm Handy schlecht erkennen - das letzte Bit ist 'ne 1 (MSB), das Paritätsbit 'ne 0, das Stopbit leitet die Idle-Phase ein, mit 'ner laaangen 1;)

Viel Erfolg!

Edit: also invertiert scheint da nix zu sein - das paßt schon. Allerdings mußt Du Dir die "Zahl" andersrum vorstellen beim "lesen/rechnen", da das LSB zuerst gesendet wird, also links im Oszilogramm erscheint...
 
Genau :)

Ja ne, mein Signal (die TTL Seite) ist so richtig.
Aber alles was ich so gefunden hatte an Beispielen und Beschreibungen war +15V (denkt man natürlich an High) und -15V (Low). Dem ist aber nicht so. Das echte RS232 ist (gegenüber TTL) inventiert. Aber ich hab hier eh alles auf TTL, von daher :)
Sorgte nur erst für Verwirrung, bis ich es denn begriffen hatte :)

Das mit LSB first kannte ich noch :)
Hatte das Problem ja erst, deswegen war mir das gleich ins Auge gestochen.
 
OffTopic @LotadaC:

Ich hatte heut ne kurze Unterhaltung mit Reichelt:
Thomas Baumann @TightDev
@reichelt_el Hiho :) Habt ihr schon geplant die winzigen ATtiny's aufzunehmen? also ATtiny 4, 5, 9, 10? Vorzugsweise SOT-23

reichelt elektronik @reichelt_el
@TightDev Moin auch, die kommen definitiv, da unser Produktmanagement jedoch aktuell mit Volldampf am neuen Hauptkatalog werkelt, wird >

reichelt elektronik @reichelt_el
@TightDev das leider noch dauern. Bitte schau gelegentlich wieder rein. - Grüße!

Wenn die die haben werd ich das auch mal auf die ATmicro adaptieren :)
Oder du machst das. Ist ja universell einsetzbar.
Du schwörst ja so auf die Dinger :D
Ich hätt gern auch mal 2 oder 3 davon, aber deswegen extra bei Pollin oder beim bösem C bestellen... Nee
 
Naja, ich fand die eigentlich einfach nur so niedlich, daß ich einfach mal ein paar bei Christian Scharpe geordert hatte. Der hat die immer noch. Wennst willst, überlasse ich Dir auch einen;)

Hast Du denn einen TPI-fähigen Programmer?

noch niedlicher ist übrigens der Tiny20 als Wafer Level Chip Scale Package (WLCSP)... da ist selbst Dino mit seinem Fädeldraht am Ende:p
(Hach is der süüüüß...)
 
Ne, der Dragon kann das nicht. Gott weiß warum, technisch kann der das definitiv, ist nur ne Softwaresache...

Aber ich hab viele GPIO Pins am Raspberry Pi frei dafür ;)
Wäre nicht der erste Programmer den ich bastel (wenn auch der erste unter Linux)

Einer würd mir glaub ich nicht viel nutzen. Wenn ich bedenk wie viele ich in der Anfangszeit verfused habe (32khz mit /8, whoops, Ende im Gelände, ...)
 
Ach Du warst das damals. Was war eigentlich das konkrete Problem? Daß Dein Programmer nicht auf die maximal zulässige ISP-Frequenz von *grübel* 1kHz runtergestellt werden kann? Hab grad den AVRISP-MKII angeschlossen, und das Studio4 gestartet - beim noch eingestellten Tiny10 kann ich nix mit ISP-Frequenz einstellen (ist ausgegraut), klar. Hat er ja nicht. Aber wenn ich einen Mega88 auswähle, kann ich die Frequenz festlegen. Bis runter zu 51,5Hz (was rein rechnerisch für 'ne durch acht geteilte Taktfrequenz von ca 1,6kHz reicht. Da kannste ja bald im Kopf rechnen...

Beim Tiny10 haste da nicht viel zum verstellen, der hat nur 3 Fusebits (Watchdog, Reset abschalten, Clockausgabe).
Timingtechnisch startet er immer mit dem internen RC, kann dann aber zur Laufzeit umgeschaltet werden (auch auf externe Clock)

Edit zum TPI: der AVRISP konnte das auch erst nach'm Firmwareupdate, wenn ich mich recht erinner. Und das Studio4 kann das auch erst ab SP1.
 
Bei mir war das damals noch mit Bascom und dem LPT ISP Kabel Marke Eigenbau (weiß nicht mehr wie der da hieß, war mit Schaltplan in der Hilfe zu finden). Und in Bascom konnte man die Clock nicht mehr weit genug runter schrauben.

ISP würd ich das bei den Tiny10 nicht mehr nennen, man muss ja eh den ganzen Chip verkabeln ^^
TPI kann der Dragon nicht, und Atmel plant das wohl auch nicht das einzubauen. Ärgerlich.

Hab mir den Tiny20 mal angeschaut. 1,55 x 1,4mm? 0.o Bist du wahnsinnig? :D


Der Code macht übrigens Fortschritte. Aber irgendwie scheint mein Mega grad n Nervenzusammenbruch zu haben.
Irgendwie sampelt er die Bits komplett falsch. Hmpf. Naja, den Fehler find ich auch noch.
 
Zum Tiny20: und erstmal die BEINE.
Aber auch als SOIC sieht der interessant aus.

Zum Code: ich weiß nicht, was Du bei mir bereits korrigiert hast - nach dem ersten Bit wird der OSR nicht wiederhergestellt. Das fehlt direkt hinter dem label bej BitRdy: "Inc OSR".
Allerdings soll OSR nach dem Stopbit 0 bleiben, also erst später inkrementieren.
INC beeinflusst das Z, nicht jedoch das C. Andersrum könnte das "Inc osr" schön zwischen die beiden Branches. So wohl nur einmal hinter das brzs (breq) (datenbit), und einmal hinter dem label parityBit.

So auf den ersten Blick.
 
Ich hab jetzt erstmal versucht das selber umzusetzen, habs also quasi nach Vorlage (deinen Beschreibungen und dem Quelltext) neu geschrieben. Es gibt garantiert Optimierungspotential, vieles ist bei dir auch schon drin. Hab ich auch wahr genommen, aber erstmal rausgelassen. Learning by doing :)
Wenn das erste funktioniert gehts weiter :)

Das größte Problem ist erstmal dass die Timings so garnicht stimmen. Irgendwie will der schneller fertig werden als die Signale vom COM Port rein kommen (es fehlt ziemlich genau 1 bit). Daher triggert der auch manchmal (je nach Parity Bit) 2x auf das angebliche Startbit.

Blau: RS232, rot: high bei Startbit Erkennung, low wenn der µC glaubt das Byte (+ Parity) ist fertig.
Er liest auch wirklich 8 Samples pro Bit ein und 9 Bits, das hab ich überprüft.
IMAGE047.png
 
Ok, wenn dir 2 Kanäle zur Verfügung stehen würde ich folgendes machen:
Ein Kanal zeichnet den TTL-UART mit.Den anderen Kanal nimmst Du zum testen.
Ein freies Bein zum Ausgang, daran den Kanal.
Erster Test: direkt beim Eintritt in die timer-isr Bein toggeln lassen (PIN-Bit 1 schreiben). Sollten 8 Flanken pro Bit erkennbar sein.
Zweiter: stattdessen beim Inc von sabuf toggeln vor dem sbic (jetzt 3 Flanken in der Mitte jedes Bits.
Dritter:nach BitRdy (1 Flanke am Ende jedes Bits).

Usw... databit, startbit, stopbit, Parität.
Aber wie oben bereits erwähnt und editiert: bei mir hatte das zurücksetzen vom OSR gefehlt.

Zu Deinem konkreten Code kann ich natürlich nichts sagen.
 
Bin grade schon am testen :)

Blöd nur dass ich eben nicht 2 Kanäle hab. Aber der Trigger funktioniert sehr zuverlässig sodass ich 2 Signale mal eben übereinander bildbearbeiten kann :)
 
Wenn Du hier nix weiter zu nachdenken hinschreibst...

  • BreadBoard such
  • Stromversorgung such
  • USB-TTL-Konverter such
  • Logic8 such
  • ATtiny10 such (wenn der bloß nicht so klein wär...)
  • AVRISP-MKII such
  • Jagwires find
  • Rechner hochfahr
  • Kaffee koch
:p

Nachtrag:
...nach dem ersten Bit wird der OSR nicht wiederhergestellt. Das fehlt direkt hinter dem label bej BitRdy: "Inc OSR".
Allerdings soll OSR nach dem Stopbit 0 bleiben, also erst später inkrementieren.
INC beeinflusst das Z, nicht jedoch das C. Andersrum könnte das "Inc osr" schön zwischen die beiden Branches. So wohl nur einmal hinter das brzs (breq) (datenbit), und einmal hinter dem label parityBit...

Quark! Einfach (zack zack) 'ne 1 ins OSR laden (ldi OSR, 1) - und zwar zwischen den beiden Branch-Instruktionen. Im Stopbit-Fall bleibt also OSR=0 (wodurch der Empfang in den Idle geht). In den anderen Fällen wirds wieder 1. LDI beeinflußt das SREG gar nicht.
Beim StopBit-Label kann dann das CLR OSR natürlich raus...
 
Brauchst nicht, hab den Fehler grad gefunden :)
War nur etwas gehandicapt, Freundin hat grad arge gesundheitliche Probleme, und somit auch mit Arbeit :/
Hatte mir ziemlich viel Zeit gekostet, daher auch so knappe Antworten.

Muss nur noch mal schaun was genau jetzt abgeht.
Mein Problem mit den Timings war simpel, es war doch tatsächlich 1 Sample pro Bit zu wenig, nu kommts hin.
 
hab aber trotzdem schon angefangen...
allerdings schon ganz am Anfang 'n dämlichen Fehler gehabt:
Man kann den Tiny zwar durchaus ohne Pullup am Reset betreiben... aber nicht, WENN DER PROGRAMMER NOCH DRANNSTECKT... WAAAHHHHH
Wenn man den abzieht, paßts mit den Oversamples schonmal:
sw-uart01.png
Wenn man näher hinschaut, sieht man auch, daß ich nicht das TCNT zum synchronisieren verwende (stimmt hier nur zufällig fast), sondern nur die 3 eher mittleren Zeitpunkte nehme. Somit bliebe der HW-PWM sauber:
sw-uart02.png
Als nächstes werde ich dann mal den debug-Schritt bei den 3 verwendeten Zeitpunkten platzieren. Wenn Zeit ist.

Nachtrag:
so, mal die debugzeile umplatziert, und den PWM von KanalB aktiviert (der war erstmal mit "(0<<COMB01)" abgeschaltet):
sw-uart03.png
scheint erstmal zu passen - der DutyCycle der PWM wird auch angepaßt - jetzt mal 0xFF senden:
sw-uart05.png
paßt auch - allerdings fällt es auf, daß ich ganz schön drifte, und das wo ich den Baudratenfehler (8MHz) eigentlich auf meiner Seite haben sollte. Ich bin zu langsam. Mal näher hingesehen:
sw-uart04.png
Meine Markierung (T1..T2) sollte eigentlich das StopBit sein (1/4800baud=208,33...µs) - da liege ich gerade noch so drinn, eigentlich sollte ich in der Mitte sein.
Also habe ich mir mal die PWM-Frequenz angesehen. Timer-Prescaler ist 1, ins OCR0A wird 207 geladen, die sollte also bei 8MHz/208=38,462kHz liegen (wir erinnern uns an gewollte 4800kHz*8=38,400kHz (wie gesagt, Baudratenfehler auf meiner Seite - eigentlich müßte ich sogar zu schnell sein)).
Trotzdem erreiche ich laut Logic8 nur 37,267kHz.
Meine Schlußfolgerung ist, daß der interne Oscillator zu langsam ist. vielleicht sollte ich dem mit OSCCAL Beine machen.

Hier mal der bisherige
Code:
;************************************
;			Lueftersteuerung
;************************************
;Software UART (RX)
;Hardware/Software PWM
;
;ATtiny10
;       +-----+
; Rx-in-|B0 B3|-!Reset
;   Gnd-|     |-Vcc
;HW-PWM-|B1 B2|-SW-PWM/debug
;       +-----+
;
;************verwendete Hardware*******
;PCINT0 RX-Pin - Synchronisation aufs Startbit
;Timer0 WGM=15 - 8fach Oversampling, HW-PWM (OC0B), Zeitbasis fuer SoftPWM (SW-PWM-Pin)
;Telegramm:
;Startbit|D0|D1|D2|D3|D4|D5|D6|D7|Paritaetsbit(even)|Stopbit

.include "tn10def.inc"	;MCU-Definitionsdatei
;************Interruptvektoren*********
.org 0x0000
	rjmp reset		;Resetvektor
.org PCI0addr
	rjmp RX_start
.org OC0Aaddr
	rjmp OS_tick
;*************Konstanten***************
.equ F_MCU=8000000
.equ Baud=4800
.equ T0Ov=(F_MCU/(Baud*8))-1	
.equ RxPin=PINB0			;hier RX-Pin festlegen
.equ ResetPin=PINB3
.equ BitCntReload=10 	;8Data+1Start+1Paritaet+1Stop-1(Carry)

;**********Reservierte Register********
.def OSR=R23			;Oversampling-Zaehler
.def BitCnt=R22	;Bitzaehler
.def RecByte=R21	;recieved Byte
.def sabuf=R20		;samplebuffer
;**********Resetvektor
reset:
	;Stackpointer ist default =RAMEND**************************????????????????????
	ldi R16, 0xD8
	out CCP, R16			;unlock protected I/Os
	ldi R16, 0x00
	out CLKPSR, R16			;MainClockPrescaler=1
	;Variablen (Register) initialisieren
	clr OSR
	ldi BitCnt, BitCntReload
	clr sabuf
	;PortB5 ist (als Paritaetszaehler bereits 0)
	
	;Timer0 initialisieren
	ldi R16, (1<<OCIE0A)
	out TIMSK0, R16	;IRQ bei Ueberlauf (WGM=15)
	ldi R16, T0Ov
	out OCR0AL, R16		;Reichweite
	ldi R16, (1<<COM0B1)|(1<<WGM01)|(1<<WGM00) 	;********************erstmal ohne HW-PWM
	out TCCR0A, R16	;KanalB PWM, WGM=15
	ldi R16, (1<<WGM03)|(1<<WGM02)|(1<<CS00)
	out TCCR0B, R16	;Presc=1, WGM=0, Timer laeuft
	
	;externe Interrupts
	;ggf vorher auf Hi-Pegel am RxPin warten
	sbi PCMSK, RxPin		;RxPin->IRQ
	sbi PCICR, PCIE0		;PinChangeInterrupt
	ldi R16, (1<<DDB2)|(1<<DDB1)
	out DDRB, R16
	
	;hier init fuer SoftPWM
	;ggf Sleepmode vorbereiten
	sei
;*************Hauptschleife****************
main:
	NOP
	rjmp main
;*************PCINT-ISR********************
RX_start:
	ldi OSR, 2			;Synchronisation
	cbi PCMSK, RxPin	;vom PCINT abgekoppelt
	reti
	
;***********OC0A-ISR**********************
OS_tick:
	push R16
	in R16, SREG		;SREG -> Stack

	;***********hier ggf Zeitbasis für SoftPWM einbauen
	lsl OSR				;Oversampling zaehlen
	brcs BitRdy		;Bit komplett? -> Sprung
	cpi OSR, 16
	brcs TovIsrRdy
	cpi OSR, 65
	brcc TovIsrRdy	;ausserhalb des Fensters? ->Sprung
	
	sbi PINB, DDB2		;******************for debugging
	sbic PINB, RxPin	;sonst Rx-Pin-Pegel auf
	inc sabuf				;SampleBuffer addieren
	rjmp TovIsrRdy		;Oversampling fertig
	
BitRdy:						;letztes Oversample eines Bits wurde empfangen (also 1 Bit komplett)
	subi BitCnt, 1		;Zaehler dekrementieren
	brcs stopBit			;wenn Stopbit empfangen wurde -> Sprung
	ldi OSR, 1
	breq parityBit		;wenn Paritaetsbit empf. wurde -> Sprung
	cpi BitCnt, 9
	brcc startBit		;wenn Startbit empfangen wurde -> Sprung
	lsr sabuf				;Datenbit empfangen, 2x rechtsschieben
	lsr sabuf				;majority landet im Carry
	ror RecByte			;majority von links in Bytespeicher rotieren (LSB first)
	SBRC RecByte, 7	;wenn es eine 1 war
	sbi PINB, ResetPin	;PORTB3 toggeln (XOR)
	rjmp TovIsrRdy		;Datenbit fertig

parityBit:				;Paritaetsbit
	lsr sabuf				;Buffer 2x ->rechts,
	lsr sabuf				;majority->Carry, sabuf=0
	brcc TovIsrRdy		;wenn es eine 1 war,
	sbi PINB, PINB3	;PortB3 toggeln (XOR)
	rjmp TovIsrRdy		;Paritaetsbit fertig
	
stopBit:					;Stopbit
	sbis PORTB, ResetPin	;wenn kein Paritaetsfehler
	;**************************hier RecByte freigeben(flag etc...)
	out OCR0BL, RecByte

	cbi PORTB, ResetPin		;Paritaetszaehler wieder 0
	ldi BitCnt, BitCntReload ;Bitzaehler reinitialisiert
	clr sabuf					;samplebuffer=0
	sbi PCMSK, RxPin		;Startbitdetektion wiederaufgeschaltet
	rjmp TovIsrRdy			;Stopbit fertig
	
startBit:						;Startbit
	;*************************ggf hier sabuf=0 prüfen, was soll bei Fehler geschehen?
	;Sartbit fertig 
	
TovIsrRdy:
	out SREG, R16
	pop R16					;SREG<- Stack
	reti

hat sich eigentlich nicht viel geändert. Ein paar Schreibfehler, für den Tiny10 ein paar Register- und Bitnamen angepaßt. Danach wars eigentlich schon korrekt. Das mit dem OSR hatte ich ja vorher schon angedeutet.
134 Bytes, 13,1% des Flash
 
Das Problem hatte ich auch, ich hab denn mit OSCCAL rum gespielt und lieg jetzt auch sehr nahe an der richtigen Frequenz :)
Ist natürlich etwas nervig. Ändern, flashen, testen und alles wieder von vorne.
Müsste man mal was basteln dass das automatisch geht. Quasi eine Art Kalibrator.

Mein Code läuft jetzt auch soweit, sogar mit DeviceID, ist aber noch ein ziemliches Chaos, werd den nachher mal ausdrucken und aufräumen, denn pack ich den mal hier mit dazu. Auch wenn ich bisher nur das 4. Sample auswerte und Parity ignoriere (noch! Das sind die nächsten Schritte).

Aber eine Sache ist mir noch aufgefallen:
Ist das normal dass der PWM nie 0 erreicht? Also der Ausgang 100%ig auf 0 ist. Warum?
Kommt das daher weil der nicht mit voller Auflösung läuft?
 
Zu PWM-Duty=0: das ist normal bzw folgt aus der Auswertung des OutputCompareMatches. Du verwendetest den Mega88 oder so, dazu mal
Datenblatt 15.5 - Output compare unit(Seite92) schrieb:
Whenever TCNT0 equals OCR0A or OCR0B, the comparator signals a match. A match will set the Output Compare Flag (OCF0A or OCF0B) at the next timer clock cycle.
Als WGM hatten wir einen single slope mode gewählt, bei dem der Timer beim OCR0A-CompareMatch überläuft. Dort ist der zusätzliche "next" Timertakt bereits abgezogen (siehe meine Formel). Beim Tiny10 kommt da 207 raus (208-1), der Timer läuft also bis 207, wodurch das match signalisiert wird, aber erst im nächsten Takt wirksam wird. Im 208ten Takt wird der Timer also dann (wie gewünscht) 0.

Wenn Du also für KanalB 'ne 0 vorgibst, geht der Pin im Überlauf Hi, und erst im nächsten Timertakt wieder low (durch unseren Prescaler entspricht das einem Systemtakt).

Also muß ich hier auch immer 1 abziehen? Ja - aber für 0 wäre das ja TOP (also OCR0A), dann fällt das match-event aber mit dem Überlauf zusammen (und wird ignoriert) - das Hi-setzen des OC-Beinchens beim Überlauf erfolgt aber.
Wie kannst Du das umgehen? Indem Du das ganze invertierst - also nicht die an-Zeit, sondern die aus-Zeit festlegst. Dann erreichst Du zwar nicht mehr die volle Leistung, die brauchst Du hier aber auch nicht, oder? Für volle Leistung und komplett abschalten können könnte man zB für die empfangene 0 den CompareOutputMode abschalten (und für jede andere Zahl an). Dann geht Dir natürlich der Fall 1 (0 senden für einen Takt Hi-Pegel) verloren.

Zum OSCCAL: man könnte zB ein Programm schreiben, welches OSCCAL gesteuert beschreibt, und irgendwie ausgibt. Mit dem Tiny10 habe ich weniger Möglichkeiten. man könnte zB 2 Taster (entprellt) verwenden, die OSCCAL inkremetieren/dekrementieren. Ein Timer läuft im Hintergrund (da unabhängig vom Programm), und toggelt automatisch den ComparePin (also auch Hardware im Hintergrund). Bei einem 8bit-Timer sollte so also ein 512stel der CPU-Frequenz messbar sein. Damit kannst Du OSCCAL erstmal abgleichen. Die Ausgabe kann entweder über eine gelatchte serielle Kommunikation erfolgen, oder man gibt es in Form von 8 LEDs binär aus, oder man legt den Wert im Eeprom ab, oder...

Beim Tiny10 hab ich aber nur 3 I/Os und keinen Eeprom... aber ich könnte das fast Direkt mit meinem Programm machen - Der DutyCycle von KanalB wird mit 103 (ca 50%) fetsgelegt, nach empfang eines Bytes schreibe ich dieses nach OSCCAL. Dann sollte sich Die PWM-Frequenz ändern, deren Sollwert ich ja kenne/vorgegeben habe. Dummerweise werde ich mit höchster Wahrscheinlichkeit aber erstmal dermaßen daneben liegen, daß mein taktgebundener serieller Empfang unbrauchbar(*) wird, und ich resetten muß. (Start, LA-Trigger starten, Terminalprogramm senden, Frequenz ansehen, Reset, LA-Trigger starten, ...)

(*) man könnte natürlich aus der neuen PWM-Frequenz die neue (sicher krumme) Baudrate des Controllers ermitteln (war ja (8fach-Oversampling) das 8fache der Bitfrequenz=Baudrate) und versuchen, diese dem Terminalprogramm vorzgeben. Das geht aber auch nicht schneller, als den Controller zu resetten.

Beachte, daß die Kalibration auch von Temperatur und Versorgungsspannung abhängt (also die Oscillatorfrequenz, aber daraus folgend natürlich auch Deine Kalibration).

Hmm... eine hab ich noch: ich könnte ja erstmal den voreingestellten Wert von OSCCAL retten, nach dem Empfang (= Trigger) schreibe ich OSCCAL für ein paar Überläufe um, danach wird OSCCAL wiederhergestellt. Dadurch sollte die veränderte Frequenz auswertbar sein, mein UART aber trotzdem wieder (halbwegs) stimmen.
 
Hi,

Das Problem hatte ich auch, ich hab denn mit OSCCAL rum gespielt und lieg jetzt auch sehr nahe an der richtigen Frequenz :)
Ist natürlich etwas nervig. Ändern, flashen, testen und alles wieder von vorne.
Müsste man mal was basteln dass das automatisch geht. Quasi eine Art Kalibrator.
da drüber gibts App-Notes von Atmel wie man den internen Oszillator über den UART-Takt, nem 32kHz-Osc, ... kallibrieren kann.

Gruß
Dino
 
Ah ok, denn ergibt das Sinn.
Ich hab das jetzt so gemacht dass ich bei Wert 0x00 COM0B1 auf 0 setze, sonst auf 1. Wenn nicht 0x00 wird der empfangene Wert decrementiert, sollte denn ja so passen. Theoretisch würde denn zwar der Wert 0xFF weg fallen, aber der würde eh keinen Sinn machen da der Timer ja eh nur bis 200dickemilch zählt wegen dem UART.

Mit dem OSCCAL da dachte ich etwas komplizierter als du.
Der Befehlssatz von den Tinys und Megas ist ja nahezu identisch. Ein kleines Programm schreiben was OSCCAL setzt und 1 Pin in einer gewissen Frequenz (Takt / 255 z. B.) toggelt. Das mit einem Mega mit LCD abfangen. Der kann via ISP (und bestimmt auch TPI) den Controller ja neu flashen. So könnte man auch schnell sehen wie weit sich der damit über- und untertakten lässt und automatisch kalibrieren lassen. Aber das wäre ein neues Projekt :)
 
Da bist Du immer noch zu kompliziert - laut AVR053 (doc2555 g) können einige Programmer das sogar selbst (STK500, die AVRISPs und die JTAGICEs) - allerdings sind darin nur'ne Hand voll Controller gelistet.
Ok, die Note ist von 2006 - möglich, daß sich da inzwischen was geändert hat.

Im Prinzip ist ein Programm in den Zielcontroller zu flashen, welches die, dann vom Programmer über ISP(SPI) bzw JTAG übermittelten Timing-Impulse mit dem internen Timer vergleicht und versucht, einen möglichst passenden Wert für OSCCAL zu finden. Hat er diesen gefunden, schreibt er das Byte ins Eeprom, und signalisiert das an den Programmer.
Entweder kann das Eeprom jetzt vor'm neuprogrammieren ausgelesen werden, oder Du stellst sicher, daß das Eeprom durch das flashen nicht überschrieben/gelöscht wird, und kannst in Deinem Programm Deinen Kalibrationswert aus dem Eeprom laden lassen.

Eigentlich sollte es sowas für Deinen Drachen (JTAG? SPI/ISP?) ja auch geben können.
Das mit dem Eeprom ist aber für Chips ohne selbigem nicht brauchbar. Eigentlich sollte es möglich sein, den ermittelten OSCCAL-Wert über den Programmer und die Programmierumgebung ausgeben zu lassen - wäre ja nur'ne Sache der Programmer-Firmware.

AVR054 (doc2563 c) beschäftigt sich mit der Nutzung des HW-UART zum calibrieren.

Zum Tiny10 hab ich AVR057 (doc42038 a) gefunden, allerdings wird hier ein ATmega324 mit externem 11,0592MHz-Quarz eingesetzt (Verweis auf AVR918 (TPI-Guide?) und AVR911 (AVROSP?)) - auch hier wird 'n entsprechendes Programm ins Target geflasht, das Kalibrationsergebnis aber über die Kommandozeile ausgegeben.

Eigentlich sollte der AVRISP MKII das ja auch können, basiert der nicht sogar auf dem AVROSP? - dazu hab ich aber noch nichts gefunden. Aber ich finde ja auch kaum Infos zur TPI-Fähigkeit des Programmers (lediglich in der Online-Hilfe des Studios) - ein aktualisiertes Manual finde ich nicht...

Meiner Meinung sollte es am sinnigsten sein, wenn ATMEL die entsprechenden Möglichkeiten direkt ins AVRStudio integriert - unter Ausnutzung des verwendeten Programmers (bzw dessen Möglichkeiten).
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)