ervaringen met de NIOSsoft core voor FPGA

Bij de NIOS moeten er wellicht nog een MMU, stack en interruptcontroller worden geinitialiseerd. Met objdump kun je de elf file bekijken om te zien wat er allemaal zit en eventueel disassembleren. Er wordt waarschijnlijk een startup.s meegecompileerd. De compiler opties -Os of -O2 geven doorgaans de compactste code. -O3 de snelste.

bovenstaand programma gebruikt geen stack ( der word niks aangeroepen), geen MMU (zou niet mogen. ding heeft welgeteld 1 byte ram nodig en dat prop je in een intern register ) en gene interrupt. 6.4k is compleet abnormaal. ( zelfs als het ding bepaalde zaken moet intialiseren is dat nog abnormaal )

enfin, ik zal eens kijken in die startup...

Ik heb de indruk dat die nios gemaakt is om daar ene beetje GCC code op te draaien maar om er echt een snel realtime systeem mee te maken.... das een ander paar mouwen. een ARM is ook soms ( ik zeg wel soms. de ene is al beter dan de andere ) zo een misbaksel voor dergelijke dingen. Sommige zijn snel maar de meesten hebben ook teveel clockticks nodig. Als hij midden in een instructie zit kan hij niet aborteren.

een interrupthandler is nochthans simpel. push de program counter,push de accumulator en het B register, push het context register en laad de program counter met het address en vort met de geit.

de interrupt handler die ik schrijf gebruikt hardcoded adressen ( herinner je de vorig vragen nog die ik gepost heb ? ) de interrupt handler gebruikt geen enkel register buiten de accumulator , de carry bit en het B register.. roept niks ( geen andere call-return constructies ) , pakt niks binnen en levert niks af. het gaat de data halen vanaf vaste adressen en zet ze ook terug op vaste adressen. die adressen liggen volledig buiten het normale programma. de reden dat ik die vorige vragen stelde is precies om van dergelijke rotzooi vanaf te zijn.

tis klein en razendsnel. ik heb het al honderden keren gedaan op allerhande processortjes. 6802 6809 68k 8051 8096 i960 en nog een nest anderen.

enfin. ik zit weer op mijne preekstoel. maar het is toch frappant dat we nu verzand zijn in een 'object oriented' abstracte wereld waar ze potdorie niet meer weten hoe ze een snelle interrupt afhandeling kunnen doen.

['opa' mode] ik heb terug heimwee naar de goeie oude tijd toen ik met losse diodekes een rom moest in elkaar solderen. dat was nog eens programmeren. al dat newfangled overloaden en subclassen...
ze hebben tegenwoordig 500 kilobyte code en 2 miljoen gates nodig om een ledje te laten branden...

in mijne tijd moesten we twee uur te voet door de kou en sneeuw voor we aan het internet waren. en nu.. ze klikken en de multimedia web 2.0 applicatie vliegt ze rond de oren.

wij waren al content als we over een 75 baud lijn met ascii karakters een manneke op het schemr konden zetten

   O
  /|\
   |
 _/ \_

[/'opa' mode]

stel u voor dat dat in een pacemaker zit ... geclockt aan ene paar kilohertz... de patient is al 2 minuten klinisch dood tegen dat de processor begint aan de interrupt routine ...

<opa mode>
Dan pakt men de hoogspanning van den buizenradio en plaatst deze kortstondig op en linker zijde en rechterborst kas.
</opa mode>

kan me de frustratie van Free wel voorstellen. Een van mijn docenten digitale techniek op de MTS of HTS riep altijd al dat de beste programeertaal een soldeerbout was

Wel free_electron. Assembler rules .

Ik ben ook allang niet meer mee met die abstrakter wordende programmeertalen. Dit is geen elektronica meer maar informatica. Ik ben het volledig met je eens.

Geef mij maar ook terug die bytes en bits die je zelf moet shiften, moven, adden, anden, orren, xorren, setten, clearen en ga zo maar door. Zo maak je uiteraard de allersnelste programma's.

Wat ik van die grote code footprint denk:

