AD omvandlare

[gripner]

Håller på med ett litet projekt där jag har 3 givare som ger en analog späning ut, 0.4-2.8V

Dessa 3 vill jag in med i en uC tex atmega at90usb xxx via en AD omvandlare

Har kollat runt lite på elfa och det finns ju en hel del i alla prisklasser, FÖR många.
Så, någon som har erfarenhet av en simpel 1 eller 4 kanalers AD och kan rekomendera.

1 eller 4 kanaler
5V drivspänning
0-5V mätområde
parallelt eller serielt interface mot uC
Inget behov av extern klocka.
Om 4 kanaler skall de 4 kanalernas signal lämnas över till uC som 4 värden ej multiplexat eller dylikt.
Så lite kringkomponenter som möjligt
Parallelt interface mot uC är oxå ok.

Har aldrig programerat spi, i2c etc så det seriella interfacet får gärna vara "normalt PC serielt interface rs232" men med ttl nivå 0/5V. Inget hackande om benämningar tack, ni som kan detta förstår vad jag är ute efter.

MAX158 har jag fastnat lite för, dock verkar den vara utgående...

[rehnmaak]

Atmega har väl inbyggda ad-omvandlare eller räcker inte 10 bitar (tror jag de är)?

[jesse]

Du har en del detaljerade krav som t.ex. "Om 4 kanaler skall de 4 kanalernas signal lämnas över till uC som 4 värden ej multiplexat eller dylikt." och samtidigt vill du gärna ha "rs232"... ??? Det funkar nog inte så riktigt.

MAX158 har ju just en multiplexer - det du inte ville ha.... men om du vill ha åtta bitar parallellt ut i fyra kanler utan att multiplexa så måste du ju ansluta fyra separata AD med 8 bitar från varje... 32 bitar!

Men nu ska jag försöka att inte klaga utan vara konstruktiv.

MAX158 har bara 8 bitar. en AVR processor har vanligtvis en inbyggd ADC med 10 bitar (som redan nämnts). Ofta har du sex eller fler kanaler till den. Så det är bara att ansluta dina fyra analoga ingångar direkt till fyra ben på processorn. (Visserligen är de också multiplexade, men det är ju det absolut enklaste sättet att göra det på.)

Så kör på den inbyggda ADC:n om det inte finns något väldigt speciellt skäl att inte göra det. (Då blir det noll kringkomponenter, förutom kanske någon kondensator eller så).

Om du använder VCC som referens (och vi antar att denna är exakt nog) så kommer dina inläsa 10-bitars värden att ligga mellan 82 (0.4 volt) och 573 (2.8 volt).... det blir en upplösning på 0.004 volt, eller 491 "steg". Om det räcker?

[gripner]

På MAX158 väljer man via en matris på 3 av dess pinnar vilken analog ingång man skall läsa av och konvertera, så man kan få ut från den värdet för vardera analog ingång smidigt.

Jag hade för mig att uCn jag tänkte använda at90usb endast hade 1 ad omvandlare, ska kolla datablad, hoppas verkligen att det är som skrivits innan att de kanske har fler, beror väll på modell.

edit:
kommer använda mig av atmel USB1286
http://www.atmel.com/dyn/resources/prod ... /7593S.pdf
ser ut som den har 8st 10bits adc om jag inte tolkar det fel. Räcker ju mer än väl för mig!

ibland går man över ån efter vatten

[Icecap]

µC'n har bara 1 st AD-omvandlare men den har en 8-input multiplexer.

Och sedan undrar jag över varför topic i denna tråd är "DA omvandlare"?

[4kTRB]

Kryptiskt.

I alla fall så är
DAC1020/DAC1021/DAC1022
10-Bit Binary Multiplying D/A Converter
DAC1220/DAC1222
12-Bit Binary Multiplying D/A Converter
från National attraktiva, finns 10-bit,9-bit, 8-bit
och hyggligt snabba, anpassbara till TTL-nivåer.

[gripner]

jag har aldrig arbetat med en adc förut, än mindre en multiplexad. Så en dum fråga kanske, då den i tänkt uC är multiplexad, måste man i koden "välja" vilken av de 8 analog input pinen man "läser av" och konverterar ?

Välj pin 0-7 via 3 bitar tex 0 0 1 = pin 1
läs adc
spara data

välj pin 0-7 via 3 bitar tex 0 1 1 = pin 2
läs adc
spara data


medan en icke multiplexad skulle man i koden kunna göra något simplare som tex
läs adc tillhörande pin0
spara
läs adc tillhörande pin1
spara

etc

Har jag fattat något rätt ?

[sodjan]

> måste man i koden "välja" vilken av de 8 analog input pinen man "läser av" och konverterar ?

Ja, det är en av initieringarna man gör:

1. Välj generella ADC parameterar (omv.hastiget o.s.v)
2. Välj kanal.
3. Starta omvandlig och vänta på klarsignal.
4. Läs av och spara värdet.
5. Gå tillbaka till 2, om det behövs.

