PIC emuleren op AVR

Dit is bijna onbegonnen werk, de architectuur is volledig anders. Bovendien zijn de pinouts (zelfs tussen verschillende modellen AVRs en PICs) volledig anders. Je moet dit dan allemaal gaan vertalen, waardoor je niets van prestaties overhoud.

Waarom zou je perse PIC code op een AVR willen draaien?

Waarom zou je dat willen? AVR heeft ook qua architectuur grote voordelen, dus als je die hardware gebruikt, waarom zou je dan op en brakke architectuur willen blijven prutsen?

Op 17 mei 2011 14:27:57 schreef EricP:
waarom zou je dan op en brakke architectuur willen blijven prutsen?

Nounou, brak, prutsen...de heilige oorlog is hier weer eens uitgebarsten. Ik dacht dat we dat punt hier toch intussen wel achter ons hadden gelaten.

Inderdaad een wat nutteloze en ongefundeerde opmerking die PIC-AVR fitties in de hand werkt.

Maargoed, je zit met AVR en PIC in dezelfde orde van snelheid, en aangezien emuleren impliciet snelheid inleveren betekent, ga je dus een hoop inleveren qua performance. Zomaar op gelijke snelheid alles draaien gaat nooit lukken, en juist de toepassingen waar je een PICje gebruikt zijn vaak tijd-kritisch.

In alle gevallen die ik kan bedenken kun je beter direct op AVR ontwikkelen. Ik zie geen enkele toepassing waarbij iemand dit zou willen. Een bestaande binary voor een PIC die je wilt gebruiken, die voer je gewoon ook op een PIC uit. Geen enkele reden om dat op een AVR te willen.

Daarbij wordt C-code voor een PIC18 of hoger ook zwaar geoptimaliseerd voor die architectuur (daar zitten speciale, voor C-compilers gunstige opcodes tussen). Ontzettend gecompliceerd om dat om te zetten naar AVR architectuur, en als het al lukt dan doe je alle optimalisatie volledig teniet met die conversieslag. En dan hebben we het nog niet eens over periferie die volledig afwijkt...

Kom nou toch jongens... Ga nou niet vertellen dat iets wat met bankswitching werkt nog van deze tijd is... Dat is brak. Achterhaald. Begraven.
'Modernere' hebben daar wellicht eens wat fatsoenlijks voor, maar als het iets 'nieuws' is, kun je het net zo goed gelijk op een AVR ontwikkelen.

Dan hebben we het maar niet als maffe quircks als harde 'open drain output' waar een pull-up aan moet hangen om het ding als output te gebruiken. Dat stel je in in de config. Dat is niet meer van deze tijd. Dat is brak. Achterhaald. Begraven.

En zo zijn er nog een berg. Feit blijft dat als je eenmaal AVR hardware hebt, dat er geen enkele reden is om aan een microchip architectuur vast te houden. Behalve de angst voor 'onbekend', 'ik ken dit kunstje en nu moet ik een datasheet gaan lezen'...

ik weet niet, ik heb hier totaal geen verstand van maar de verschillende typen pic en wat ze kunnen en wat waar in het geheugen van de pic moet staat toch in zo'n bestandje voor iedere pic apart??

als je dat voor de AVR kunt aanmaken zodat alles direct voor AVR wordt geschreven in PICbasic.... scheelt een hoop omwegen.

want uiteindelijk worden het allemaal of het nou pic of avr is 1nen en 0len

Als je met een PIC een slecht programma maakt ben je een brakke programmeur...
En een OD output is heel nuttig voor o.a. het One-wire protocol.
Het heeft ook weinig nut om een PIC op een AVR of vice-versa te emuleren.
Een soort translation tool zou wel nut hebben. (Die echt de code van de een omzet in code voor de ander)
Maar dat is een heel ander verhaal...

Op 17 mei 2011 15:20:58 schreef EricP:
Kom nou toch jongens... Ga nou niet vertellen dat iets wat met bankswitching werkt nog van deze tijd is... Dat is brak. Achterhaald. Begraven.

