Om jag börjar main med:
DDRB = 0xFF;
så funkar det!
Nu används inte PORTB alls, och givetvis bör man sätta alla oanvända portar som output. Men det känns ändå långsökt att detta är lösningen?
Funkar gör det dock! (förutom att AVR:en just nu korkade helt å hållet - går inte att programmera om, suck!)
Mvh
speakman
ATtiny2313 USART - konstig baudrate
Jag hade samma problem här om dagen.. det ville inte funka. Tillslut så insåg jag att jag inte hade satt fuse-bitarna när jag gick från utvecklingsbordet till det egentillverkade kortet med en annan atmega (dock samma modell). Tidigare använde jag en extern kristall på 8Mhz men den nya atmega använde som default den interna oscillatorn på 1Mhz.
Jag kikade på den här sidan och fick till det på rätt sätt:
http://electrons.psychogenic.com/module ... OGuide.php
Börja med att läsa bitarna.. skriv ner dom på papper och kolla vilka du behöver ändra på. Är du osäker så står standardvärdena i databladed, dvs vilket värde de skulle ha "unprogrammed".
Jag kikade på den här sidan och fick till det på rätt sätt:
http://electrons.psychogenic.com/module ... OGuide.php
Börja med att läsa bitarna.. skriv ner dom på papper och kolla vilka du behöver ändra på. Är du osäker så står standardvärdena i databladed, dvs vilket värde de skulle ha "unprogrammed".
Enligt databladet så är det 0x64 som är default... vilket är intern RC-oscillator@8Mhz.
0x62 är mycket riktigt 4Mhz. Felet ligger nog någon annanstans. De 50Hz/20ms du mäter upp är nog mätbrum och inget som kommer från UART:en skulle jag tro...
Edit: Hur programmerade du fuse-bitarna för att få den att sluta fungera?
0x62 är mycket riktigt 4Mhz. Felet ligger nog någon annanstans. De 50Hz/20ms du mäter upp är nog mätbrum och inget som kommer från UART:en skulle jag tro...
Edit: Hur programmerade du fuse-bitarna för att få den att sluta fungera?
Det kan nog bero på att UBRRH och UBRRL inte ligger bredvid varandra i minnet, och att det därför inte går att köra med UBRR bara. Gissar att det är så iaf. Sen är den iotn2313.h du ska kolla i, inte io2313.h.speakman skrev:Något som också förvirrar mig är varför inte UBRR går att använda? Den defineras ju i io2313.h och borde ju fungera. Om man läser io.h så läser den in ioXXXX.h beroende på vad som är definerat. Jag antar att dessa defineras av kompilatorn m.h.a. --mmcu
Tiny2313 kör med 8 MHz-oscillator med en delare på 8 som standard, dvs 1 MHz. Sätt CKDIV8 till 1 för att inte dela med 8.
Tack för allt engagemang, för det första!
Sodjan:
Har inte kollat AVR, men 8051:orna jag kört rekommenderas att antingen sätta NC pins till Output, eller dra dom till jord. Låter rimligt, varav det borde gälla för samtliga uC:er, mitt tycke.
Vad det gäller nätbrum, så borde inte nätbrummet vara exakt fyrkantsvåg, och rätta sig efter vilken byte som skickas på serieporten.
Dessutom så blir det rätt om jag byter programvara i uC:n. Med exakt samma koppling.
Den enda skillnaden som det visade sig vara, är just de att portarna sätts till utgångar direkt i början. Bevisligen så fungerar det, men jag uppfattar det fortfarande som långsökt.
Ang. fusebitarna så har jag aldrig skrivit dom (eller för länge sedan), utan dom är fortfarande som dom alltid varit.
En sidofråga: Är det ofarligt att köra den på interna RC-osc @ 8MHz? Det pratas om problem med startup-tider i databladet, man kanske måste ändra "SUT0" och "SUT1" för att kompensera?
Mvh
speakman
Sodjan:
Har inte kollat AVR, men 8051:orna jag kört rekommenderas att antingen sätta NC pins till Output, eller dra dom till jord. Låter rimligt, varav det borde gälla för samtliga uC:er, mitt tycke.
Vad det gäller nätbrum, så borde inte nätbrummet vara exakt fyrkantsvåg, och rätta sig efter vilken byte som skickas på serieporten.
Dessutom så blir det rätt om jag byter programvara i uC:n. Med exakt samma koppling.
Den enda skillnaden som det visade sig vara, är just de att portarna sätts till utgångar direkt i början. Bevisligen så fungerar det, men jag uppfattar det fortfarande som långsökt.
Ang. fusebitarna så har jag aldrig skrivit dom (eller för länge sedan), utan dom är fortfarande som dom alltid varit.
En sidofråga: Är det ofarligt att köra den på interna RC-osc @ 8MHz? Det pratas om problem med startup-tider i databladet, man kanske måste ändra "SUT0" och "SUT1" för att kompensera?
Mvh
speakman
cykze:
Du har helt rätt ang. header-filen! Jag har tittat i fel fil hela tiden.
UBRR finns inte definerad i "rätt" fil.0
Mvh
speakman
Du har helt rätt ang. header-filen! Jag har tittat i fel fil hela tiden.
UBRR finns inte definerad i "rätt" fil.0
Menar du "sätt till 0"? F.ö. så är den _inte_ satt som den är programmerad nu (0x64).The CKDIV8 Fuse determines the initial value of the CLKPS bits. If CKDIV8 is unprogrammed,
the CLKPS bits will be reset to 0000. If CKDIV8 is programmed, CLKPS bits
are reset to 0011, giving a division factor of 8 at start up.
Mvh
speakman
> ...rekommenderas att antingen sätta NC pins till Output, eller dra dom till
> jord. Låter rimligt, varav det borde gälla för samtliga uC:er, mitt tycke.
Gäller alla **CMOS** kretsar, inte bara uC:er...
> Ang. fusebitarna så har jag aldrig skrivit dom (eller för länge sedan),
> utan dom är fortfarande som dom alltid varit.
Det viktiga måste väl vara att du förstår hur dom är satta och att du
är helt övertygad om att dom är rätt satta för din applikation.
*HUR* dom blev satta som de är, är mindre intressant...
> Vad det gäller nätbrum, så borde inte nätbrummet vara exakt fyrkantsvåg,...
Nej, och det är det inte på *ingångarna*, vilket är själva problemet.
Ingångarna kommer att pendla fram och tillbaka i olika mellanlägen
mellan "1" och "0" och orsaka olika (oönskade) fenomen i CMOS
ingångsstegen, främst onormalt hög strömförbrukning.
> och rätta sig efter vilken byte som skickas på serieporten.
Du kör utanför spec, och det finns ingen möjlighet att säga vad som ska
eller inte ska hända.
> jord. Låter rimligt, varav det borde gälla för samtliga uC:er, mitt tycke.
Gäller alla **CMOS** kretsar, inte bara uC:er...
> Ang. fusebitarna så har jag aldrig skrivit dom (eller för länge sedan),
> utan dom är fortfarande som dom alltid varit.
Det viktiga måste väl vara att du förstår hur dom är satta och att du
är helt övertygad om att dom är rätt satta för din applikation.
*HUR* dom blev satta som de är, är mindre intressant...
> Vad det gäller nätbrum, så borde inte nätbrummet vara exakt fyrkantsvåg,...
Nej, och det är det inte på *ingångarna*, vilket är själva problemet.
Ingångarna kommer att pendla fram och tillbaka i olika mellanlägen
mellan "1" och "0" och orsaka olika (oönskade) fenomen i CMOS
ingångsstegen, främst onormalt hög strömförbrukning.
> och rätta sig efter vilken byte som skickas på serieporten.
Du kör utanför spec, och det finns ingen möjlighet att säga vad som ska
eller inte ska hända.
sodjan:
När byten på scopemetern stämmer exakt med den byte serieporten skickar, så *borde* det betyda att det fungerar. Det var så jag resonerade.
cykze:
Jag tvivlar inte på vad du säger, du verkar onekligen kunna AVR. Men det jag förundras över är att det i mitt fall stämmer exakt med den tänkta baudraten (efter att ha satt pinnarna till utgångar då förstås), trots att den borde gå en åttondels hastighet?
Ett annat USART-problem är att den vägrar sten att ta in tecken! Mäter upp med scopemetern, och det ser OK ut.
Ska testa sätta DIV8-biten också, men måste göra om koden lite först.
Mvh
speakman
När byten på scopemetern stämmer exakt med den byte serieporten skickar, så *borde* det betyda att det fungerar. Det var så jag resonerade.
cykze:
Jag tvivlar inte på vad du säger, du verkar onekligen kunna AVR. Men det jag förundras över är att det i mitt fall stämmer exakt med den tänkta baudraten (efter att ha satt pinnarna till utgångar då förstås), trots att den borde gå en åttondels hastighet?
Ett annat USART-problem är att den vägrar sten att ta in tecken! Mäter upp med scopemetern, och det ser OK ut.
Ska testa sätta DIV8-biten också, men måste göra om koden lite först.
Mvh
speakman
För att se ungefär vilken frekvens AVR:en kör på så gör du ett program som "växlar" en lysdiod en gång per sekund vid t ex 8 MHz. Sen kollar du med ett tidtagarur hur lång tid det är i mellan. Är det en sekund så är det 8 MHz. Är det två sekunder är det 4 MHz osv.
Lite kod som du kan testa. Tiden mellan en växling, alltså från släckt till tänd eller tvärtom, ska ta en sekund vid 8 MHz. Ta tid!
Det är ju en fördel om man har räknat rätt i koden också, men det bör stämma...
Lite kod som du kan testa. Tiden mellan en växling, alltså från släckt till tänd eller tvärtom, ska ta en sekund vid 8 MHz. Ta tid!
Det är ju en fördel om man har räknat rätt i koden också, men det bör stämma...
Kod: Markera allt
#include <inttypes.h>
#include <avr/io.h>
#include <avr/delay.h>
int main()
{
uint8_t i;
DDRB = _BV(PB0);
while (1)
{
PORTB ^= _BV(PB0);
for (i=0; i<40; i++) // Gör 40 st delay-anrop
_delay_loop_2(50000); // Väntar 50000*4 klockcykler
}
return 0;
}Alldeles riktigt går processorn betydligt snabbare nu. Kör ett antal timrar o dyl. i den övriga koden (styr en R/C-servo), och det märktes direkt skillnad. Fick helt enkelt skala upp allt 8ggr.
Men jag förundras fortfarande hur baudraten kunde stämma tidigare?
Har dessvärre inte haft tid att kolla upp den hur den fungerar nu. Får ta det vid ett senare tillfälle.
Mvh
speakman
Men jag förundras fortfarande hur baudraten kunde stämma tidigare?
Har dessvärre inte haft tid att kolla upp den hur den fungerar nu. Får ta det vid ett senare tillfälle.
Mvh
speakman
