Varför 8 bit?

[vespaman]

(Vad konstigt att man inte få quote på sista inlägget)

>Du verkar utgå från att alla 32-bits miljöer med automatik alltid har GNU-miljöer för utvecklingen.

Nejdå, men de flesta... Finns ju även en del 8-bitars med i påsen tror jag ...

Varför jag nämde de som jag jobbat med, var för att jag tänkte att du var intresserad av alternativ (och då vore det ju inte så smart att prata om sådana som jag inte har erfarenhet av). Dessutom blir det en låång lista om jag skulle lista alla som verkligen supportas. Och solen skiner ute

>Att det saknar värde. Ingen vill ju använda något "knäppt".
>Det gör det ju inte att argumentet är fel, så klart, bara utan värde.

Snarare väldigt mycket värde, om ingen vill använda det knäppa? Kanske det bästa argumentet för att välja en annan lösning isf?

>Men du kanske räknar allt som inte är GNU som "knäppt".

Varför tror du det? Kör inte något GNU IDE själv, dock gdbserver i bakgrunden såklart.

Min bakgrund är att jag har jobbat med många processorfamiljer genom åren, och många debuggers/emulatorer och det har alltid känts så trist att sätta sig in i en ny, dessutom tar det värdefull tid att lära sig. Är dessutom sjukt trött på de enorma kostander som det *kan* röra sig om, speciellt om man är några stycken i projektet.

Men detta känns inte som en konstruktiv diskussion, rätt off topic. Mitt argument är fortfarande att det är en fördel att ha en toolchain som man kan 'återanvända' många projekt.
Och nej:- alla processorer på denna jord supportas *inte*, men det är iaf lätt den som har flest.
Och ja:- detta är ett argument av många. Ta det för vad det är värt. Applicera argumentet i er egen situation och förkasta det om ni redan har er 'guldmiljö' och ni inte behöver byta, eller om vald processor inte supportas, eller, eller ...

[sodjan]

> (Vad konstigt att man inte få quote på sista inlägget)

Det går alldeles utmärkt, som i detta inlägg...
(Däremot kan du inte använda quote-knappen, men den är enbart för lata).

Men jag konstaterar att vi är helt överens! Solen skiner faktist ute.

[Icecap]

För mig känns det lite konstigt med så mycket fokus på antal bits.

Det viktiga är i sista ändan egentligen att man har ett fungerande IDE och såklart att hårdvaran klarar jobbet och har de periferifunktioner som behövs.

Sedan tillkommer effektkrav, kapsling, EMC osv. men de har i grunden inget med antal bits att göra.

I gamla dagar där man hade en MCU-krets, en bus-controller, RAM, EPROM, UART, TIMER osv. i var sin krets var det en del mer att tänka på, speciellt eftersom priserna var ganska intressanta på dessa kretsar.

Nu för tiden är datakraft mycket billig varför man kan välja ganska fritt. Avser man att göra många olika projekt kan det vara en fördel att hålla sig inom en viss familj, då kan man oftast klara sig med samma debug-verktyg och IDE och man "känner" familjens egenheter, något som är mycket mer värdefullt än att sålla mellan 8/16/32 bit.

En 32-bit behöver inte vara mer kraftfull än en 8 eller 16-bit, det beror helt på applikationen - men såklart kan den vara det i rätt applikation!

Oftast är det ju så att man jobbar med ganska liknande projekt, det är ju ganska sällan att det blir utveckling till en rymdsond ena dagen och en "blinka LED" nästa dagen, alltså kan man ställa upp övergripande krav på vad man behöver och sedan hitta den rätta processorfamilj för detta, då är saken biff.

Men om det inte fanns någon anledning att använda 8-bitars µC ville det inte heller säljas några - men då de är storsäljare fortfarande finns det tydligen ett behov!

[blueint]

Man kan ju inte *enbart* utgå från en så teknik-nörd orienterat perspektiv
som att det *måste* vara GNU-toolchain eller liknande. Det kanske kan vara
en parameter ifall man redan är "inkörd" på just det, men annars är det bra
en parameter som vilken som helst annars.

