Hallo,
wie schon einige male hier erwähnt, bin ich gerade dabei eine Temperatur
Mess und Regelungssteuerung zu bauen (es sollen dann mal in einem
Versuchshaus verschiedene Grenzflächentemperaturen und Feuchtigkeiten
gemessen werden).
Die Hauptarbeit wir in Java passieren, ich benutze den mc nur als
Interface zum PC. Klappt auch alles soweit, das Protokoll ist so, das
ich verschiednen Strings sende mit vorgeschaltetem Multiplexer und dann
den jeweiligen ADC-Wert empfange (über temperaturabhängigen Widerstand).
Gebaut habe ich es mit dem Atmega8L8.
Ich habe jedoch noch das Problem, dass manchmal noch undefnierbare
Zeichen gesendet werden, habe ich noch einen Haken im Programm, bzw. was
könnte ,man besser machen? , hier der Code:
>ok, können diese vom internen Quarz kommen?
Es gibt keinen internen Quarz beim ATMega.
Sende doch mal dauernd nur ein Zeichen z.B. 'A'.
Wenn du dann Fehler bekommst ist der interne
Oszillator zu ungenau. Dann musst du den kalibrieren
oder besser gleich einen Quarz anschliessen.
Interner Quarz? Belege? Datenblatt? Gelesen? Woher?
Meinst du den RC-Schwinger den man noch kalibrieren muss damit er auf
der gewünschten Frequenz schwingt und der mit der temperatur "furchtbar"
wegdriftet..?
Interner Quarz also.
Äähm, ich habe mich nun entschlossen einen externen Quarz zu nehmen, ich
hatte den auch schon dran. Nun noch die Fusebits einstellen über
Burn-o-mat -> lief auch gut, nur... jetzt antwortet der Atmega8 nicht
mehr ??????? warum verläßt er mich, er war doch noch so jung?????
--> das war der befehl:
C:\WinAVR-20100110\bin\avrdude.exe -C
C:\WinAVR-20100110\bin\avrdude.conf -p m8 -P lpt1 -c alex -u -U
hfuse:w:0xD9:m -U lfuse:w:0xE7:m
hier der Programmer im Conf:
programmer
id = "alex";
desc = "Alex - Direct connection ISP";
type = par;
reset = 9;
sck = 6;
mosi = 7;
miso = 10;
# errled = <num> ; # pin number
rdyled = 4;
# pgmled = 4;
# vfyled = 4;
;
Warum quälst du den Mikro mit rechnen und den UART mit ünnötiger
Datenübertragung ;) ?
Umrechnen kann dein PC viel besser .. sogar in Java ;)
Aber aufpassen, Java kennt kein unsigned !
ist das die Ursache, dass der mc garnicht mehr antwortet? also vom
avrdue garnicht mehr erkannt wird (rc=-1)?
@hmmm (komischer Name)
meinst u nur as hi und low-bite schicken, aber dennoch muss ich die
Strings davorsetzen, damit das PC-Programm die Nachricht zuordnen kann
(Protokoll)
OK, ich habe meinen Atmega beerdigt, war nicht der erste...
mit dem Mute der Verzweiflung habe ich nun einen neuen genommen und
diesen mit Burn-o-mat und als crystal auf 3-8mhz und small output swing
geändert, und er läuft und das Program tut auch das was es soll (im
Moment nur einen Text senden).
Nun könnten wir wieder zum Programm kommen .... low und hi bite zum PC?
Hi
>Ich habe jedoch noch das Problem, dass manchmal noch undefnierbare>Zeichen gesendet werden, habe ich noch einen Haken im Programm, bzw. was>könnte ,man besser machen? , hier der Code:
Warum machst du die ganze Verarbeitung im RXC-Interrupt? Interrupts
sollte man so kurz wie möglich machen. Es reicht, wenn deine
Interruptroutine so aussieht:
Hallo,
UART habe ich umgestellt auf reines Senden der high und low-byte -
klappt.
Interrupt umstellen habe ich jetzt hier am Schreibtisch gemacht, ohne zu
testen, wäre so der Weg?:
Hi
> sei ; Interrupts global aktivieren>int_rxc:> push temp1 ; temp auf dem Stack sichern> in temp1, sreg ; SREG sichern> push temp1> in temp1, UDR ; UART Daten lesen>> reti ; raus aus dem Interrupt> clr temp1>;Schleife>loop:
Was soll denn die Interruptroutine in deinem loop?
MfG Spess
in adhigh, ADCH ; danach das mittlerweile gesperrte High Byte
9
10
; in ASCII umwandeln
11
; Division durch mehrfache Subtraktion
12
13
ldi zeichen, '0'-1 ; Ziffernzähler direkt als ASCII Code
14
Z_ztausend:
15
inc zeichen
16
subi adlow, low(10000) ; -10,000
17
sbci adhigh, high(10000) ; 16 Bit
18
brcc Z_ztausend
19
rcall transmit
20
21
subi adlow, low(-10000) ; nach Unterlauf wieder einmal addieren
22
sbci adhigh, high(-10000); +10,000
23
24
ldi zeichen, '0'-1 ; Ziffernzähler direkt als ASCII Code
25
Z_tausend:
26
inc zeichen
27
subi adlow, low(1000) ; -1,000
28
sbci adhigh, high(1000) ; 16 Bit
29
brcc Z_tausend
30
rcall transmit
31
32
subi adlow, low(-1000) ; nach Unterlauf wieder einmal addieren
33
sbci adhigh, high(-1000) ; +1,000
34
35
ldi zeichen, '0'-1 ; Ziffernzähler direkt als ASCII Code
36
Z_hundert:
37
inc zeichen
38
subi adlow, low(100) ; -100
39
sbci adhigh, high(100) ; 16 Bit
40
brcc Z_hundert
41
rcall transmit
42
43
subi adlow, low(-100) ; nach Unterlauf wieder einmal addieren
44
sbci adhigh, high(-100) ; +100
45
46
ldi zeichen, '0'-1 ; Ziffernzähler direkt als ASCII Code
47
Z_zehner:
48
inc zeichen
49
subi adlow, low(10) ; -10
50
sbci adhigh, high(10) ; 16 Bit
51
brcc Z_zehner
52
rcall transmit
53
54
subi adlow, low(-10) ; nach Unterlauf wieder einmal addieren
55
sbci adhigh, high(-10) ; +10
56
57
subi adlow, -'0' ; adlow enthält die Einer, Umwandlung in ASCII
58
mov zeichen,adlow
59
rcall transmit
60
61
ldi zeichen, 'X' ; Ende des Strings
62
rcall transmit
63
ldi zeichen, ' ' ; Ende des Strings
64
rcall transmit
Spart dir Register
.def ztausend = r23 ; Zehntausenderstelle des ADC Wertes
.def tausend = r24 ; Tausenderstelle des ADC Wertes
.def hundert = r25 ; Hunderterstelle des ADC Wertes
.def zehner = r26 ; Zehnerstelle des ADC Wertes
und macht es übersichtlicher. Da du die allema nicht mehr brauchst.
Wow mein erster Tipp in ASM hier grins
Hallo,
@holg_i:
ja, ich hab die ganze ASCIIs ja schon rausgeworfen und sende nur noch hi
und low byte (siehe letzte Mitteilung)
@spess53
ääähhm....ok, ich hab noch so meine Probleme mit Assembler, kannst du
mir hier helfen? Es soll auf jedem Fall beim Empfang eines Strings über
den UART was das high und low byte gesendet werden.
Gruß
Pfeiffy
Dirk P. schrieb:> @spess53> ääähhm....ok, ich hab noch so meine Probleme mit Assembler, kannst du> mir hier helfen?
Ich denke, dass dir hier nicht wirklich klar ist, wie das mit rcall etc
funktioniert. Was ein Interrupt ist dürftest auch noch nicht durchschaut
haben.
Warum machst du den Empfang per Interrupt? Musst du doch nicht. Machs
doch erst mal konventionell mittels Polling.
Du hast da einen ziemlichen Saustall auf dem Stack angerichtet. Im
Grunde bist du gar nicht soweit von einer richtigen Lösung entfernt,
wenn du die Ablaufpfade erst mal richtig stellst. Sieh erst mal zu, dass
du das in den Griff kriegst.
Wenn du sowieso schon Java kannst, dann versteh ich nicht, warum du dir
dann hier mit Assembler eine Baustelle aufmachst, die mit C (dank deiner
Java Vorkentnisse) nur 1/4 so groß wäre.
Hi
>ääähhm....ok, ich hab noch so meine Probleme mit Assembler, kannst du>mir hier helfen? Es soll auf jedem Fall beim Empfang eines Strings über>den UART was das high und low byte gesendet werden.
Das sollte dich aber nicht hindern, das Programm im Simulator zu testen.
Ein paar Kleinigkeiten habe ich schon korrigiert.
MfG Spess
Hallo,
klar Einarbeiten in Assemble, weiss ich ja (aber mir fehlt die Zeit!)-
alles was ich in Assembler machen will ist diese Schnttstelle zum PC
über die UART und damit die ADCs abfragen und noch einen Multiplexer
davor. Mehr möchte ich garnicht. Es klappt ja so wie ichs progranmmiert
habe, jetzt wollte ich es nur noch verbessern.
Gruß
Pfeiffy
Hi
>noch eine Frage: wie kann ich im Simulator den Interrupt simulieren?
Während der Simulation im I/O View das passende Interrupt Flag Bit
setzen.
MfG Spess
Dirk P. schrieb:> Hallo,> klar Einarbeiten in Assemble, weiss ich ja
C und nicht Assembler ist für Deinen Anwendungsfall die richtige Wahl,
wie Karl heinz Buchegger schon bemerkt hat.
Hallo,
ich lass das jetzt mal mit c, der code, den mir spess gegeben hat läuft
einwandfrei und macht genau das, was er soll, nochmals danke!!!!
Ich wende mich nun der Verarbeitung und der Auswertung, wie auch dem
Versuchsaufbau zu. Mit Java ist das eine tolle Sache, läuft schon
wunderbar!!
Gruß
Pfeiffy