Welke libs heb je geincluded? Want de compiler compiled ook de HAL en alles wat geincluded wordt, en linkt dat mee. Die code komt ook mee in de code memory volgens mij. Eventueel de HAL afzetten (als dat kan?)

Nu is dat wat ik juist schreef eigenlijk een aanname. Ik weet niet exact wat de gcc doet met de geincludeerde libraries. Komt al de code van de libs in het memory, ook al roep je die niet aan?

Die NIOS is echt wel een leuk ding om op te werken, samen met het hele SOPC gebeuren. Maar ik heb ook gemerkt dat je voor realtime systemen de NIOS niet echt kunt gebruiken (ik doe de snelle data xfer met een DMA nu, anders kan ik nooit snel genoeg de data transfereren en mis ik waardevolle samples, wat natuurlijk uit den boze is bij systemen die de data kunnen analyseren tot op de sample nauwkeurig)

[Bericht gewijzigd door stecj366 op zaterdag 13 oktober 2007 09:19:53 (31%)]

Op 12 oktober 2007 23:33:37 schreef free_electron:
bovenstaand programma gebruikt geen stack ( der word niks aangeroepen), geen MMU (zou niet mogen. ding heeft welgeteld 1 byte ram nodig en dat prop je in een intern register ) en gene interrupt. 6.4k is compleet abnormaal. ( zelfs als het ding bepaalde zaken moet intialiseren is dat nog abnormaal )

enfin, ik zal eens kijken in die startup...

Ik heb de indruk dat die nios gemaakt is om daar ene beetje GCC code op te draaien maar om er echt een snel realtime systeem mee te maken.... das een ander paar mouwen. een ARM is ook soms ( ik zeg wel soms. de ene is al beter dan de andere ) zo een misbaksel voor dergelijke dingen. Sommige zijn snel maar de meesten hebben ook teveel clockticks nodig. Als hij midden in een instructie zit kan hij niet aborteren.

Iedere processor maakt de huidige instructie af voordat er naar een interrupt wordt gesprongen.

Bovendien ben ik nog wat vergeten: De GCC tools staan standaard in de mode dat er ook een C library wordt meegelinkt en je een executable krijgt die onder Linux bruikbaar is. De C library heeft ook globale variabelen die moeten worden geinitialiseerd. Als je aan de linker (ld) meegeeft dat de standaard libraries niet moeten worden meegelinkt (ik dacht -nostdlib -nostartup, maar dat zou je even in de handleiding moeten opzoeken), dan zou je de kale code moeten krijgen.

Nou heb ik van NIOS geen kaas gegeten. Maar als wat je maakt 'slechts' lowlevel assembly zou moeten zijn, waarom dan niet een AVR/PIC core pakken? (als die er zijn, of anders wat je gewend ben een 8051 core).

Het ziet er naar uit dat wat je wil doen prima in assembler is op te lossen.

Hogere talen zijn eerder bedoeld voor het makkelijk hanteerbaar maken van complexere,niet-timings critical applicaties. Zoals gebruiker interfaces e.d.

Zelfs op de PC worden tijd-critische dingen nog in assembler gedaan, met name high-performance grafische drivers.

Is er een bepaalde 'eis' dat je een NIOS moet gebruiken?

Nios integreerd mooi in de altera development suite (off course, het is door hen ontwikkeld). In de SOPC builder kan je mooi heel je systeem (pu + randapps) opbouwen. Het zou ook kunnen met een AVR/PIC/... whatever core, maar die zou dan in SOPC moeten kunnen integreren, wat weer extra werk is. Als je een SOPC ready core hebt maak je het jezelf enkel gemakkelijk...

En ja, je zou kunnen opteren voor assembler, maar jah, we zijn de 21e eeuw eh

[Bericht gewijzigd door stecj366 op zaterdag 13 oktober 2007 11:38:54 (10%)]

Natuurlijk 21'e eeuw. Daarom maak ik de software op mijn werk ook met MS Visual Studio 2005 en niet met de macro assembler.