Dokumentation, exempel, know-how, osv är enorm när det gäller GNU-toolchain. Därför blir det mindre inlärningströskel. Mindre risk att den upphör i framtiden och ens källkod blir inkompatibel. Man är också oberoende av enskilt företag som tillhandahåller verktyg. Möjligheten att inkludera kompilatorn med produkten, eller använda annat än x86 plattformen för utveckling är andra möjligheter.

De flesta vill sannolikt ha något som "gets the job done" så att säga.
Och gärna ha en single-point-of-support när det strular.

GNU-toolchain har så gott om exempel att man oftast kan gå rakt på huvudmålet rätt snabbt. Och man kan återanvända tidigare kunskap eftersom GNU består över tiden.

> som en fördel för 32-bitarna är att man kan använda GNU:s toolchain,
Vilka "32-bitare" ?

ARM, MIPS, x86, osv.

> och man slipper alla knäppa IDE:er...
Självklart. Märkligt argument. Vem vill använda något "knäppt" ?

De som blir tvingade för att processor tillverkare X endast tillhandahåller en kompilator som måste köras på en viss hårdvara och ett visst operativsystem av en viss version. För att sedan EOL:a alltihop efter en tid.

[v-g]

blueint:Men vad spelar det för roll om något i utvecklingsväg blir EOL? Klart om processorn fortsätter utvecklas är det ju surt MEN gör den inte det så är det ju kvitt samma, bara att köra på med det man har.

Blir ett utvecklingsverktyg nedlagt så är det rätt troligt inte så populärt och även om det är surt för den enskilde så lär det ju inte vara en katastrof. Större (seriösa) företag har supportavtal osv så de kan inte bara lägga ner helt huxflux.

Hjälper ju inte mycket heller att ha sourcen till ett program om man inte har alla parametrar med vilket det är kompilerat samt hela miljön satt upp korrekt. Hände mig helt nyligt till dreamboxen och hjälpen man fick var ungefär som goddag yxskaft, så bra var det med open source för MIN del.

[blueint]

Det är inte så kul att kasta bort mängder med fungerande program och inte kunna uppgradera de processorer man har i drift. Och det finns mindre företag också som kanske inte sitter med lyxavtal.

[Micke_s]

Eller att företaget släpper en kompilator som kompilerar fel, kör man gcc så kan man i alla fall kolla hur koden för kompilatorn ser ut.

[Walle]

Jag drar ju direkt paralleller till kameror. Att säga att en 32-bitars µCU generellt är bättre än 8-bitars är typ som att säga att mellanformat generellt är bättre än småbild. Ja, bildkvaliteten blir generellt högre, OM fotografen vet vad den sysslar med. Det är inga problem att ta skitbilder med en mellanformatare. Likväl som det inte är några problem att skriva skitprogram till en 32-bitars µCU. Men att mellanformatskameror generellt är större och tyngre än småbildskameror är inte alltid en fördel. Man väljer det format som passar uppdraget bäst. Ibland kan det vara mellanformat, ibland småbild, ibland något annat format.

Vem drar skruv med skiftnyckel om man har fasta nycklar? Är skiftnyckel bättre än fasta nycklar bara för att man kan dra många olika storlekar med den?

Nej, som någon skrev innan, man väljer väl rätt µCU för uppgiften.

Edit: Jag började visst skriva på det här inlägget innan jag åkte hem från jobbet i fredags..så det hann komma ett par inlägg emellan

[Icecap]

blueint: "Det är inte så kul att kasta bort mängder med fungerande program"

Såklart inte, därför är det viktiga att all källkod dels är i ett standardspråk (t.ex. C) och dels att den är synnerligt bra kommenterat, speciellt i hårdvarudelarna.

