Kan köra en ren/naken arduino?

[sodjan]

> UNO kortet har en ISP-kontakt...

Sorry!!
Ja, den har *två*, jag hade fått för mig att det enbart fanns
en ISP kontakt ansluten till den andra (USB-) AVR'en...

> Så ni menar att jag behöver inte använda mig av någon
> bootloader(trots att alla andra använder det vid alla tillfällen)...

Anledningen till att "alla andra" kör USB/bootloader är ju så klart att
det inte behövs någon extra hårdvara (ISP-programmerare)!
Det är ju själva "grejen" med Arduino...

Om du nu ändå ska köra med UNO-kortet, så finns det ingen större
anledning att *inte* köra "the Arduino way", så att säga. Ja, det finns
några småsaker, t.ex om 1 sek delayen i bootloadern är ett problem,
det får du själv avgöra.

[Jonaz]

Precis Ingen bootloader behövs med den programeraren när du kopplar in den i RÄTT ICSP Kontakt.
Edit: svar till Al bundy

Edit2: AVR ISP MK 2, ingen bootloader behövs, men om du skall köra med USB kabeln från datorn till UNO kortet så behövs en bootloader.

[Al_Bundy]

Vad bra!

Det förklarar varför alla som kör med AVR ISP MK 2 säger att man inte behöver tanka ner en bootloader eller osv från nätet.



Vid 1.38 så väljer han "Burn Bootloader". Han använder sig av en ATmega328P-PU.
Om jag nu använder en ATmega8-16PU på en UNO och vill bränna in en bootloader på den. Då väljer jag bara Arduino NG /w ATmega8 som board istället för UNO som board? Eller har detta absolut ingen betydelse nu när jag använder AVRISP MK 2 för att bränna in en bootloader? Men om jag ska bränna en en sketch via USB så måste jag välja Arduino NG /w ATmega8 som board istället för UNO som board?

Jag vet att ATmega8 har nästan samma pinmapps än ATmega168/328, men jag kommer inte använda ATmega8 på UNO permanent. Det kan röra sig om någon fler digital ingång/utgång har en PWM mer på en ATmega168/328 än ATmega8. Annars när det gäller setup av kristall, motstånd och kondensatorer så är dom det samma.
Jag tänker bara använda min UNO för att placera tomma ATmega8/168/328 och bränna in en bootloader med AVRISP MK 2 och sedan bränna över ett program via USB:n. Efter det tänker jag ta bort ATmegan och använda den som en "standalone Arduino" på ett vanligt PCB-kort.
Jag tar bara bort de 3 gula kablarna och den gröna kabeln, men låter resten av komponetner och kablar sitta kvar på plattan.


Så hade jag tänkt iallafall.
Jag vet nu att det är ganska onödigt att bränna en en bootloader på en ATmega, om man redan har en AVRISP MK 2 och målet är att köra en naken arduino bara. Men det är för att inte krångla till det så mycket

[Al_Bundy]

> UNO kortet har en ISP-kontakt...

Sorry!!
Ja, den har *två*, jag hade fått för mig att det enbart fanns
en ISP kontakt ansluten till den andra (USB-) AVR'en...

> Så ni menar att jag behöver inte använda mig av någon
> bootloader(trots att alla andra använder det vid alla tillfällen)...

Anledningen till att "alla andra" kör USB/bootloader är ju så klart att
det inte behövs någon extra hårdvara (ISP-programmerare)!
Det är ju själva "grejen" med Arduino...

Om du nu ändå ska köra med UNO-kortet, så finns det ingen större
anledning att *inte* köra "the Arduino way", så att säga. Ja, det finns
några småsaker, t.ex om 1 sek delayen i bootloadern är ett problem,
det får du själv avgöra.

Det är mycket mer som är "grejen" med arduino också.
Lätt kod. Allt nästan färdigt. Enklare...kanske inte för mig direkt
Kollar man ett blinkprogram med AVR studio och Arduino IDE så skiljer dom sig väldigt mycket.
Kolla här:
http://www.evilmadscientist.com/2012/bl ... th-an-avr/

[olof_n]

How does it work?