Ach, bankswitching. Dat is iets uit de 16F-serie, en dat is zo gebleven om de architectuur compatible te houden. Met die architectuur heb je met iets van 35 opcodes overigens wel een heerlijke omgeving om iets kleins in assembly te maken. Voor een AVR is dat veel lastiger om in thuis te raken.

De 18F heeft (bijna) geen bank-switching, en bovendien heb je daar met een fatsoenlijke compiler helemaal geen last (of weet) van. (Op een 16F in een hogere taal ook niet, maar die was niet geoptimaliseerd voor compilers.)

En zo zijn er nog een berg. Feit blijft dat als je eenmaal AVR hardware hebt, dat er geen enkele reden is om aan een microchip architectuur vast te houden. Behalve de angst voor 'onbekend', 'ik ken dit kunstje en nu moet ik een datasheet gaan lezen'...

Ik gebruik zowel PIC als AVR en elk heeft z'n sterke punten. PIC is in sleep wat zuiniger. AVR is met z'n I/O weer wat makkelijker, bijvoorbeeld met de aparte registers om het RMW-probleem te voorkomen (wat ook weer verwarrend kan zijn tijdens het programmeren). PIC is beschikbaar in kleinere packages. AVR heeft betere GCC ondersteuning (hoewel er voor PIC alternatieven zijn). PIC heeft een nauwkeurigere interne RC-oscillator. Zo zijn er nog tig verschillen, maar allemaal niet zo heel relevant en vaak een kwestie van wennen.

Voor een beginner zijn andere dingen belangrijk, bijvoorbeeld hoeveel programmeer-voorbeelden er zijn te vinden en of iemand in z'n omgeving één van beide reeds toepast. Hierdoor kun je wegwijs raken met zo'n ding.

Het is heel jammer dat jij van dit topic gelijk een flame-topic moet gaan maken met je opmerkingen, zeker omdat het vraagstuk dit keer niet eens was 'welke moet ik kiezen'. Helaas liet ik me toch verleiden tot een reactie, hoewel ik geen partij kies.

> Is er momenteel een bestaande oplossing om code die ontwikkeld is voor een PIC microcontroller ontwikkeld is, op een AVR uit te voeren?

niet dat ik weet, tenzij het source code is die op een chip-onafhankelijke manier is geschreven.

> Is er interesse om code voor PICs op een AVR uit te voeren. (Als in: zijn er mensen die liever voor een PIC architectuur programmeren, maar graag goedkopere AVR hardware willen gebruiken?)

lijkt me niet. het belangrijkste voordeel van (12 en 14 bit core) PICs is dat ze goed verkrijgbaar zijn, niet dat het een fantastische architcetuur is.

> 3. Is er veel verschil tussen verschillende PIC chips

ja

> Zoja, dan wil ik me er eens aan wagen om een emulator te schrijven, die een gecompileerde PIC binary als input neemt, deze wrapt in een soort van virtuele machine voor de AVR, en een AVR binary uitspuwt.

zinloos. nuttiger zou zijn een library/header file set te maken waarmee je C code kan schrijven die zowel op een PIC (HiTech C) als op een AVR (GCC ofzo) kan draaien. (en als je toch bezig bent, neem dan meteen 8051 mee). het probleem zit 'm dan voornamelijk in het aasnpreken van de peripherals.

als je dat voor de AVR kunt aanmaken zodat alles direct voor AVR wordt geschreven in PICbasic.... scheelt een hoop omwegen.

Waarom schrijf je dan je AVR programma ook niet meteen in "AVR" Basic (Bascom) ?

Ik denk dat een PIC-Basic programma omschrijven naar Bascom nog het makkelijkst is.

Is er momenteel een bestaande oplossing om code die ontwikkeld is voor een PIC microcontroller ontwikkeld is, op een AVR uit te voeren?

/Fittie... is dat niet zo iets als een Opel kadet body kit passend te krijgen op een Ferrari ?