Jag har gjort ett projekt där jag kunde använda två olika processorer (Fujitsu FFMC 16LX och Renesas M16C), källkoden var i stort den samma medan det fanns olika källkoder till hårdvaran. Alla uppdateringar i funktionerna fungerade alltså i båda kompilatorer när väl hårdvarudelarna fungerade och valet mellan processorna var enkelt: i den ena kompiler finns det en definition som anger vilken processortyp som används, denna används då till att välja mellan Fujitsu och Renesas' hårdvaradefinitioner.

Så ska man kasta bort ett fungerande program för att man måste byta processor har man gjort programmet fel från början.

[blueint]

Portabel kod är en sak, kod som fungerar rakt av en helt annan. Sådan anpassning går ju förlorad.

[sodjan]

> ...kör man gcc så kan man i alla fall kolla hur koden för kompilatorn ser ut.

"Kan" är inte detsamma som att det är vettigt, rimligt eller ens önskvärt.

Jag har så klart inte sett hur gcc koden ser ut "under the hood" men
jag misstänker att man bör vara rellativt beläst inom kompilatorteknik
för att hänga med i vad de gör. För de allra flesta är det där ett
argument helt utan värde, ändå är det ett av favoritargumenten
från open source förespåkarna. Märkligt...

[blueint]

Det kan vara så enkelt som att man byter plattform för att köra utvecklingsverktygen. Har man källkoden kan man i stort sett alltid flytta med dom utan problem.

[Icecap]

blueint:
För en hel del år sedan bytte jag ut en I80C320 (8 bit) mot en Fujitsu µC (16 bit). All källkod var i C och jag fick ju skriva om all hårdvaruhantering. Då hårdvara-koden var testade och fungerade körde all annan källkod direkt - i första försöket!

Därför skriver jag numera alla hårdvaru-specifika programdelar i specifika filer och resten av källkoden skriver jag i andra, då kan man ganska enkelt byta hårdvara utan problem.

[vespaman]

blueint:Men vad spelar det för roll om något i utvecklingsväg blir EOL? Klart om processorn fortsätter utvecklas är det ju surt MEN gör den inte det så är det ju kvitt samma, bara att köra på med det man har.

Blir ett utvecklingsverktyg nedlagt så är det rätt troligt inte så populärt och även om det är surt för den enskilde så lär det ju inte vara en katastrof. Större (seriösa) företag har supportavtal osv så de kan inte bara lägga ner helt huxflux.

Även om dom inte lägger ner, så kan dom "uppgradera/förbättra" (har hänt mig några gånger) till en version som inte är direkt kompatibel med ditt gamla projekt. Det blir liksom en kedja med misär - utvecklingsmiljön supportar inte windows X (X= ny version), lösningen blir att uppgradera utvecklingmiljön -> tid måste läggas på att få igång nya miljön, importera gamla projektet. Nu är i princip allt nytt, och man måste göra en fulltständig systemtest även om man bara ändrade en rad. Mycket dyrt och jäkligt tråkigt jobb (tycker iaf jag).

Hjälper ju inte mycket heller att ha sourcen till ett program om man inte har alla parametrar med vilket det är kompilerat samt hela miljön satt upp korrekt. Hände mig helt nyligt till dreamboxen och hjälpen man fick var ungefär som goddag yxskaft, så bra var det med open source för MIN del.

Nu har inte jag koll på dreambox, men det är väl en kommersiell produkt? Om så är fallet är den ju inte nödvändigtvis open source bara för att den i sig använder open source.

Sedan kan jag hålla med om att man kanske inte själv börjar avlusa GCC, men det behöver man nog knappast, med tanke på alla (många många många) användare och utvecklare. Oddsen är oerhört mycket större att ev. problem fixas snabbt i GCC (om man nu mot all förmodan får problem).

Och, som sagt, mycket lättare att byta processor plattform om man behöver.

Känns trivsamt och behagligt att köra GCC

[blueint]

Att utvecklingsverktyget ej fungerar på den nuvarande operativsystemsversionen eller dongeln utan uppdateringar. Men samma uppdatering gör också att fungerande källkod ej fungerar längre eller (avancerade) inställningar är en klassiker.

Lösningen: Backup på operativsystem, utvecklingsverktyg mm.