The "Burn Bootloader" commands in the Arduino environment use an open-source tool, avrdude. There are four steps: unlocking the bootloader section of the chip, setting the fuses on the chip, uploading the bootloader code to the chip, and locking the bootloader section of the chip. These are controlled by a number of preferences in the Arduino preferences file.

"setting the fuses" är en viktig del. Jag har skrivit det tidigare. Första gången bör du bränna bootloadern OAVSETT om du ska använda den eller ej för att sätta alla "fuses". Gör du inte det måste du göra det manuellt (via avrdude).
Sedan när du laddar upp koden vi din ISP-programmerare skrivs bootloadern över men alla "fuses" är kvar.

[Glenn]

Jag tycker PIC-koden är så kletig jämfört med Arduino-koden.

PIC-kod i vilket språk ? asm ?

Det är ju inget som säger att du måste köra lågnivå, du kan ju köra något högnivåspråk och kompilera för PIC också.

Jag har tidigare postat riktigt korta väldigt läsbara exempelprogram som gör saker i PBP (PIC BASIC Pro), många kör C och där
ser nog programmet ungefär likadant ut som det gör när du skriver i arduino-IDE.

[Icecap]

Al: "Kollar man ett blinkprogram med AVR studio och Arduino IDE så skiljer dom sig väldigt mycket."

Det gör dom ju inte! Skillnaden är att i AVR Studio-fallet skrivs koden för Delay() in och det behöver du inte göra i Arduino-fallet.
Men det konstiga är att du inte behöver göra det i AVR Studio heller, delay()-funktionen finns redan så du jämför två olika sätt att lösa en uppgift på och konkluderar att äpplen är enklare än banan.

Men du kan inte jämföra dom utan att göra det på lika villkor.

Jag kan visa dig C-kod på 10k+ rader och asm-kod på 30 rader, då kommer du att tycka att asm-koden är lättast - men det är den inte! Den är bara minst...

Och "minst" betyder bara att man vet väldigt lite om vad som händer.

[Al_Bundy]

ICE!

Här är en AVR kod:

Kod: Markera allt

#define F_CPU 20000000    // AVR clock frequency in Hz, used by util/delay.h
#include <avr/io.h>
#include <util/delay.h>
 
int main() {
    DDRD |= (1<<DDD1);          // set LED pin PD1 to output
    while (1) {
        PORTD |= (1<<PORTD1);   // drive PD1 high
        _delay_ms(100);         // delay 100 ms
        PORTD &= ~(1<<PORTD1);  // drive PD1 low
        _delay_ms(900);         // delay 900 ms
    }
}

Hade jag fått välja så hade jag skrivit så här:

Kod: Markera allt

#include <avr/io.h>
#include <util/delay.h>
 
int main() {
    DDRD = 1;          // set LED pin PD1 to output
    while (1) {
        PORTD = 1;   // drive PD1 high
        Delay(100);         // delay 100 ms
        PORTD = 0;  // drive PD1 low
        Delay(900);         // delay 900 ms
    }
}

Varför krångla till det?
Allt detta ~ > | < & och vidare hocus pocus bör man skippa!

Typ när man skriver ^= till en variabel. Dafuq!

[Wedge]

Om allt du bryr dig om är en enda LED på LSB i PORTD så spelar det ingen roll vilket du använder, men inbilla dig inte att de två senaste koderna gör samma sak.

>Allt detta ~ > | < & och vidare hocus pocus bör man skippa!
Eller så lär man sig vad det betyder, och argumenterar inte så dumt.

[ajje]

Jag kan inte låta bli att flika in att ibland luktar det som under en bro....

[sodjan]

DDRD och PORTD är 8-bitars register. Man bör alltid skriva
värden som definierar alla *8* bitarna. Dina kodexempel gör
inte alls samma sak:

> PORTD |= (1<<PORTD1); // drive PD1 high

*OCH* lämnar övriga pinnar *SOM DE ÄR* !!

> PORTD = 1; // drive PD1 high

*OCH* sättar alla andra bitar *TILL 0* !!

En jäkla stor skillnad! Du vet helt enkelt inte vad du skiver om
och inte heller hur processorn fungerar i grunden.

