PIC16F876: Clock t.o.v. timers, USART, I³C, ADC en RTC

[Eddy VL]

 

Ik ben van plan om een schakelingetje te maken voor mijn CV (Radson op gas) met een PIC.

 

Nu heb ik er al een Hardware oplossing voor gemaakt, en dat werkt goed, maar die heeft enkele nadelen.

 

Omdat ik nog niet met controllers gewerkt heb, ben ik nu enige proefontwerpen aan het maken. Ik heb een simulatie gemaakt voor een PIC16F676. Die zou wat betreft "de hardware vervangen" voldoen. Ik heb zelfs een pootje over om een RS232 (TXD alleen) aan te sluiten, zodat ik, zij het op 11O baud, zou kunnen loggen.

 

Nu zou ik eigenlijk ook de schakeling en de logging in 1 PIC kunnen doen.

 

Ik wil:

- een aantal temperaturen kunnen loggen (ADC met voldoende precisie.

- met weergave van de tijd in de logs (RTC met tamelijke precisie)

- mag gegevens niet verliezen bij spanningsuitval/uitschakelen.

ik denk hierbij aan de 24AA256EEProm 32k X 8. Alleen heb ik dan een I²C bus nodig...

- De gegevens kunnen opgevraagd worden met een seriele poort (RS232) dus er moet een UART in.

 

Dit steekt allemaal in de 16F876. Heeft geen interne maar externe klok. Kan daar 10, 16 of 20 Mhz kristal voor gebruiken.

Dus timer1 op "interne" klok zou moeten goed zijn als RTC. (of externe klok met batterij in sleep-modus)

 

Maar nu komt de vraag:

- De I²C gebruikt "een" Baudrate Generator om de klokfrequentie te delen (voor 400 khz bvb)

- Usart gebruikt ook "een" Baudrate Generator om uit de (interne) oscillator de baudrate te halen.

 

Is dit DEZELFDE baudgenerator?

 

Want dan wordt gelijktijdig gebruik wel héél problematisch...

 

 

 

Iemand?

 

 

 

Mvg

 

Eddy Vl

 

 

 

 

 

[Matchless]

Citaat:

Is dit DEZELFDE baudgenerator?

 

Want dan wordt gelijktijdig gebruik wel héél problematisch...

 

Naar mijn weten wel. Je kan wel wat spelen met de clock dividers om zo aan je 400khz te komen.

 

Ga even googlen naar de datasheet van die chip, dan heb je gelijk wat programeer voorbeelden.

[Eddy VL]

 

Bedankt Matchless,

 

Dan zal het een andere oplossing moeten worden, 40 pins met 17 bit adresbus vrees ik. Zonder I³C. Ik kan de timing van de RXD niet onderbreken als de brander aanslaat en ik wil ook liefst werken zonder hardware controle... dus liefst geen RTS.

 

Nu is het misschien wel software op te lossen, maar ik probeer het eerst simpel op te lossen.

 

Groeten Eddy Vl

 

 

 

 

[rlckring]

Ik zelf heb wel eens met avr controllers gewerkt.

 

je zou dan kunnen werken met interupts, voor als je brande aanslaat. Op het moment dat er een interupt is (brander slaat aan) kun je gebruik maken van een stack, daar slaat hij dan het huidige address op en gaat daar dan weer verder als je het code blok hebt uitgevoerd wat bij een brander interupt moest plaats vinden.

 

I2C routines heb ik toen dr tijd gewoon opgelost met loops binnen de lees en write functies. Maar er zit er geen interne eeprom in een PIC?? Dan heb je meschien geen I2C nodig. Ik weet niet hoeveel je daar in wilt onthouden? Maar anders kun je het zo naar de interne eeprom schrijven en lezen..

 

En met een AVR initialiseer je de USART (9600/8n1) tijdens opstarten en dat is maar eenmalig, heb je dan verder geen omkijken meer naar. USART werkt op de AVR ook met interupts en stack.

 

Messchien kun je deze techniek ook toepassen met een PIC.

 

Probeer te schakelen met interups en gebruik de stack. Dan kun je ook registers hergebruiken.

[Eddy VL]

 

Wel het loggen, om het kwartiertje de buitentemperatuur, elke verandering van de boiler thermostaat, ik werk nu met een flowswitch in de radiatorketen, waarbij gesampled word om de 3 minuten gedurende 7 a 8 seconden. Ook het openen van de gasklep en sluiten, want die bepalen de hoeveelheid gebruikt gas. We koken ook op gas dus zo moet het mogelijk zijn om het verbruik van verwarming/koken apart te berekenen. Dus wel véél data ook gedurende langere tijd. Dus de inwendige EEPROM is zeker te klein...

 

Het eerste projectje met de PIC16F676 werkt met een timer interrupt van 9 ms. Inputs samplen en dan timecounters opstarten, eventueel dan relaiskes sturen. Op een pinnetje heb ik dan een RS232 TXD voorzien zodat ik data kan oversturen op 110 baud.

 

Voor de 16F876 heb ik het zelf aangegeven dat het software op te lossen is, inderdaad door te choppen, maar als er maar één baud rate (down)teller is kan je geen RXD doen op elk moment, als je data wegschrijft in je uitwendige EEPROM moet je wachten tot dit is afgelopen alvorens je de BRG opnieuw kan gebruiken.

 

Dus ik moet dan de Hardware RTS gebruiken om te vermijden dat ik vanuit mijn PC de data uitvraag. Wat ook niet wil zeggen dat het niet kan opgelost worden...

 

Citaat:

I2C routines heb ik toen dr tijd gewoon opgelost met loops binnen de lees en write functies.

 

Dit is dus WEL een optie, maar het eerste idee was: er steekt I2C in, dus je kan het rechtstreeks gebruiken en er steekt een Usart in, dus die gebruiken we ook, simpel houden dus.

 

Maar omdat ik toch nog niets gemaakt/gekocht heb staat het me vrij om nog te zoeken naar andere oplossingen. Zelfs USB is mogelijk, maar dat heb ik nog niet bekeken.

 

Momenteel is het zo dat ik dus pakken datasheets aan het uitvlooien ben van spullen waar ik dus nog niet mee gewerkt heb. Het is niet zo gemakkelijk om dus direct alle details te kennen van elk systeem/processor.

 

Het spaart dus heel wat tijd uit als je een vraag kunt stellen aan mensen op dit forum die er al mee gewerkt hebben... Het is momenteel toch een denkpiste, de aankoop van de hardware en het proggen komen nog wel als het theoretisch haalbaar is.

 

Maar al zeker reuze bedankt voor het meedenken. Ook andere ideëen zijn welkom hoor.

 

M.v.g.

 

Edy Vl

 

 

 

[Matchless]

Kijk eens voor een arduino/freeduino.

 

Daar kan je bijv een sd-kaartje op aansluiten om de logs op te slaan.

 

Ook is er een grote community waar veel kennis zit.Handig omdat er dan ook al veel code te vinden is.

 

In principe moet je met een arduino je project aan het lopen krijgen.

[satbikkel]

hallo,

het ligt er een beetje aan hoeveel data je wilt bewaren.

maar de meeste pic's hebben een intern eeprom...

 

dus waarom moeilijk doen als het makkelijk kan!

 

ik weet niet in welke programeer taal je het wilt maken, maar ben zelf we fan van picbasic. voor voorbeelden kijks op www. picbasic.nl

[Matchless]

Citaat:

maar de meeste pic's hebben een intern eeprom...

 

Dat klopt, alleen is het geen "vetpot". Die zit zo vol als je gaat loggen.

[Eddy VL]

 

Citaat:

maar de meeste pic's hebben een intern eeprom...

 

de PIC16F867 heeft 256 byte EEPROM.

- datum opslaan: 3 bytes

- Uur opslaan: 3 bytes + 1 byte inputs + 1 byte output = 5 bytes. Minimaal 4 veranderingen als brander 1 maal aanslaat = 5 X 4 = 20 bytes.

 

12 X brander aanslaan = 240 bytes + 3 bytes van de datum...

EEPROM vol...

 

Matchless heeft gelijk...

Citaat:

Dat klopt, alleen is het geen "vetpot". Die zit zo vol als je gaat loggen.

 

Dus extern stokeren. Ram met batterij, paralelle EEPROM of seriële EEPROM...

 

Arduino gebruikt ATMEGA processoren, en die kunnen wél gelijktijdig I2C en USART. Ben nu ATMEL processoren aan het bestuderen, ziet er goed uit, zal dan ook trachten te onderzoeken wat Arduino te bieden heeft aan mogelijkheden.

 

M.v.g.

 

Eddy Vl

 

 

[Matchless]

De arduino is een atmel ontwikkel bordje maar heeft als voordeel dat het programeren wat makkelijker gaat. Ook heb je daar verschillende atmels versies voor.

 

En je kan zgn shields (opsteek printjes) krijgen voor bijv een kaartlezer, bleu-tooth of een netwerk aansluiting.

Ook is er een mini versie te krijgen.

 

Goedkoper en (bijna) precies hetzelfde is een freeduino.

 

Als je het nog goedkoper wilt maken dan pak je een atmel en zet dan de arduino bootloader er zelf op.

 

Het hele gebeuren is nl open source.

 

Maar ik zou iig niet voor een externe eeprom gaan omdat dit duurder wordt als je later toch te weinig ruimte zou hebben. Pak het dan goed aan en gebruik een sd-kaartje. Die kosten geen drol meer. Ander voordeel is dat je er zo weer een nieuwe sd ingeprikt hebt zou de oude vol geschreven zijn. En die oude kart kan je evt bewaren als een soort archief.

Schrijf je er een software bij op je pc dan kan je alles terug bekijken.

[Eddy VL]

 

Matchless,

 

ik sluit de SD-kaart niet uit hoor, is best een goed idee, maar vereist vermoedelijk een extra pak software, en ik heb de hardware ook nog niet bekeken... Ik kan het momenteel niet allemaal tegelijk verwerken. Ook de Arduino momenteel niet, want ik wil eerst weten wat de processor kan.

 

Ik heb de Bootloader zien staan ook bij Atmel. Dus ook hier mogelijkheden.

Ook de EEPROM is nog niet afgeschreven, want met I2C heb ik in principe 8 adressen, dus dat kan ook.

 

De Arduino kaartjes moeten dan geintegreerd worden in de besturingseenheid van de brander (nog te maken). Met hierbij de mogelijkheid om de ATmega op de print van de besturingseenheid te zetten, programma zelf schrijven of bootloader gebruiken. Dus in alle geval: leren wat mogelijk is met zo'n ATmega. (en dat is wel véél, ik ben er nog een tijdje mee bezig)

 

Ik denk dat ik alles ga moeten opsplitsen in kleinere stukken en één voor één uitpuzzelen, want ik vraag eigenlijk wel veel voor een eerste projektje.

 

- zes ingangen, zes uitgangen om het warm te krijgen... te samen met de bijhorende hardware, ik sta paralel op de ingangen van de bestaande besturingseenheid, dus eigenlijk hoogohmig meten om de bestaande werking niet te verstoren. En de besturing, behalve de gasklep/detectie, neem ik over met relais. Dit alles ligt al tamelijk vast. Het gemakkelijke deel dus.

 

- het loggen van minimum 2 temperaturen: bvb de KT100 als "voeler", en de ADC gebruiken.

 

- het opslaan van de gegevens, die moeten bewaard worden bij spanningsuitval. Parallele Ram met batterij vereist meer pootjes en/of dlatches. Dus liever seriëel (of SD).

 

- Usart om de gelogde gegevens op te vragen met de PC

 

- de RTC: bij het loggen wil ik het uur (seconden vanaf middernacht) meegeven en op 0 uur de datum loggen.

 

En dit laatste ben ik momenteel aan het nazien of het kan. Ik kan daar momenteel zelfs wat hulp voor gebruiken.

 

Het klokje met datum moeten toch zo'n 8 a 9 dagen zelfstandig blijven lopen. Dus ik moet een batterij of backupcondensator voorzien. Een uitwendige RTC is ook mogelijk (met batterij backup condensator)

 

Of ik zet de processor in sleep. Met een 32768 Khz kristal op Tosc1 en Tosc2 (AtMega8 - processor) kan ik Timer2 aansturen.

 

Als ik daarvan 5 bits gebruik en de prescaler op 7 zet kom ik aan 1 sec. (kan dus nog 3 bit gebruiken). Maar voor het aantal seconden na middernacht heb je in totaal 17 bit nodig, dus heb ik heb nog 14 werkende bits nodig zodat ik tijdens de sleep, ééntje kan bj optellen per seconde.

 

Dus wat ik nu wil weten is: wat werkt er nog in de verschillende powerdown modes?

Processor? Interrupt van timer2 ? Registers? Ram?

 

Ook in het geval van sleepmode moet er een batterij/lader/switch bijkomen om de klok levend te houden.

Is dus ook nog niet opgelost.

 

Momenteel zou ik eerst willen weten hoe ik de real-time clock

zou kunnen doen. Misschien heb jij daar ervaring mee of iets zien staan?

 

M.v.g.

 

Eddy Vl

 

 

 

 

 

 

 

[Matchless]

Citaat:

Ik ben nu aan het nazien of ik de ATMEGA zo ver kan krijgen.

 

Alleen was ik van plan om de seriële uitgang te gebruiken om een SD-kaartje te integreren. Wordt dus dringen als ik nu tegelijkertijd een I²C bus moet maken... Er zit maar 1 seriële uitgang op. En de USART heb ik ook al nodig.

 

Ik zal dus keuzes moeten maken.

 

 

Maakt de SD interface geen gebruik van I2C ? Dan is het een kwestie van adresseren.

 

Wat je ook zou kunnen uitzoeken is dat je eerst de data in de eeprom laadt en dan na een bepaalde tijd de eeprom naar de SD kaart schrijft.

 

Je hoeft immers niet alles tegelijk te laten doen (wat bij een microprocessor ook niet gaat).

 

Een andere mogelijkheid is een 2e atmel die alleen voor de CF kaartje wordt gebruikt. Voor de prijs hoef je het iig niet te laten.

[Eddy VL]

 

Dit komt van MAX

 

Citaat:

The schematic in Figure 1 shows a typical application circuit. The SD card requires full-duplex, 8-bit SPI operation. Data is clocked into the card's DI pin from the MAXQ2000's MOSI pin, and out of the card's DO line into the MISO pin of the MAXQ2000. Data is clocked simultaneously in and out of the card on the rising edge of the CLK line. Eight extra clocks must be provided at the end of each transaction to permit the SD card to complete any outstanding operations. The input data during these extra clocks must be all ones. Clock rate must be limited to a maximum of 400kHz during the identification phase, but can be increased up to 25MHz once the SD card has been identified.

 

MAXQ2000 SPI Module

 

The MAXQ2000 contains a hardware SPI module that is easily configured for the SD card interface. To configure the clock polarity and data length, the SPICF register is programmed to all zeros. This configures the SPI module to latch data on rising clock edges and sets the data length to eight bits. For this application, the MAXQ2000's system clock frequency is 16MHz. In that case, the SPICK register is programmed to 0x28, which results in an SPI clock of approximately 380kHz. The SPI master mode must be enabled by setting the two lower bits of the SPICN register.

 

En ik heb ook dit gevonden (zie bijlage)

 

Is blijkbaar een gesynchroniseerde seriële poort. En voor zover ik gezien hebt werkt hier geen adressering op. 1 master = 1 slave.

 

LM75

 

Een ander nadeel van de LM75 is dat je meer draadjes nodig hebt voor I²C dan voor een KT100, en je moet de I³C naar buiten brengen over eventueel een lange lijn. En dat zie ik dan minder zitten. Omvormen zou bij de LM75 wel niet nodig zijn, de temp wordt wel in graden gegeven.

 

Het tijdelijk opslaan heb ik ook in gedachten, maar dan als overbrugging wanneer er andere activiteiten zijn. Ik heb trouwens nog zoiets dat zo opgelost moet worden: er moet een input buffer komen om de inkomende karakters van de USART op te slaan, met dezelfde reden. Dus er zullen redelijk wat bytes in de RAM of EEPROM moeten ook.

 

Momenteel heb ik al iets gemaakt op Sim voor de RTC. Op de controller heb ik het INT0 pootje voorzien voor aanwezigheid van de netspanning. Bij afwezigheid gaat hij naar sleep om de batterij te sparen. De RTC loopt gewoon door.

 

Om het kwartier moet hij de temp meten. De timing hiervoor steekt er in. Maar wanneer het net wegvalt en daarna terugkomt, moet de timer opnieuw berekend en ingesteld worden op het volgende kwartier.

Steekt er dus ook in.

 

Word dus wel een complexe zaak. Maar nu eerst de temp meting oplossen...

 

Mvg

 

Eddy Vl

 

 

 

[Matchless]

Kijk eens naar deze projecten.

 

Daar kan je iig weer wat idee-en opdoen.

[Eddy VL]

 

Bedankt voor de link

 

Van niet al zijn projecten is de code beschikbaar, maar de SD zal zeker van pas komen (FAT sector!)

 

Mvg

 

Eddy Vl