Groeten, Bram

Interessant, zoveel reacties had ik niet verwacht. Het is niet de bedoeling om mensen met AVR hardware voor een PIC te laten programmeren, maar wel om bestaande software op een eenvoudige manier op een ander platform uit te kunnen voeren.
Maar als ik het goed begrijp worden er dus nooit (of zelden) programma's van duizenden regels code voor een PIC geschreven, om daarna te porten naar bijvoorbeeld een AVR. En als het nodig zou zijn, is het dus doenbaar dat handmatig te doen?

Ik heb zelf behoorlijk wat ervaring met het ontwikkelen van parsers en interpreters (en in mindere mate ook met compilers), en was op zoek naar een boeiend hobbyprojectje.

Vandaag was op Slashdot iemand die een volledige Linux kernel in Javascript kon uitvoeren, en dat heeft me zin gegeven om een nieuwe virtual machine te maken. Daarbij zijn AVRs en PICs van architectuur toch simpeler dan een x86, en het is altijd boeiend om iets nieuws te leren.
http://bellard.org/jslinux/

Tegenwoordig wordt trouwens meer en meer virtualisatie toegepast, en dat kan bijna zonder performantieverlies. De meeste microcontrollers bevatten nog niet de hardware-extensies om virtualisatie (of zelfs kernel/user-mode) toe te laten en lopen dus nog wel iets achter, maar ik denk dat het emuleren van eender welk platform toch moet lukken met een factor van 5 a 10 keer de originele snelheid.