En del andra C miljöer för t.ex PIC har speciella definitioner/symboler för
de individuella bitarna i olika register, då hade man skrivit något i stil med:

> PORTDbits.1 = 1; // drive PD1 high

Det kan jag personligen tycka är "renare" än:
> PORTD |= (1<<PORTD1); // drive PD1 high
men det är mest vana.
Jag har inte hittat något liknande för AVR.

[Icecap]

Al: i Arduino skriver man ju Setpin() (eller vad det nu heter) och om du har svårt att tro att det kan göras på samma sätt under icke-Arduino får du väl ha den tro, det indikerar ganska tydligt vad du har visat med all oönskat tydlighet: din insikt i µC-världen är noll.

Man kan definiera saker om det är enklare, jag gör det jämt! Exempel:
#define P_Beacon PDR6_P60 (Saxat från ett aktuellt projekt och betyder: Port 6, bit 0)

Då kan jag skriva:
P_beacon = true; // Och då går den pinne till '1'

Och skriver jag:
P_Beacon = false; // Går pinnen till '0'

Man kan även definiera dessa portbits på ett sätt som du sannolikt inte förstår just idag och som ger tillgång dill varje portbit efter behag, kompilern får sedan göra grovjobbet. Och denna definition ska man göra en enda gång för en viss cpu-typ, sedan är det bara att inkludera den filen man sparar det hela i projektet.

Som andra skriver: att du inte förstår vad du gör betyder inte att ditt sätt är bättre, det kanske är enklare för dig men det visar bara att du inte har fattat systemet.

Tar man en portpinne är det få µC som har ett instruktionssätt som medger att man kan ändra en bit i porten utan att "röra" de andra - och även då blir det en RMW-instruktion!

Och RMW då? Read - Modify - Write

Pinnarna i en port sitter till ett utgångsregister. Detta register kan inte ändra en enda pinne selektivt, alla 8 bit skrivs varje gång. Alltså måste den ändra en bit vid att läsa av läget (Read), ändra rätt bit till rätt läge (Modify) och sedan skriva det tillbaka (Write) till registret.

I din värld kan du använda en bit per port om du vill fasthålla ditt enklare sätt, i "vår" värld kan vi använda alla 8 bit i samma port till olika saker vid att "klydda" med |&^~ osv. Och gör det ont i dina ögon går det att göra så att du inte behöver att titta på det, det är bara att definiera lite, sedan är saken biff.

Det är mycket tydligt att din insikt i vad du jobbar/lekar med är så nära noll den kan bli och jag skulle verkligen råda dig till att läsa lite böcker m mikroprocessorer och deras funktioner, då kanske du inser att en ATmega inte är speciellt olika en Z80 eller 6502, 8031 eller liknande fossiler.

[sm5tfx]

> UNO kortet har en ISP-kontakt...

Sorry!!
Ja, den har *två*, jag hade fått för mig att det enbart fanns
en ISP kontakt ansluten till den andra (USB-) AVR'en...

Ja, den har faktiskt två MCU:er också...
Den ena, vars ISP-kontakt sitter på ena långsidan i "USB-änden" av kortet är för den ATmega8 som agerar USB-UART (på äldre kort sitter det nån FTDI för den funktionen). Den andra, som sitter mitt på ena kortsidan på kortet, är för ATmega328:an som är den egentliga Arduino CPU:n.
Det är alltså den senare man vill använda om/när man ska bränna en Arduino bootloader.

[elf98]

Lyssa nu!
Jag beställde paketet och betalade 8 dollar för det. Jag fick det godkänt att paketet hade skickats och jag hade fått ett spårnings nummer. Efter 7-10 dagar så SKALL spårningsnumret vara aktiv, annars så ska man kontakta säljaren. Det är deras policy. Jag gjorde det, men fick inge svar...eller fick bara autosvar. Efter 25 dagar så valde jag stänga stänga ned orden av anledningen at spårningsnummret fungerar inte. Säljaren kontrollerar orden och accepterar.

Efter några dagar senare så fungerar spårningsnummret...efter 30 dagar!

Så du har betalat ändå?

För oavsett när spårningsnummret börjar fungera ska du självklart betala för det som levereras till dig. Allt annat är bedrägeri.