ATNEL tech-forum

Re: Problematyczny pomiar ADC na dwóch kanałach...

2012-09-13T20:12:18+01:00

Zrobiłem to o czym napisałem w topic1534.html#p15068 i już widzę znaczącą poprawę.

PS.
Pomiar ADC opanowany.
Trzeba jeszcze komparator ruszyć - zabezpieczenie przed przeciążeniem tranzystora sterującego trafem.

Statystyki: Napisane przez szopler — 13 wrz 2012, o 20:12

Re: Problematyczny pomiar ADC na dwóch kanałach...

2012-09-13T19:29:43+01:00

Hmmm poszukaj w nocie tabelki ADC Prescaler Sections .
co ciekawe podczas doboru częstotliwości taktowania ADC zauważysz lub zauważyłeś że wartości częstotliwości próbkowania są mocno niewygodne, w efekcie czego będziesz musiał się nieco pobawić, albo dobierając odpowiedni
kwarc , albo użyć timera.

choćby np tak

[syntax=c]
TIMSK |= (1< TCCR0 |= (1< TCNT0 = 155; // wartość startowa licznika

DDRC &=~ (1<
[/syntax]

dla oczywiście ADC w trybie freeRun zakładam próbkowanie 20Ksps

[syntax=c]
ADCSRA = (1< |(1< |(1< |(1<
ADMUX = (1< |(1< |(1<
[/syntax]

ale nie mam pojęcia czy słusznie rozumuje ....

Statystyki: Napisane przez SunRiver — 13 wrz 2012, o 19:29

Re: Problematyczny pomiar ADC na dwóch kanałach...

2012-09-13T19:35:39+01:00

12000000/64 = 187500 i tak mam ustawione przy /128 też o dziwo był "zwis".
Nie bardzo widzę gdzie się wybiera rozdzielczość, ale ADC6 i ADC7 chyba są 10bit na sztywno (te piny nie mają w tym uP innych funkcji jak tylko ADC).

Zmieniam częstotliwość sprawdzania napięcia przetwornicy z 10kHz na 1kHz - tak było na płytce testowej i działało dobrze. Nie ma sensu gonić procka tym bardziej, że jeszcze parsowanie danych z GPS i zapis na kartę go czeka...

No i widzę jeszcze jedną głupotę jaką zrobiłem - sterowanie przetwornicą w przerwaniu... zaraz to zrzucam do zdarzenia.

Statystyki: Napisane przez szopler — 13 wrz 2012, o 19:12

Re: Problematyczny pomiar ADC na dwóch kanałach...

2012-09-13T18:36:06+01:00

to ciekawe w sumie ...
co piszesz możliwe że coś ci się procek nie wyrabia , ADC masz na 8 czy na 10bit ??

niby nota mówi że czas konwersji mieści się w zakresie 13 - 250ms
i maxymalnie daje radę wydusić 15kSPS

chyba że coś jawnie przeoczam ??

------------------------ [ Dodano po: kilkunastu sekundach ]

powiedzmy że przy 10 bitach możesz taktować ADC nie więcej niż 200khz
i musisz pogrzebać teraz w tabeli w nocie by ustalić sobie preskaler na bitach ADSPn by uzyskać najbliższą
możliwą zbliżoną do 200khz lub innej żądanej

Statystyki: Napisane przez SunRiver — 13 wrz 2012, o 18:36

Re: Problematyczny pomiar ADC na dwóch kanałach...

2012-09-13T18:00:16+01:00

I chwała za to, bo czasem człowiek się blokuje na jakimś fragmencie kodu tylko dlatego że czegoś nie widzi albo nie do końca rozumie jak to działa...

FreeRuning mode jak widziałem włącza się za pomocą sbi(ADCSRA, ADATE); lub jak kto woli: ADCSRA |= (1<Niestety po włączeniu objawy jak napisałem wyżej...

Nie do końca rozumiem też wpływ ADPSn w tym rejestrze na szybkość pomiaru...
np. przy podziale 12M/128 procesor jakby nie nadążał, podobnie dla wartości /2 i chyba /4. Pośrednie tzn. /8 /16 /32 /64 jakoś działają.

Ciekawie jest również gdy zmniejszę prędkość UART'a z 57600 na 9600. Są momenty gdzie wyraźnie widać (choćby po LED, ale w terminalu też), że następuje chwilowe przeciążenie... LED raz na ileś mignięć ma około 2x dłuższą przerwę niż powinien.

Statystyki: Napisane przez szopler — 13 wrz 2012, o 18:00

Re: Problematyczny pomiar ADC na dwóch kanałach...

2012-09-13T17:51:43+01:00

oczywiście zgadzam się z tym , bo teraz kod analizuję , choć dziś coś nie mam głowy do myślenia
niemniej staram się pomóc.

Statystyki: Napisane przez SunRiver — 13 wrz 2012, o 17:51

Re: Problematyczny pomiar ADC na dwóch kanałach...

2012-09-13T18:04:07+01:00

SunRiver napisał(a):

Jak widać w załączonym kodzie steruję ręcznie. FreeRunning powoduje jedno - przez RS232 nic nie leci, a dioda która dodatkowo pokazuje mi że "program żyje" nie zmienia stanu.
Co do tego, że zabudowany ADC wystarcza do zabawy się nie zgodzę. Przetwornica napięcia zbudowana na procesorze (PWM + ADC) działa o niebo lepiej niż FlyBack na układzie MC34063!

SunRiver napisał(a):

Zobacz sobie do noty jakie parametry ma określone AVCC -- zwykle może się różnić o ±0,3V od VCC. Jednakże pod tabelką w nocie jest dodatkowe zastrzeżenie, że AVcc nie może być mniejsze niż 2,7V, i większe niż 5,5V.

Sprawdź AREF ... zwykle jest powiązane z AVCC i nie może go przekroczyć , a dolna granica zwykle to 2V
czyli nie tak kolorowo i nie za bardzo możesz sobie AREF mieszać

Jeśli korzystasz z wbudowanego źródła odniesienia Vint 2,56V to też miej na uwadze że w zależności od układu , partii układów może się ono znacznie różnić od 2,56V -- typowo może się wahać od 2.3 do 2.9V najczęściej 2.6V
zresztą w nocie znajdziesz dopisek że wartości Vint są tylko wytycznymi --- cokolwiek to znaczy

kolejny parametr ważny to Vin tu sprawa jest prosta ... napięcie powinno być mierzone względem GND do Vref

na razie sprawdź podłączenia i filtrowanie , oraz sposób wyzwalania pomiarów na kanałach ADC
potem zajmiemy się resztą

Napięcie odniesienia 1.098V - zmierzone.
AREF do masy przez 100n jak należy. Do tego 100n na AVCC i drugie 100n na VCC. Dławika na AVCC już nie dawałem bo nie ma sensu skoro pozostałe piny PortC działają jako cyfrowe.
Procka do pomiaru też nie usypiam bo ma ważniejsze zadania do wykonania niż pomiar. Z resztą przerwania zewnętrzne w zbyt wielu przypadkach i tak by go budziły zanim pomiar by się zakończył...

Statystyki: Napisane przez szopler — 13 wrz 2012, o 17:47

Re: Problematyczny pomiar ADC na dwóch kanałach...

2012-09-13T17:30:20+01:00

Hmm, a jak sterujesz pomiarem ??
na początek sugerował bym Freeruning mode , wyzwalaj ręcznie wtedy kiedy jest to potrzebne
szumy jakieś wystąpią zawsze nasze ADC nie jest specjalnie dokładne , ale w większości przypadków starcza
do zabawy...

Niemniej takie wahania mogą wskazywać na 2 problemy

1. Programowy --- Kanały nie pracują jednocześnie i trzeba je przełączać
2. Sprzętowy --- dokładność ADC nie wynika tylko z niego samego , ale tez przede wszystkim ze sposobu
podłączenia. I tu chyba masz problem.

Zobacz sobie do noty jakie parametry ma określone AVCC -- zwykle może się różnić o ±0,3V od VCC. Jednakże pod tabelką w nocie jest dodatkowe zastrzeżenie, że AVcc nie może być mniejsze niż 2,7V, i większe niż 5,5V.

Sprawdź AREF ... zwykle jest powiązane z AVCC i nie może go przekroczyć , a dolna granica zwykle to 2V
czyli nie tak kolorowo i nie za bardzo możesz sobie AREF mieszać

Jeśli korzystasz z wbudowanego źródła odniesienia Vint 2,56V to też miej na uwadze że w zależności od układu , partii układów może się ono znacznie różnić od 2,56V -- typowo może się wahać od 2.3 do 2.9V najczęściej 2.6V
zresztą w nocie znajdziesz dopisek że wartości Vint są tylko wytycznymi --- cokolwiek to znaczy

kolejny parametr ważny to Vin tu sprawa jest prosta ... napięcie powinno być mierzone względem GND do Vref

na razie sprawdź podłączenia i filtrowanie , oraz sposób wyzwalania pomiarów na kanałach ADC
potem zajmiemy się resztą

Statystyki: Napisane przez SunRiver — 13 wrz 2012, o 17:30

Re: Problematyczny pomiar ADC na dwóch kanałach...

2012-09-13T17:18:45+01:00

Dzięki Mirku... nie wiem jak mi się to przemyciło skoro skopiowałem ze swojego kodu który (jak mi się wydawało) był już poprawiony... :/

Zastanawia mnie jeszcze jedna sprawa... czas konwersji podany w dokumentacji 13-260us.
Czy wywoływanie pomiaru ADC co 100us nie zrobi mi w końcu "kuku"?

Statystyki: Napisane przez szopler — 13 wrz 2012, o 17:18

Re: Problematyczny pomiar ADC na dwóch kanałach...

2012-09-13T17:12:11+01:00

Code:

ADMUX |= (ADMUX & 0b11100000) | kanal;

zobacz i poczytaj sobie tutaj:

http://atnel.pl/uaktualnienia-programow-do-dvd.html

a jest tam link do naszego forum:

post13633.html#p13633

to właśnie pewnie tu masz problem - więc zaglądaj czasem na stronę atnela do aktualizacji i artykułów ok?

Statystyki: Napisane przez mirekk36 — 13 wrz 2012, o 17:12

Problematyczny pomiar ADC na dwóch kanałach...

2012-09-13T17:23:47+01:00

Procesor: ATMega168PA
F_CPU = 12 000 000
[syntax=c]
/* Dolaczenia plikow */
#include
#include
#include
#include
#include "MK_USART/mkuart.h"

/* Definicje makr i uproszczeń */
#define sbi(byte,bit) byte |= (1<#define cbi(byte,bit) byte &= ~(1<#define bit(byte,n) (byte>>n)&1
#define _Set1
#define _Rst0
#define PWM_RegisterOCR0B
#define PWM_Value 64

typedef uint8_tu08;
typedef uint16_tu16;
typedef uint32_tu32;
typedef struct pulse {
u08 A;
u08 B;
u08 C;
u08 D;
} pulse;

/* Deklaracje zmiennych */
struct _FLAGA {
u08CheckPort:1;
u08SerialSend:1;
} _FLAGA;

volatile pulsePULSE;
charRS232_String[32];
volatile u16ADC_Value;
volatile u16Pomiar_HV;
volatile u16Pomiar_BAT;
volatile unsigned charstan_portu, poprzedni_stan;
volatile u16 Timer_1s, Timer_1m;

/* Deklaracje funkcji */
voidobsluga_pulsow(void);
voidobsluga_rs232(void);
u16obsluga_adc(u08 kanal);
/* .... ---- .... */

/* .... INICJALIZACJA .... */
void _INIT(void) {

/* Konfiguracja wyjsc sterujących osprzetem */
sbi(DDRD,2);//GPS power control
cbi(PORTD,2);//GPS power on(sbi) / off(cbi)

sbi(DDRB,0);//Red LED control
cbi(PORTB,0);//Red LED on(sbi) / off(cbi)

sbi(DDRB,1);//MMC power control
cbi(PORTB,1);//MMC power on(sbi) / off(cbi)

/* Konfiguracja wejsc impulsow */
cbi(DDRC,0); cbi(DDRC,1); cbi(DDRC,2); cbi(DDRC,3);// C0..C3 jako wejscia
sbi(PORTC,0); sbi(PORTC,1); sbi(PORTC,2); sbi(PORTC,3);// C0..C3 Pullup ON

sbi(PCICR, PCIE1);// Włączenie przerwań od PCINT8 (PC0) do PCINT11 (PC3)
sbi(PCMSK1,PCINT8);// Maska zezwalająca na przerwanie od PC0
sbi(PCMSK1,PCINT9);// Maska zezwalająca na przerwanie od PC1
sbi(PCMSK1,PCINT10);// Maska zezwalająca na przerwanie od PC2
sbi(PCMSK1,PCINT11);// Maska zezwalająca na przerwanie od PC3

/* Konfiguracja przycisku */
cbi(DDRD,3);// PD3 jako wejscie
sbi(PORTD,3);// PD3 Pullup ON

/* Konfiguracja Timer2 jako TIMER - odliczanie czasu na potrzeby systemu */
cbi(TCCR2B, CS22); sbi(TCCR2B, CS21); cbi(TCCR2B, CS20);// Konfiguracja na 12MHz/8 = 1.5MHz
OCR2A = 150; // Compare Interrupt co 150/1.5MHz = 100us (10kHz)
sbi(TIMSK2, OCIE2A);// Włączenie przerwania typu compare od rejestru A

/* Konfiguracja Timer0 jako zrodlo sygnalu PWM */
sbi(DDRD,5);// PD5 jako wyjscie
sbi(TCCR0A,COM0B1); cbi(TCCR0A,COM0B0);// Clear OC0B on Compare Match, set OC0B at BOTTOM
cbi(TCCR0B,WGM02); cbi(TCCR0A,WGM01); sbi(TCCR0A,WGM00);// CCS - Mode 1 (Phase Correct) because of Fpwm
cbi(TCCR0B,CS02); cbi(TCCR0B,CS01); sbi(TCCR0B,CS00);// CCS -> 12MHz/1 = 12MHz /2 (Phase Correct -> Fpwm=22059Hz)
PWM_Register = 0;// PWM 0% na starcie (dodane dla bezpieczenstwa)

/* Konfiguracja ADC */
sbi(ADMUX,REFS1); sbi(ADMUX,REFS0);// Wybor napiecia odniesienia - 1.1V
sbi(ADCSRA,ADPS2); sbi(ADCSRA,ADPS1); cbi(ADCSRA,ADPS0);// Fp=12MHz/64 = 187.5kHz
sbi(ADCSRA,ADEN); // Wlaczenie ADC

/* Konfiguracja RS232 */
USART_Init(57600);

sei();
}
/* .... ---- .... */

/* .... PRZERWANIA .... */
ISR(TIMER2_COMPA_vect) // Wywoływane co 0,0001s przy OCR2A = 150
{
TCNT2 = 0; // Zerowanie timera

Timer_1s++;
if (Timer_1s >= 10000) {
Timer_1s = 0;
Timer_1m++;
if (Timer_1m == 5) {
ADC_Value = obsluga_adc(6);
Pomiar_BAT = ADC_Value * 76;
}
if (Timer_1m >= 60) {
Timer_1m = 0;
}

_FLAGA.SerialSend = _Set;
}

// switching DC/DC control
Pomiar_HV = (94*obsluga_adc(7)) / 100;
if ( Pomiar_HV < 400 ) {
PWM_Register = PWM_Value;
} else {
PWM_Register = 0;
}
}

ISR(PCINT1_vect)
{
_FLAGA.CheckPort = _Set;
}
/* .... ---- .... */

/* .... FUNKCJE .... */
void obsluga_rs232(void) {
if (_FLAGA.SerialSend == _Set) {

//sprintf(RS232_String,"%03d %03d %03d %03d\r\n", PULSE.A, PULSE.B, PULSE.C, PULSE.D);
sprintf(RS232_String,"HV=%03uV BAT=%05uV ADC=%04u\r\n", Pomiar_HV, Pomiar_BAT, ADC_Value);

uart_puts(RS232_String);
PORTB ^=(1< }
_FLAGA.SerialSend = _Rst;
}

u16 obsluga_adc(u08 kanal) {
ADMUX |= (ADMUX & 0b11100000) | kanal; // ADMUX & maska (zachowaj to co już jest ustawione) i ustaw 4 ostatnie bity - nr kanalu
sbi(ADCSRA,ADSC); // Start konwersji ADC
while (ADCSRA & (1< return ADCW; // Zwroc wynik konwersji
}

void obsluga_pulsow(void) {
if (_FLAGA.CheckPort == _Set) {
stan_portu = (~(PINC) & 0b00001111);

switch ( (stan_portu ^ poprzedni_stan) & stan_portu ) {
case 1: PULSE.A++;break;
case 2:PULSE.B++;break;
case 3:PULSE.A++; PULSE.B++;break;
case 4:PULSE.C++;break;
case 5:PULSE.A++; PULSE.C++;break;
case 6: PULSE.B++; PULSE.C++;break;
case 7:PULSE.A++; PULSE.B++; PULSE.C++;break;
case 8:PULSE.D++;break;
case 9:PULSE.A++; PULSE.D++;break;
case 10:PULSE.B++; PULSE.D++;break;
case 11:PULSE.A++; PULSE.B++; PULSE.D++;break;
case 12:PULSE.C++; PULSE.D++;break;
case 13:PULSE.A++; PULSE.C++; PULSE.D++;break;
case 14:PULSE.B++; PULSE.C++; PULSE.D++;break;
case 15:PULSE.A++; PULSE.B++; PULSE.C++; PULSE.D++;break;
}
_FLAGA.CheckPort = _Rst;
}
poprzedni_stan = stan_portu;
}
/* .... ---- .... */

/*.... MAIN .... */
int main(void)
{
_INIT();

for (;;)
{
obsluga_pulsow();
obsluga_rs232();
}
return 0;
} // End of main

[/syntax]
Problem polega na fałszowaniu wyniku pomiaru ADC6 gdy dokonuję także pomiaru na ADC7.

Szczegóły - zakomentowanie:
[syntax=c]
//Pomiar_HV = (94*obsluga_adc(7)) / 100;
[/syntax]
I w terminalu widnieje:

Code:

HV=000V BAT=53428V ADC=0703

, gdzie 5.3428V to napięcie zasilania układu przed stabilizatorem 3.3V.
Po odkomentowaniu powyższego, czyli włączeniu pomiaru napięcia przetwornicy:

Code:

HV=400V BAT=32452V ADC=0427

, pokazuje napięcie przetwornicy 400V - wartość poprawna. Natomiast ADC6 pokazuje wartość zaniżoną mimo, że napięcie zasilania nie zmienia się, a już na pewno nie spada o 2V.
Gdzie się ukrywa błąd?

Statystyki: Napisane przez szopler — 13 wrz 2012, o 17:03