Het is zeker niet zo dat iedereen alle klokcycles echt nodig heeft, dus een virtuele machine, garbage collector etc... lijkt me allemaal mogelijk. Software wordt meer en meer op een hoger niveau van abstractie geprogrammeerd ( assembly -> C -> java/c# -> python/ruby/javascript -> ...), en dat zal ook zo zijn met microcontrollers. Hardwarecost is vaak verwaarloosbaar ten opzichte van ontwikkeltijd voor software.

Dus nu ben ik enkel op zoek naar een boeiend projectje, en 't zou leuk zijn moest het ook nog nuttig zijn.

- AVR emulator voor in de browser
- Javascript interpreter voor op een AVR (dus programmeer je avr in JS in plaats van in C)
- ...

Alle ideeen welkom.

Javascript interpreter voor op een AVR

En dat allemaal in een AVRTINY2313 ?

Wat is de toegevoegde waarde van ? Als je een AVR (of PIC) niet de gebruikelijke talen kunt programmeren (Assembler, C of Bascom/Picbasic) moet je dr niet aan beginnen.

Software wordt meer en meer op een hoger niveau van abstractie geprogrammeerd

Dat wil je niet, ik wil bitjes kunnen flippen, en mn interrupts zelf in de hand hebben.

Tegenwoordig wordt trouwens meer en meer virtualisatie toegepast

Maar daar heeft t ook nut... als je effectief maar 20% van de machine capaciteit gebruikt kun je er best een paar virtuele op draaien, al was het maar om op hardware/stroom/koeling te besparen. Een $0.40 kostende processor emuleren op een PC van een paar honderd euro gaat me even mn pet te boven. Bovendien... emuleren... dat kan in de bestaande tooling toch al ?

Groeten, Bram

[Bericht gewijzigd door bprosman op dinsdag 17 mei 2011 16:42:06 (32%)]

Op 17 mei 2011 16:35:11 schreef bprosman:
[...]
En dat allemaal in een AVRTINY2313 ?

Wat is de toegevoegde waarde van ? Als je een AVR (of PIC) niet de gebruikelijke talen kunt programmeren (Assembler, C of Bascom/Picbasic) moet je dr niet aan beginnen.

Vind je dat?

Wat denk je van Arduino? Veel mensen stellen hun interrupt handlers niet meer met de hand in.

C is uitgevonden omdat assembly niet volstond en mensen functies wilde gebruiken. Java/c#/... is toen uitgevoenden omdat mensen niet zelf meer hun geheugen allocatie wilde doen. scheme/haskell/... is uitgevonden omdat programmeurs functies on the fly wilde kunnen creeren (lambda expressies)

Als je één keer lambda's begrijpt, en alle functionele structuren hebt ontdenkt, wil je niet meer terug low level, tenzij je echt maximale performance nodig hebt.

Ervaren programmeurs maken wel vaken een eigen definitie van een programmeertaal, die beter is om hun doel te bereiken, waarop ze vervolgens een kleine interpreter schrijven die dat taaltje begrijpt.

Waarom niet op een AVR?

-edit----

Bijvoorbeeld: met arduino doe je zo:

void setup() {
attachInterrupt(0, blink, CHANGE);
}
void blink() {
digitalWrite(pin, state);
}

waarbij blink een function is die ergens anders gedefinieerd staat.
Dat werkt natuurlijk, maar dat is niet altijd even overzichtelijk. Je wilt op exact die plaats je functie definieren, of dynamisch een nieuwe functie aanmaken. In vb. Javascript kun je het zo schrijven:

void setup() {
input(0).change(function() {
digitalWrite(pin, state);
});
}

Duidelijk en kort. Doe een digitalWrite, als er een change is aan input0. Zelfs geen assignments, dus geen side effects.

Ik hoop dat dit mijn punt een beetje verduidelijkt. Ik begrijp goed dat assembly goed genoeg is om een ledje te laten knipperen, of net iets meer. Maar als het echt complex wordt, kun je moeilijk nog assembly of basic gebruiken, tenzij je constant in je hoofd, je algoritmes gaat compileren...

[Bericht gewijzigd door jonathan_s op dinsdag 17 mei 2011 17:28:33 (30%)]

Lol, lambda's gebruiken op een microcontroller met 8k flash rom en 128 bytes geheugen.

Voor hele grote microcontrollers kan ik me er iets bij voorstellen, maar daar kun je ook linux op laten draaien.

Er zijn platformpjes waar je het compact .NET framework op kunt draaien, dan kun je ontwikkelen met bijvoorbeeld C#.

Als je nu eens een compact .NET framework weet te maken voor PIC / AVR / etc dan heb je mijn aandacht!

Op 17 mei 2011 15:20:58 schreef EricP:
Ga nou niet vertellen dat iets wat met bankswitching werkt nog van deze tijd is...

Dan hebben we het maar niet als maffe quircks als harde 'open drain output' waar een pull-up aan moet hangen om het ding als output te gebruiken.

bankswitching is fantastisch ! toch als het om registerbanken gaat.
niks beter om multitaskers te maken. ( of heb je het over code banking ? dat is inderdaad flauwe kul )

en open drains zijn soms noodzakelijk. ( zonder interne pull up ! )
denk maar aan i2c bus..

Op 17 mei 2011 16:27:42 schreef jonathan_s:
Interessant, zoveel reacties had ik niet verwacht. Het is niet de bedoeling om mensen met AVR hardware voor een PIC te laten programmeren, maar wel om bestaande software op een eenvoudige manier op een ander platform uit te kunnen voeren.[/quote]
dat heet Java...

Maar als ik het goed begrijp worden er dus nooit (of zelden) programma's van duizenden regels code voor een xxx geschreven, om daarna te porten naar bijvoorbeeld een yyy.

dat gaat niet alleen al door de peripherie die noodzakelijk is. als xxx hardware pwm generatoren heeft en yyy niet dan heb je al een probleem : je code is onporteerbaar. ( zeker op binair niveau )
en je gaat geen xxx vinden die exact dezelfde peripherie heeft als een yyy.

je kan high level routines in source porteren maar je BSP is anders.
deftig embedded werk splitst de code in een 'application' en een 'bsp' ( board support package). de bsp is eigenlijk een HAL die gestript en geoptimaliseerd wordt voor de aanwezige en te gebruiken hardware ( peripherals die niet gebruikt wordenzijn gestript in een bsp ) de application doet calls tegen de bsp. zo kunnen de 'softies' zich concentreren op algoritmes en hoeven ze niks of slechts weinig te weten van de hardware.
code wordt porteerbaar omdat je in het slechtste geval in de bsp een emulatie gaat doen.

maar vergeet de fantasie van xxx op yyy te lopen. dat lukt gewoonweg niet.

(1) De meeste microcontrollers bevatten nog niet de hardware-extensies om virtualisatie

-snip-

(2) emuleren van eender welk platform toch moet lukken met een factor van 5 a 10 keer de originele snelheid.

-snip-

(3) Het is zeker niet zo dat iedereen alle klokcycles echt nodig heeft,

-snip-

(4) dus een virtuele machine, garbage collector etc... lijkt me allemaal mogelijk.

(5) Software wordt meer en meer op een hoger niveau van abstractie geprogrammeerd ( assembly -> C -> java/c# -> python/ruby/javascript -> ...), en dat zal ook zo zijn met microcontrollers.

-snip-

(6) Hardwarecost is vaak verwaarloosbaar ten opzichte van ontwikkeltijd voor software.

bwaaahahahaaaa. lang geleden dat ik nog zo goed gelachen heb. Ge lekker verder spelen met le loonix toestanden en laat embedded software over aan de grote jongens. Je toont met je bovenstaande opmerking aan dat je er GEEN BAL van snapt.

sta me toe je een aantal dingen te verduidelijken ...

1) vertualiseren met 4k rom en 64 bytes ram ga je niet te veel moeten virtualiseren...

2) nooit sneller : TRAGER ! sommige dingen ga je in runtime moeten emulreren en dat kost kostbare tijd.