Wat free lijkt te willen is op assembler nivo, zonder dynamische poespas, zonder memory management, al die foefjes die bij een basic C setup aanwezig zijn. Het lijkt er op dat wat 'ie wil het makkelijkste/beste met assembler geklaart kan worden, maar daar'n tegen weet ik verder niet precies wat 'ie nu wil. Een motorcontroller die torque/fixed speed reguleert. Het zou te complex kunnen zijn voor assembler, ik ken zijn algoritme verder niet.

Ik heb het idee dat het gebruik van een softcore hier verkeerd is. Een softcore is bedoeld voor het control-path binnen een FPGA, niet het datapath! Tijdkritische dingen los je gewoon op met dedicated hardware (waarom kies je anders voor een FPGA?).

Op 13 oktober 2007 11:24:28 schreef MagicBox:
Hogere talen zijn eerder bedoeld voor het makkelijk hanteerbaar maken van complexere,niet-timings critical applicaties. Zoals gebruiker interfaces e.d.

Nah. Ik kan me prima voorstellen dat je sommige dingen liever in een hogere taal doet. Soms wil je gewoon iets als 'if a*3.25+b<5*c { blurb}'. Om dat soort berekeningen in assembler uit te moeten voeren...

Op 13 oktober 2007 12:33:59 schreef KillerB the Supreme:
Ik heb het idee dat het gebruik van een softcore hier verkeerd is. Een softcore is bedoeld voor het control-path binnen een FPGA, niet het datapath! Tijdkritische dingen los je gewoon op met dedicated hardware (waarom kies je anders voor een FPGA?).

De applicatie die free wil maken is een motorcontroller voor harddisks wat ik uit zijn andere topic begreep.

Dus hij zit wel in het controller domain. Alleen is een NIOS daar weer overkil voor (ik stel me dat als een 80386 of hoger equivalent voor). Als het niet in een FPGA moest, zou een PIC/AVR microcontroller voor alleen die functie uitermate geschikt zijn.

Op 13 oktober 2007 12:33:59 schreef KillerB the Supreme:
Ik heb het idee dat het gebruik van een softcore hier verkeerd is. Een softcore is bedoeld voor het control-path binnen een FPGA, niet het datapath! Tijdkritische dingen los je gewoon op met dedicated hardware (waarom kies je anders voor een FPGA?).

De nios wordt momenteel gebruikt om de routines te simuleren en uit te werken. Kleine veranderingen zijn nu eenmaal sneller door te voeren op software niveau dan op HW niveau (enkel de compile time al...)

Uiteindelijk zal het wel in hardware worden uitgevoerd. Simulaties van de dedicated hardware blijkt heel moeilijk te zijn omdat er geen model van de hdd motor op te stellen is. Dus je hebt geen input data voor het HW systeem...

En dat van de assembler, was maar om te lachen hoor... Ik gebruik ook wel eens asm voor echt time critical stuff (maar enkel als het ECHT niet anders kan, en dat heb ik nog niet vaak megemaakt)

Op 13 oktober 2007 12:56:47 schreef MagicBox:
De applicatie die free wil maken is een motorcontroller voor harddisks wat ik uit zijn andere topic begreep.

Hmm, lijkt me niet zo waarschijnlijk. Misschien voor een testsysteem, maar in een HDD zelf ga je geen FPGA gebruiken. Veel te duur. Daar gaan ASICs in. Maar goed, misschien zit ie nog in het proto stadium. Help us out FE!

Lees dit topic eens:
http://www.circuitsonline.net/forum/view/53481

Op 13 oktober 2007 11:05:13 schreef Nico.c:
[...]
Iedere processor maakt de huidige instructie af voordat er naar een interrupt wordt gesprongen.

Bovendien ben ik nog wat vergeten: De GCC tools staan standaard in de mode dat er ook een C library wordt meegelinkt en je een executable krijgt die onder Linux bruikbaar is. De C library heeft ook globale variabelen die moeten worden geinitialiseerd. Als je aan de linker (ld) meegeeft dat de standaard libraries niet moeten worden meegelinkt (ik dacht -nostdlib -nostartup, maar dat zou je even in de handleiding moeten opzoeken), dan zou je de kale code moeten krijgen.