Alternativt är 4 helt separata ADC'er, om man har väldigt höga
krav på att alla kanalerna måste "frysas" i samma ögonblick.
Vilka krav har du ? Det har inte framgått (i siffror !).

> Har jag fattat något rätt ?

Ja, något...

[gripner]

Har inget krav på prestanda

Jag kommer trycka på en knapp för att starta inläsningen av 4 värden som sen skall visas på tex en display. om det tar lite tid att "loopa" igenom de adc pinnarna som skall användas för att få tag i datan som skall visas gör ingenting, det rör sig ju ändock bara om bråkdelen av en sekund.

[sodjan]

> Har inget krav på prestanda

*Självklart* har du det! Men vad är det ? En halv sekund?
En sekund? En 1/10 sekund? Men säg inte att du inte har
något krav alls...

Ja, man läser 4 kanaler på någon eller några millisekunder.

Av ditt första inlägg kunde man få intryck av att även det var
för långt intervall mellan varje kanal. "Ej multiplexat", stog det.
"Varför?", frågar man sig då... Normalt är det p.g.a prestandakrav.

Men om några ms är OK, och 10 bitar också är OK, så finns det
få anledningar att söka sig utanför själva processorn. Jag tror
inte att det blir mindre programmeringsjobb med intern ADC än att
hålla på med gränssnittet mellan processorn och externa ADC'er.

[jesse]

> Har inget krav på prestanda

hehe (har lite roligt åt Sodjans svar)....

Skriv en separat rutin som gör jobbet: (efter att ha initierat ADC:n)

Kod: Markera allt

ställ in kanal (nr)
vänta (man ska vänta lite så att kanalen hinner stabiliseras innan konvertering startar)
starta konvertering
vänta på att ADC ska bli färdig
läs in resultatet
returnera

Då blir det ju sedan väldigt enkelt om man vill antingen loopa igenom alla kanaler eller om man vill välja att läsa någon specifik kanal. En detalj bara, om du ska loopa igenom kanaler: Jag vet att den kod / nummer man ska skicka inte alltid är 0,1,2,3,4 för de olika kanalerna utan kan lika väl vara 33,35,65,67 eller något annat ologiskt. Så när jag gjort liknande saker har jag lagt in en liten tabell som den letar upp rätt kanalkod i. Koder för kanalerna finner du i binär form i databladet.

Skriver du i assembler eller C?

[sodjan]

> hehe (har lite roligt åt Sodjans svar)....

För att det var bra/rätt eller tvärtom ?

[jesse]

>För att det var bra/rätt eller tvärtom ?

Första stycket... "*Självklart* har du det!"...
Det återkommer alltid i diskussionerna, så jag skrattade lite åt det idag.
Annars var det väl helt korrekt.

Tidskravet har vi nu fått utrett - det klarar sig bra om det går att läsa alla fyra kanaler inom en halv sekund, och det går ju utan problem.

Kravet på precision verkar ju också vara uppfyllt, även om vi inte vet exakt hur dåligt det får bli:
Gripner: "10bits adc räcker ju mer än väl för mig!"

OK. Jag räknade ju lite på upplösningen ovan. Man kan ju även läsa in enbart de åtta översta bitarna från ADC:n om man vill. Det blir då ca 0.02 volt upplösning med VCC som referens. Så kan du jobba ned åttabitars tal.

[gripner]

Troligen kommer jag använda den interna ref spänningen, om jag inte missförstod det var den på 2.56V eller i närheten.
Jag kommer mäta mellan 0.4V och 2.4V
blir mer än ok upplösning med 8bitar.
Det är lite vikter som skall överföras 1-50kilo. behöver inte vara nogrannare än 0.5kilo. Även om det kommer bli det.

Programmet i uC:n blir simpelt till att börja med
Antingen kommer programmet fungera enligt nedan

initiera/konfigurera usart
sätt baudrate
sätt 8n1

Initiera/konfigurera ADC
Tänd diod för att indikera att "adc:n lever" (felsökningens skull)

:start på loop för de 3-4 mätvärderna
ställ multiplexer för att läsa adc pin 1
läs adc pin 1 till variabel
sänd variabel med adc värdet till usart + identifiering vilken pin som lästs
goto början på lopen och kör vidare med adc pin 2,3,4

om sista pinnen är läst vänta 1sek och börja sedan om.

Eventuellt skall IRQ användas istället

när irq genereras från USART vid mottagande
loopas de 3-4 adc pinnarna igenom och skickas till usart send.

Detta alternativ för att man skall kunna starta "viktfångandet" från programet på PC:n istället för att det ligger och läser av konstant.

väldigt simpelt program för folk som kan det här, men måste erkänna att man f¨r huvudverk då man inte rört C sedan 1997..... Men det tar sig! Och senast man använde en uC i någon form var motorolas 68HC serie om jag inte mins fel 1995

[jesse]

>inte rört C sedan 1997

Alltid kul med en nystart.