3) in embedded systemen wel. je optimaliseert je clockspeed voor verbruik. veel embedded systemen zijn time-determinisitsch (robotica bijvoorbeeld) als je dat gaat emuleren schop je de timing in de war met vaak catastrofale gevolgen... de code is zo dicht geweven op de aanwexige hardware ( die hardware wordt geselecteerd voor de uit te voeren job ) dat dat niet porteerbaar is zonder in te boeten aan performantie of functionaliteit . een knipperledje porteren : no problem. een speed controller voor een 3 fase motor met hall effect feedback .... dat is een ander paar mouwen ....

een zelfbalancerend karretje wordt al een echte ramp...

4) zie 1 ...

5) riiiiight.... zie punt 1 ...

Wat denk je van Arduino? Veel mensen stellen hun interrupt handlers niet meer met de hand in.

Arduino's zijn ook uitgevonden voor mensen die de structuur van een microcontroller niet (willen) doorgronden.

Veel mensen stellen hun interrupt handlers niet meer met de hand in

Dat zijn ook vaak de mensen die je hier op het forum ziet met vragen waarom de timing van hun programma niet (meer) klopt of hun processor op de meest rare momenten vastloopt of reset.

Groeten, Bram

Op 17 mei 2011 17:52:03 schreef free_electron:
[...]

bankswitching is fantastisch ! toch als het om registerbanken gaat.
niks beter om multitaskers te maken.

Helemaal meet eens. Ah-la 8051... (en niet alleen voor multi-taskers, maar ook voor snelle ISRs zonder stack geneuzel)

( of heb je het over code banking ? dat is inderdaad flauwe kul )

Nou... Gewone registers die in banks zitten. Omdat de I/O space op was... Nog wat triester dan dan code banking dus...

en open drains zijn soms noodzakelijk. ( zonder interne pull up ! )
denk maar aan i2c bus..

Dan zet je die uit... Onzin om dat op 1 pin hard in hardware te hebben zitten en dan extern een pull-up er aan te gaan knopen als je dat als output wilt gebruiken. Overigens is voor I²C die interne pull-up (als die er al zou zijn) ook niet zo erg. Rekening mee houden voor je externe pull-up...

Overigens... Als je met java wilt rommelen... Had Maxim daar niet een 8051-kloon van waar dat op draaide... Ben de naam even kwijt. Ding met een shitload aan hardware interfaces... DS80C400 serie ofzo?