aha. ik ga dat eens onderzoeken. bedankt.
klopt elke rocessor maakt hidigeinstructie af , maar het ziet ernaar uit dat zommige processoren veel 'mcrocode hebben' een arm heeft soms nog 6 of 8 clockticks nodig om de lopende instructie af te werken ( zekere als ie cache gebruikt )

8051 heeft dat niet. 2 of 3 clockticks later zit hij al in de int vector.
enfin das een ander verhaal

ik ga die GCC eens uitvlooien. ik vind het wel straf dat , zelfs al gebruik je niks van die library's , dat die toch geladen worden... van bloatware gesproken. een deftige compiler moet dat per default verwijderen.

@ magicbox en anderen.

de reden voor de nios is de volgende.
sommige systemen zijn nog niet uitgewerkt in hardware.
ik wil de jios gebruiken als 'emulator' voor hardare.

het probleem is het volgende de mensen die de stuuralgoritmes maken kennen enkel 'c' en niks van FPGA.

wat ik doe is een soort procesor maken die toegang heeft tot alle registers in de motorcontroller.
de morotcontroller gebruikt een SPI achtige bus op zeer hoge clock ( 100 MHz clk ) en schuift simultaan data in en uit.
daarvoor heb ik een statemachiene gemaakt.
gans dat blok ziet eruitals een stuk ram.

in de asic zitten er een 4 tal registers ( elk 16 bit ) sommige zijn write only , sommige read /write en sommige is de read data anders dan de write data. ( write is gain setting voor de ADC , read is de ADC waarde.. )

er zitten meerdere 'velden' in elk 16 bit woord.
bijvoorbeeld

ADC_control
D15 Gain 4
D14 Gain 3
D13 Gain 2
D12 Gain 1
D11 Gain 0
D10 Filter 1
D9 Filter 0
D8 P_Control 3
D7 P_control 2
D6 P_control 1
D5 P_control 0
D4 Force_Sample
D3 Auto_sample
D2 Synced
D1 --
D0 Disable

gans die registermap is een tabel. ik heb een programa gemaakt ( in visual basic) wat die ' memory layout tabel' in leest en daar verilog code van maakt om al die parameters te kunnen lezen en schrijven.

er komt
- verilog uit die direct synthetiseerbaar is
- c code die al de symbolische namen bevat gemapt op een address ( via die defines of _at_ )
- vb code met een enumerated list met de addressen van a die parameters.

ik ka dus vanuit C of CB gewoon schrijven Gain = &h12 of
Disable =1.

dat landt netjes op het juiste address in die ge-emleerde ram , de verilog code pakt direct alle data die nodig is om het ganse register te assembleren ( die zit immers ook al in de ram en de bitstream vertrekt. )

ik kan dus botweg schrijven : if ADC_read > 127 then Gain = Gain -1.
de hardware doet de rest.

dus voor algoritme ontwikkeling is dat een droom. je moet met niks geen rekening meer houden.

om ons algoritme mensen te plezieren is het idee om dus een processor in de fpga te duwen.

zij kunne in C hun algoritme ontikkelen : de processor loopt dat ding en voert het uit. i kheb de bottleneck die bitbanging zou vormen al verwijderd door alle modules die teveel tijd vragen op een CPU al in hardware te bouwen.

schrif programmatje : compileer : laad de rom file en runnen maar

eenmaal de boel correct werkt laten we de C code vertalen naar verilog en we zijn weg.

het punt is dat we willen vermijden dat iederen met fpga moet leren werken , leren synthetiserern etcetera etcetera.

