USART, AVR och Mega88

[sodjan]

Hm, jo, men bara för att det ska vara tydligt...

Detta är *inte* ett "USART problem" som den där AVR-freaks tråden handlar om.

Det är naturligtsvis inget specifikt för just USART'en, utan gäller denna
grupp av instruktioner generellt. Jag kan tycka att det är en lite märklig
arkitektur där vissa instruktioner bara fungerar mot en delmängd
av kontrollregistren. Lösningen i tråden på AVR freaks med ett macro
fungerar ju i och för sig...

Slutligen kan jag tycka att det är lite trist att man inte kan kolla upp
ett felmeddelande i dokumentationen utan måste kasta sig över
tengentbordet och hysta in en fråga på ett forum så snart minsta
lilla problem uppstår. Det är lite jobbigt att ämnen markeras som
"oläst" bara för en såden skitgrej... Dessutom två gånger för exakt
samma fel inom ett par minuter...

*Lite* slarvigt och slappt, if you ask me.

[Swech]

Man kan väl säga att AVR Mega har "växt ur" sig själv
det finns så många register så att de helt enkelt inte får plats
att mappas av OUT. Detta "problem" finns inte på de
mindre modellerna.
Men så länge man vet om det och assemblern talara om vad som
är fel så är det enkelt lösbart

Swech

[AAVE]

Märklig?? Betänk att du kan porta kod från Atmels minsting (ATiny11) till deras största kretsar (ATMega256?) bara man följer deras kodningstandard:

AVR001: Conditional Assembly and portability macros
www.atmel.com/dyn/resources/prod_documents/doc2550.pdf

[sodjan]

Nej, det är igentligen inte märkligt.
Många arkitekturer får liknande egenheter när de växer ur
den ursprungliga arkitekturen. Samma sak för PIC och 8088 o.s.v.

Och PDF'en har naturligtsvis rätt macros för att komma runt det.

[AAVE]

Är det verkligen rättvist att jämföra AVR med PIC här? Portar du kod från PIC10 till PIC18F får du mer eller mindre skriva om hela projektet.

Atmel däremot har gjort sitt bästa för att göra portning så smärtfritt så möjligt (förutsatt att man följer deras rekommendationer). Jag tycker du ska ge Atmel lite mer cred...

[sodjan]

Jag sa ju att det inte är så märkligt att man får
vissa problem när en arkitektur växer, det är likadant
med många arkitekturer som har en historia att ta hänsyn till.
Atmel har löst det med ett par macron, men det kräver att
användarna använder dom också...

Sen finns det ingen som portar kod mellan PIC10 och
PIC18. De spelar i helt olika divisioner och har helt olika
applikationsområden.

[AAVE]

Hos Atmel har arkitektureren varit mer eller mindre oförändrat genom åren. Det som kan ändras är IO-minnet, vilket inte är så konstigt eftersom olika kretsar har olika kringkomponenter med tillhörande IO-map. Så Atmels arkitektur har inte "växt". kanske mest för att den var så väl designat från början.

Sen finns det ingen som portar kod mellan PIC10 och
PIC18. De spelar i helt olika divisioner och har helt olika
applikationsområden.

Vad sägs om att porta kod från PIC16 till PIC16F1? vem har växtverk nu då?

edit: ändrade PIC161F till PIC16F1

[sodjan]

Jag känner inte till PIC161F så jag kan inte säga något om det.

[vfr]

AAVE> Varför argumenterar du emot Sodjan? Han håller ju till största delen med dig! Är det argumentet med 10x versus 16x du hänger upp dig på så är det väl onödigt. Precis som Sodjan säger så är det vitt skilda produkter, och ändå är dom till största delen lika.

Vad är PIC161F? Har jag aldrig hört talas om.

[AAVE]

Sodjan tar upp en av PICens största nackdelar och får det att låta som om AVR:en har samma problem. Ville bara påpeka detta...

Man kan väl säga att AVR Mega har "växt ur" sig själv det finns så många register så att de helt enkelt inte får plats att mappas av OUT.

Poängen med 10x vs 16x är att portningen blir mycket svår just eftersom arkitekturen har ändrats så mycket. Jobbar man med AVR däremot kan man flytta kod mellan ATTiny11 och ATTmega256 rätt så smärtfritt bara man följer Atmels riktlinjer.


Annars är vi överens :)

nu drar jag till stan, ha en trevlig helg!

[sodjan]

Båda har liknande "problem" och det finns liknande lösningar
till båda (macron och assembler direktiv). Problemet på båda
är att få nybörjare att använda dom...

Problemet med portning mellan PIC10 och PIC16 har inte så mycket
med arkitekturen att göra, som att de har så olika användsområden.
Och *så* stora skillnader är det inte.

Men å andra sidan så är det inte mer problem än från en annan
"base line" modell till en annan "midrange" modell.

Slutligen, det jag initialt pekade på är att man på AVR måste se upp med
vilka instruktioner man använder till vilka register, eftersom alla
instruktioner inte fungerar "överallt". Det har ingenting med portning
av kod mellan olika modeller att göra, det är en helt annan fråga...

[Swech]

AVR - PIC
Alltid känsligt, alla har vi våran favorit.
Vilken sida jag personligen står på bör väl vara känt vid det här laget.

Värt att notera är att atmels nya XMEGA har precis samma struktur
och samma kommando som hela linjen från MEGA till de allra minsta Tiny kretsarna.

Hursomhelst det går att skriva riktigt bra program till både PIC och AVR
- och naturligtvis riktigt dåliga också


Swech

[AAVE]

Grejen är att jag håller på att porta ett PIC12 program till PIC16, och ett ATTiny2313 till ATTmega88 (samma projekt som PICen, bara olika varianter av hårdvaran). Trots alla dessa "problem" sodjan verkar se överallt gick AVR portningen på några minuter. PICen däremot...

Jag tycker Swech sammanfattade det hela rätt bra...

----------

På tal om PIC, är någon intresserad av en PIC10 klon i FPGA?

[sodjan]

Det beror mycket på om det det är en "base line" (lite mer jobb) eller
en "midrange" (betydligt enklare) PIC12...