Op 17 mei 2011 16:27:42 schreef jonathan_s:
Dus nu ben ik enkel op zoek naar een boeiend projectje, en 't zou leuk zijn moest het ook nog nuttig zijn.

- schrijf een HAL (in C) met een universele interface voor diverse PICs en AVRs
- doe iets aan de GCC compiler voor AVR, of de Jal compiler voor PICs
- voor de echte nerd: bedenk zelf een microprocessor en implementeer die met alleen 555 chips, bonus als de ROM en RAM ook alleen uit 555's bestaan, extra bonus als het lukt met maar 555 van die chips (weerstanden en condensatoren zijn toegestaan)

Er zijn momenten dat ik software die voor de AVR is geschreven zou willen omzetten voor de PIC. En ik kan me zo voorstellen dat dat andersom ook het geval is.
Maar dat zou ik nooit doen door emuleren, want...afijn, de argumenten zijn al langs gekomen.

Persoonlijk zou ik het prettig vinden als bouwers hun code eens wat beter zouden documenteren.
Eerst een functionele omschrijving, vervolgens een uitleg van de software met betekenisvolle naamgeving van routines en variabelen.
"Hogere" generatie talen (dan assembler) hebben allen ten doel gehad de ontwikkeltijd te verkorten, het onderhoud eenvoudiger/sneller te maken en de porteerbaarheid/portabiliteit te vergroten. Denk aan talen als C, Cobol, Pascal en Java.
Dat dit ten koste gaat van performance is vaak minder belangrijk. (Hoewel hetzelfde programma gebouwd in verschillende talen drastische verschillen kan opleveren door de kwaliteit van de optimalisering door de compiler. De PL/1 compiler op het IBM mainframe levert aanzienlijk snellere code dan de Cobol compiler.) Ik heb het dan vooral over administratieve software.

Maar voor de embedded wereld (als ik het even zo mag samenvatten) gelden andere regels en, vooral, andere eisen aan de applicatie.
Virtualisatie lijkt mij een onzinnig pad, juist dit type hardware wordt om bepaalde redenen gekozen.
Het is van geen kant vergelijkbaar met virtualisatie zoals die in grote rekencentra wordt toegepast.

Oftewel, wat wil je nou bereiken. Zorgen dat programmatuur eenvoudig zou kunnen worden overgezet? Dan is documentatie de aangewezen weg.

@Wouter: met 556 stuks 556 heb je met 1 chippie meer wel de dubbele capaciteit!

Op 17 mei 2011 18:54:19 schreef hadv:
met 556 stuks 556

zet er dan meteen 558 558's in he! altijd dat halve werk ... (rolt met ogen)

Op 17 mei 2011 16:27:42 schreef jonathan_s:
Het is niet de bedoeling om mensen met AVR hardware voor een PIC te laten programmeren, maar wel om bestaande software op een eenvoudige manier op een ander platform uit te kunnen voeren.

Oshonsoft? Daarmee kan je zowel PIC's als AVS's programmeren, en volgens mij gebruiken beide IDE's dezelfde basic taal.

Je komt echter wel de knoei met wat hardware verschillen. Lees dit voor de gein eens door.

Lees dit voor de gein eens door.

Voor de gein inderdaad, laat het daar ook maar bij. Die lijst is zo ontzettend discutabel en tevens verouderd.

Wat betreft de vraag van de topic starter. De meeste mensen hier zijn terecht of onterecht negatief over je vraag/voorstel. Echter zou ik me niet direct uit de weg laten slaan. Hoewel het misschien niet direct zin heeft, kan een het zeer leerzaam project zijn.

Op 17 mei 2011 20:17:06 schreef naffets:
Voor de gein inderdaad, laat het daar ook maar bij. Die lijst is zo ontzettend discutabel en tevens verouderd.

Ik zie dat je mij een paar verbetertips gaat sturen, je weet m'n mail.