Hallo zusammen,
ich wollte mir "nur mal eben schnell" mit einem µC eine Moeglichkeit
aufbauen, um die Kennlinie eines NTCs zu ermitteln.
Dazu habe ich den NTC in der wie von mir gewuenschten Weise an einen
Analogeingang des ATMega328P angeschlossen und mir einen digitalen
Temperatursensor besorgt (TI LM95071).
Beide Messwerte werden dann per serieller Kommunikation an ein FTDI
Modul uebergeben, das die Daten am USB Port eines PCs zur Verfuegung
stellt.
Alle 10ms wird der Analogwert gelesen und ein Mittelwert ueber 16
Messungen gebildet. Ich bekomme also alle ~160ms einen Messwert.
Flux das alte Testboard umgebaut und los geht's.
Funktioniert soweit, bis auf das Hardware SPI. :(
(Deaktiviere ich das SPI_MasterReceive() funktioniert es und ich bekomme
den gemittelten Analogwert alle 160ms.)
Ich habe fuer den TI-Sensor Hardware SPI des 328P verwendet.
Leider klappt das nicht wie erwartet.
Die ersten 10 bis 15 SPI Zyklen (jeweils 2 Byte) klappen problemlos.
Doch dann geht SCK zwischen zwei Übertragungen auf high und bleibt dort.
Am SCK-Pin (PB5) ist nur der ISP Konnektor angeschlossen. Dieser dient
entweder zum Anschluss des AVRISP MKII oder des TI Sensors.
Der Effekt tritt allerdings auch auf, wenn nix (also kein Sensor und
natuerlich kein AVRISP) angeschlossen ist. (Es liegt also nicht (!) am
TI Sensor.)
Kann mir jemand sagen, was ich uebersehen habe ?!
Ich wuerde mich sehr freuen.
Ich hoffe der Code ist nicht zuuuu lang um ihn im thread anzuzeigen.
Vielen Dank,
Balze aka AVR_Noob
P.S.: Auf den Screenshots ist zu sehen:
1. Zwoelf erfolgreiche UEbertragungen nach Einschalten
2. Fehlverhalten von SCK nach der 12ten UEbertragung
3. Zwoelfte UEbertragung im Detail
main.c:
1
/* define CPU frequency in Mhz here if not defined in Makefile */
2
#ifndef F_CPU
3
#define F_CPU 6000000UL // Externer Takt von dem FTDI FT232R Module (6Mz)
4
#endif
5
6
#include<util/delay.h>
7
#include<stdlib.h>
8
#include<string.h>
9
#include<avr/io.h>
10
#include<inttypes.h>
11
#include<avr/interrupt.h>
12
#include<avr/pgmspace.h>
13
14
#include"peter_fleury_usart\uart.h"
15
#include"spi.h"
16
#include"adc.h"
17
18
#define UART_BAUD_RATE 125000
19
20
#define CS_DDR DDRC // Chip Select fuer TI Temp Sensor
Die Programmstruktur ist Murks.
Man macht sowas nicht im Interrupt: while(!(SPSR & (1<<SPIF)));
Und überhaupt ist viel zu viel im Interrupt und viel zu wenig in der
Hautpschleife. Warum heißt die Hauptschleife eigentlich
Hauptschleife?
Da habt Ihr natuerlich beide Recht.
Aber sollte das Entruempeln wirklich mein komisches Problem loesen.
Zwischen "kein guter Stil" und "geht so nicht" ist ja noch ein
Unterschied.
Danke erstmal, werde das nachher mal umstricken und ausprobieren ob das
ursaechlich war.
Danke, mfG
Balze aka AVR-Noob
Avr Noob schrieb:> Doch dann geht SCK zwischen zwei Übertragungen auf high und bleibt dort.
Vermutlich der SPI-Standardfehler, wie hast Du den /SS Pin beschaltet
bzw. definiert?
Peter
Aeeeeehhhmm,
gar nicht :(
Ich habe vermutet, dass es egal ist welchen Pin ich fuer Chip(Slave)
Select nehme.
(Ich sollte aufhoeren bei µCs Vermutungen anzustellen :)
Muss ich !SS behandeln als waere !SS der zustaendige Slave Select?
(als Ausgang definieren; low vor UEbertragung, high nach UEbertragung)
Danke, mfG
Balze aka AVR_Noob
Asche auf mein Haupt.
Ich muss gestehen, dass ich den Absatz "/SS Pin Functionality" komplett
ueberlesen habe.
Sorry, dass ich Euch mit Anfaegnerfehlern dieZeit raube.
Dickes Danke!
Wird gleich ausprobiert (und hoffentlich in meinem nicht fluechtigen
Speicher zwischen den Ohren abgelegt.)
MfG,
Balze aka AVR_Noob
Kurze Rueckmeldung, damit moeglicherweise jemand anderes mit einem
aehnlichen Problem nachlesen kann, dass Peter Danneggers Frage und
Lothar Millers Hinweis auf das Datenblatt die Loesung gebracht haben.
Es funktioniert!
Vielen Dank nochmal!
MfG,
Balze aka AVR_Noob
Den gleichen Fehler hatte ich auch gemacht, schätze darauf fallen viele
Anfäger rein.
Auch AVR's verhalten sich nicht zu 100% so, wie man es vermutet. Man
soll sich halt nicht auf Annahmen verlassen.