er gaan een 40 tal mensen met dat platform aan de slag.
gans dat platform s stuurbaar vanop de PC ook ( je kan al die registers monitoren, lezen en schrijven vanop de PC ( via USB 2.0 : er zt een Cypress FX 2 op het bord die niks anders doet dan data vlammen aan 480 Mb/s )
een visual bais cprogramma stuurt gans de boel.
in dat VB programma zit naast een gui waar je zelf knoppekes en meterkes en wijzertjes ook VBA. je kan daar dus ook dnge schrijven zoals ' if gain tralala. dat gaat volle gas over usb naar dat verilog block en terug. haast opdezelfde snelheid alshet intern draait op de control processor.
dat VB programma heeft ook een DDserver aan boord die naar matlab exporteert.

mijn 'synthese programma' maakt ook de matlab routines aan zodat je vanuit matlab ook dingen kan schrijven zoals "if gain...blablabla"
dat werkt allemaal haast even snel.

nu zijn er sommige zaken ( zoals de realtime speed control ) die op de interne processor ind e FPGA moeten draaien simpelweg omdat de latency van USB niet gegarandeerd is )

en daar wou ik dus ook weer de nios voor gebruiken.
maar dat ding is interruptgewijs zo traag dat het onmogelijk is. als de disk op toeren is krijgt de nios 60.000 interrupt per seconde op zijn dak voor de speed control loop alleen al... en er zijn nog 5 andere loops ook. met 422 en 222 clockticks voor in en out is dat een ramp.

ik heb het al getest op die pruts '8051' deat speed control loopke kan ik haast op 1.2 MHz bombarderen. en das met een 48 MHz clock.
op de nios met 48 MHz clock plooit de nios al bij 40.000 interupts / seconde

32 bit risc my ass ... geef mij maar een goeie ouwe 8051.

de mensen van altera moesten toegeven dat de nios inderdaad gemaakt is voor controle applicaties en niet als realtime engine. voor de realtime moet je die 'c' to hardware' gebruiken . de instructuion set uitbreiden etc. dan kan je dat. maar dan zit je weer met een 'vast' systeem waar een wiskundige die de algoritmes moet modelleren met matlab niet kan aan prutsen.

en das net het gedeelte wat ik user programmeerbaar wil houden. dat moet net software blijven ! ik noem dat 'software emulated hardware'

dit ding moet zo flexibel mogelijk zijn. schrijf de code . test ze en later wordt dat in verilog gegeoten en komt het in en ASIC ( niet meer in een FPGA... dat platform is slechts een hulpmiddel om de asic te ontwerpen )

enfin
lang verhaal. das een project waar serieus wat man-uren in zitten ( ik ben daar al fulltime mee bezig sedert vorig jaar december... ) het draait goed. de matlab koppeling werk. VBA werkt goed. de user interface is razendsnel ( ik heb zelf eigen controls moeten schrijven zoals knoppekes en meterkes. de ingebakken controls van windows zijn veeeeeel te traag gewoonweg omdat ze teveel paraters hebben
als je tekst aanpast op een button bijvoorbeeld moet de standaard control van windows gaan zien hoe groot de button is , welk backgournd color , welk font welk dit welk dat en dat pakt veel tijd.
mijn controls zijn veel simpeler. je kan niks instellen er is alleen de tekst op de buttun , een enabled flag en een click event. als de rest is 'hardcoded'

ik kan de user interface veeeeeel sneller updaten dan met standaard controls. normaal een window met 500 buttons de tekst updaten : een paar tiental keer per seconde.
als ik dat doe met mij 'buttons' das een wazig ding. je kan niks lezen.

enfin.

Als ik dat zo lees, zou ik zeker eens op zoek gaan naar een AVR / AVR32 core. D'r zijn goeie C ontwikkeltools voor. Lineaire memory map, zero overhead, zo goed als alle instructies nemen 1 clock cycle in beslag. Interrupt-in doet 't in +- 5 cycles, terugkeer in 3. (Das voor AVR 8-bit dan).

Die dingen zelf draaien op max 16Mhz. Maar zou je eens na kunnen gaan hoe dat moet lopen op 50MHz of hoger als core in een FPGA..

De GCC compiler implementeerd de standaard C taal. 1 van de dingen die C definieert is dat je static variabelen op nul beginnen.

In een microcontroller als de NIOS moet je dus een memset (data_start, 0, data_end-data-start); doen.

Zo haal je al de eerste library functie binnen. Zo zijn er nog veel meer dingen die zonder dat jij er iets voor doet zomaar vanzelf binnengehaald worden.

Als je zegt dat je dat zelf wel wilt doen (of dat het niet nodig is!), dan moet je dat uitzetten: --nostartup zoals aangegeven.

Om zo min mogelijk met microcode te doen, en een snelle interrupt respons te verkrijgen, slaan moderne processoren vaak niets anders op de stack op dan de PC en evt het status register. De rest van de registers moet je zelf doen. Dat is in dit geval je voordeel: jij hoeft helemaal geen dingen op de stack te gooien. (*).

Ter info: De intel 960 processor kon gegarandeerd in 30ns (1 clock tick) in z'n interrupt zitten. Moest je wel er voor zorgen dat de interrupt de NMI is (interrupt adres in hardware register, niet in RAM), en dat je geen DIV instructies gebruikt in je MAIN (die kosten 2 clocks).

Over "alle processoren maken de huidige instructie af"... Dat hoeft niet: Als je weet dat alle "effecten" van de huidige instructie nog niet hebben plaatsgevonden, kan je hem schrappen en eerst de interrupt gaan doen. Dus als een mul a, b, c instructie iets doet van c := b*a; kan je als de instructie normaal 32 clocks duurt gewoon tot de laatste clock de instructie afbreken en de volgende keer overnieuw beginnen. Vervelend wordt het natuurlijk als je op die manier een main programma kan blijven aborteren zonder dat ie ook maar 1 instructie verder komt.

Er zijn er processoren die schaduw registers hebben voor de interrupt routines, en dus niks op de stack hoeven te zetten. Dat wordt soms ook doorgetrokken dat de SFUs (Special Function Units) hun interne state ook kunnen schaduwen in geval van een interrupt. Dus als je een interrupt krijgt, gaat de processor in z'n geheel met een andere register-set en "interne state" verder, meteen IN de irq routine.

Dit laatste is een logische optie voor de familieleden van i386 architectuur processoren die hyperthreading doen. (maar die staan er bepaald niet om bekend om snel code uit de IRQ te kunnen afhandelen.)

(*) Weet je dat zeker? De C-compiler heeft de vrijheid om een zwik registers te gebruiken. Die moet je niet zomaar in een hoger-prioriteit interrupt gaan overschrijven. Dan gaan er dingen fout...

De GCC compiler implementeerd de standaard C taal. 1 van de dingen die C definieert is dat je static variabelen op nul beginnen.

In een microcontroller als de NIOS moet je dus een memset (data_start, 0, data_end-data-start); doen.

Zo haal je al de eerste library functie binnen. Zo zijn er nog veel meer dingen die zonder dat jij er iets voor doet zomaar vanzelf binnengehaald worden.

kijk, dat begrijp ik dus niet. ik gebruik geen dynamische allocatie in het programma. Ik veronderstel dus dat de compiler slim genoeg is om gewoon elke variabele hard vast te pinnen op een bepaalde locatie at compile time.

wat jij schrijft is dat GCC at runtime memory gaat alloceren ?

Als je zegt dat je dat zelf wel wilt doen (of dat het niet nodig is!), dan moet je dat uitzetten: --nostartup zoals aangegeven.

ok, probeer ik

Dat is in dit geval je voordeel: jij hoeft helemaal geen dingen op de stack te gooien. (*).

ik veronderstel dat de compiler slim genoeg is om uit te vlooien wat er op de stack moet gesmeten worden.
Das normaal gesproken een kwestie van : de ISR eerst te compiler en kijken welke registers er gemodificeerd worden door de ISR. Die registers moet de compiler bewaren (push/pop).
ik heb de assembler dump eens bekeken van zo een NIOS programma. ze smijten gewoon default alles op de stack. de compiler analyseert niks. er zit daar gewoon ergens een 'macro' in. niks optimisatie.

een van de redenen dat ik alle variabelen die in de ISR gebruikt wordt op hardcoded adressen zet is juist dat de compiler dan perfect kan uitvlooien waar er aan geroefeld wordt. elke ISR krijgt van mij zijn eigen stuk memory ( herinner je de 'registerbanken' bij een 8051). identiek het zelfde princiepe. je hoeft niks te bewaren of restoren en of op te kuisen. elke routine heeft zijn eigen 'bank' waar hij kan in spelen. het enige wat moet gepusht/gepopt worden is in princiepe de accumulator en het status register en zelfs dat hoeft in mijn geval niet aangezien mijn hoofdprogramma dit is :

void main (void) {while 1{};}

De ISR's kunnen elkaar ook niet onderbreken (daar steekt de hardware rond de CPU een stok voor) . het hoofdprogramma in assembler zou er zo uit moeten zien :

begin : sjmp begin

en de rest zijn interrupt handlers.

als ik dat in PL/M of C51 van intel schrijf krijg ik exact de code die ik zoek. Is GCC dan zoveel 'slechter' als compiler ?

ik ga de architectuur van dat ding veranderen.
gewoon een main programma wat een register poll'd.
als dat register verandert : spring naar die subroutine.
en dan zorg ik dat de hardware gewoon een nummer zet in dat register.
0 = doe niks
1= handler 1
2= handler 2
3= handler 3
enzovoort.

dat zal stukken sneller gaan, en hopelijk maakt de compiler er dan geen pot van...

Met het pollen van registers heb ik ook geode ervaringen... geen probleem tegen 500kHz.

probleem is opgelost. de nios ligt in de vuilbak en er zit nu een STR710 in. De atmel die ik eerst op het oog had kan niet booten vanaf zijn EMI ( ik ga de interne flash niet gebruiken. de software verandert een paar keer per uur. ik kan gewoon via de FPGA controle pakken over de SRAM die aan de ARM hangt. vlam het programa erin via de USB poort , door da FGPA en eenmal klaar laat ik de ARM uit reset komen. geen bootloader nodig. das weer werk en miserie gespaard. )

de STR710 is een arm7 met een interrupt controller aan boord. het is gegarandeerd dat je in de interrupt handler zit binnen 12 clockticks + clockticks nodig om huidige instructie af te werken. de return is altijd 6 clockticks.

en dat is inclusief het saven van de context.

de IAR compiler ondersteunt die processor volledig inclsief de interrupt controller. je geeft gewoon via een directive op '__IRQ' aan welke interrupt de routine moet vasthaken en klaar.

volgende week ga ik op cursus bij altera speciaal voor de nios. reken maar dat ik het 'ettertje' op de voorste bank zal zijn met alle 'lastige' vragen ...

[Bericht gewijzigd door free_electron op donderdag 18 oktober 2007 16:07:15 (15%)]

Klinkt interessant. Die core + compiler, kosten die geld? of zijn die open beschikbaar? het zou namelijk handig zijn om toch ook een backup te hebben voor de nios, als ik nog eens iets snel moet oplossen...

Hou ons op de hoogte van de nios cursus Komen die ook eens naar Belgie?

EDIT: ik zie juist dat die str een standalone chip is, laat dus maar

[Bericht gewijzigd door stecj366 op donderdag 18 oktober 2007 16:35:33 (12%)]

Op 18 oktober 2007 16:34:29 schreef stecj366:
Klinkt interessant. Die core + compiler, kosten die geld? of zijn die open beschikbaar? het zou namelijk handig zijn om toch ook een backup te hebben voor de nios, als ik nog eens iets snel moet oplossen...

Hou ons op de hoogte van de nios cursus Komen die ook eens naar Belgie?

EDIT: ik zie juist dat die str een standalone chip is, laat dus maar

ik geloof de nios cursus loopt ook in engeland. tis wel niet goedkoop. 1500 $ voor 3 dagen ...

Op 18 oktober 2007 17:31:30 schreef free_electron:
[...]

ik geloof de nios cursus loopt ook in engeland. tis wel niet goedkoop. 1500 $ voor 3 dagen ...

Noemt die niet goedkoop:+ Eerlijk gezegd vind ik dat nog mee vallen. Niet dat ik het als hobbiest een leuk bedrag vind, maar voor een profesionele cursus is dit een bedrag waar ik niet van schrik.