ARM processor gezocht.

Ik weet dat NXP zeker ARM uC's heeft met een 32bits external interface. Ze worden echter geshared met de GPIO. Mischien heb je niet goed gezocht? (of begrijp ik het niet )

BV: LPC2468:
- 512kB flash
- 98 kB RAM (64 + 16 Ethernet +16 USB + 2 RTC)
- Externalbus : 32 Bits

Ik heb vorig jaar een ontwerp gemaakt met de LPC2294 met extern SRAM. 16 (24) bits adres en 8 (16) bits data.. helaas.

Hmm, dan snap ik het niet: Als ik in de datasheet kijk van de LPC2294 dan zie ik duidelijk dat alle data lijnen(D0-D31 => P2.0-P2.31) en adreslijnen (A0-A23 =>P3.0 P3.23) naar buiten zijn gevoerd.

Mij lijkt het dan mogelijk hierop een 32Bits RAM/FLASH aan te sluiten?

Ik vraag dit omdat ik aan het nadenken was over een systeem met een LPC2xxx chip met externe ram/rom. Als het niet mogelijk is om een 32 bits breede RAM/FLASH aan te sluiten zal ik ook ergens anders na moeten gaan zoeken.

Op 16 oktober 2007 03:33:31 schreef free_electron:
Een vraag voor onze ARM guru's:

Ik ben op zoek naar een andere 32 bit processor. de NIOS ligt in de vuilbak. dat ding is de naam 'processor' niet waard. 650 clockticks voor interrupt ...

650 clockticks. Is dat echt zo? Dat kan toch haast niet????

Ik zoek dus een ARM met een 32 bit EMI interface. ( external memory.) Tmag Arm7 of Arm9 of cortex zijn . eendert wat. als er maar 'tools' voor zijn .

Cirrus Logic heeft (of in ieder geval had) ARM processoren met 32 bits bussen. Hetzelfde geldt voor Intel. Een andere optie is een MIPS AU1xxx processor van Raza Microeletronics. Maar wat je ook kiest, je zult er zelf nog wel wat assembly tegenaan moeten gooien om de processor te starten en te initialiseren. Ik heb met zowel ARM als MIPS ervaring en de assembly valt wel mee als je even de 'quick reference card' van de instructieset ophaalt.

Ik begrijp niet waarom je GCC en Eclipse overboord gooit. De IDE die is bijgeleverd bij IAR, Keil, etc, etc is altijd een sluitpost en dus per definitie brak. Ja, je kunt een tekstbestandje editten en je kunt op de knop compile klikken maar daarbij houdt het meestal wel op. Eclipse is vele malen beter. Ik gebruik zelf GCC en Eclipse voor alle platformen. Ik hoef dus nooit met een nieuwe IDE of compiler te leren omgaan als ik weer eens met een nieuwe processor begin. 99% van de opties zijn hetzelfde. Tijd die je in GCC investeerd is dus nooit verloren. Bovendien zijn veel embedded compilers tegenwoordig gebaseerd op GCC. Als je een ARM ontwikkelomgeving koopt, dan heb je altijd GCC te pakken met een brakke IDE.

yep 650 clockticks ..

bijvoorbeeld

http://www.altera.com/literature/an/an284.pdf

pagina 14 : een uart interrupt handlen : 93 erin , 64 eruit. en 107 om een karakter te verwerken ...
das 264 instructies om een uart te lezen ! stel u voor dat data aan 100.000 karakter per seconde binnerolt. ( 1 megabaud ). je moet al op 26 MHz clocken alleen om de uart bij te houden ...

der staat een paragraaf in over 115 k baud. je hebt 8.4% cpu tijd nodig op 33 HMz clock. en ze zijn er nog TROTS op ook dat het slechts 'zo weinig' is.

der is een andere pdf (kzal hem straks posten. khebbem opt werk. )met de tabel per CPU. voor een 'e' versie stijgt de latency naar oven de 600 clockticks...

GCC overboord gooien. simpel : het werkt niet.
identiek dezelfde source gecompileerd met GCC : 6.4 kilobyte. tegen 40 bytes met IAR C .... en das zonder aan 1 instelling te komen. niks configureren. plets het op de computer en click 'build'.

ik heb niks tegen eclipse. tis GCC dat een onding is.

ik heb geen tijd om met gcc te leren werken. mijn project is nu al 3 weken te laat wegens die NIOS miserie, ik moet mijn bord gaan aanpassen om er een ARM op te zetten ( moet er eerst nog ene vinden met het 'feature' die ik zoek ... 32 bit data bus). board respin gaat paar duizend dollar en 2 weken kosten. dan moet de bootloader ontwikkled worden... de download code en dan nog de applicatie op de arm porteren. dat wordt minstens 2 maand vertraging.

die compiler van iar kostte mij 2 minuten om te installeren en het eerste programma wat ik compileerde was direct de juiste 'footprint' ( ik heb de machinetaal bekeken die eruit kwam.

het kan perfect zijn dat de onderliggende compiler in IAR de gcc compiler is( maar ik geloof her niks van. volgens mij zijn IAR en KEIL hun eigen compilers. er zijn genoeg benchmarks te vinden op het interent die GCC tegen IAR en KEIL vergelijken.. dus er MOET een verschil zijn ). maar het voordeel van de IAR omgeving is dat hij juist ingesteld staat en dat je dat niet allemaal meer moet gaan uitvlooien.
new roject. je kiest je target chip. geeft aan of het in ram of flash moet staan en je begint te coden. click built en tis klaar. alle optimisatie is gedaan.

en het heeft mooie preprocessor commandos die je toestaan om variabelen direct te mappen op hardware adressen. zonder geklooi met pointers.

het moet simpel zijn ( ik haat complexe dingen. ik krijg daar hoofdpijn van ) en het moet vooruit gaan.

Op 16 oktober 2007 16:07:48 schreef free_electron:
yep 650 clockticks ..

bijvoorbeeld

http://www.altera.com/literature/an/an284.pdf
pagina 14 : een uart interrupt handlen : 93 erin , 64 eruit. en 107 om een karakter te verwerken ...
das 264 instructies om een uart te lezen ! stel u voor dat

Brrr.... Dat is minder dan 650 clockticks, maar nog altijd veel teveel.

het kan perfect zijn dat de onderliggende compiler in IAR de gcc compiler is( maar ik geloof her niks van. volgens mij zijn IAR en KEIL hun eigen compilers. er zijn genoeg benchmarks te vinden op het internet die GCC tegen IAR en KEIL vergelijken.. dus er MOET een verschil zijn ). maar

Er is een verschil en dat zit in de bijgeleverde C library. De benchmark is meestal drystones en die meet ook een deel van de C library mee. Eigenlijk is drystones dus helemaal niet geschikt om de performance van een processor/compiler te meten omdat de meetmethode niet zuiver is.

Lees maar eens op:
http://www.compuphase.com/dhrystone.htm

Keil heeft de pagina waar bovenstaand artikel naar verwijst inmiddels van hun site verwijderd en heeft op hun website helemaal geen ARM benchmarks meer staan. Dat zegt genoeg lijkt mij.

Ik heb zelf de standaard C library van de MSP430 gcc compiler naar ARM overgezet. Die library is nog compacter dan de reguliere C libraries.

Op 16 oktober 2007 16:07:48 schreef free_electron:
identiek dezelfde source gecompileerd met GCC : 6.4 kilobyte. tegen 40 bytes met IAR C .... en das zonder aan 1 instelling te komen. niks configureren.

Dus als je GCC vraagt zomaar iets te doen (je geeft niet precies wat), doet ie iets anders dan als je IAR vraagt zomaar iets te doen? En jij bent daar verbaasd over? Goooh...

Op 16 oktober 2007 03:33:31 schreef free_electron:
Bij NXP ST en ATMEL vang ik bot ... alleen 16 bit EMI ...

Het Olimex bord http://www.olimex.com/dev/lpc-e2294.html heeft een 32 bits data bus met daarom 2 x 16 bits RAM chips parallel. Ik weet niet waar jij je botten haalt, maar Olimex zoekt blijkbaar beter.

Op 16 oktober 2007 17:28:27 schreef Wouter van Ooijen:
[...]

Dus als je GCC vraagt zomaar iets te doen (je geeft niet precies wat), doet ie iets anders dan als je IAR vraagt zomaar iets te doen? En jij bent daar verbaasd over? Goooh...

[...]

Het Olimex bord http://www.olimex.com/dev/lpc-e2294.html heeft een 32 bits data bus met daarom 2 x 16 bits RAM chips parallel. Ik weet niet waar jij je botten haalt, maar Olimex zoekt blijkbaar beter.

Gezien de situatie mag iets minder bot dan wel bij-de-hand ook wel.

Op 16 oktober 2007 17:14:36 schreef Nico.c:
[...]
Brrr.... Dat is minder dan 650 clockticks, maar nog altijd veel teveel.

je moet deze eens lezen : http://www.altera.com/literature/hb/nios2/n2sw_nii52006.pdf

pagina 9

Nios 2/e . latency + response + recovery land op 722 clockticks ....

ongelofelijk maar waar.

Gezien de tijdsdruk waar je mee zit denk ik dat IAR best een goede keuze is. Zeker als die compiler toch al voorhanden is in je bedrijf. De projectjes die ik al gedaan heb met IAR waren ook altijd al een aangename verassing qua gegenereerde code size. Ik zou niet meer omkijken qua compiler keuze en je concentreren op de andere problemen.

Daarmee wil ik zeker niet zeggen dat GCC slecht zou zijn. Integendeel, ik heb het ook al ettelijke keren gebruikt. Maar GCC is en blijft een klassieke command line tool in de beste UNIX traditie. Het vraagt in het begin een vrij stevige leerkurve. Of althans toch voor embedded development. Ik durf best te zeggen dat ik in mijn eerste projectje een dikke week bezig was eer ik een werkende omgeving had die aan al mijn eisen voldeed (en dan praat ik nog niet over een IDE maar over de libraries, linker scripts, make files, etc...). Een boek dat mij wel veel geholpen heeft om wegwijs te worden in de embedded GCC doolhof is Embedded System Design on a Shoestring van Lewin Edwards (ISBN 0750676094).

Op 16 oktober 2007 17:28:27 schreef Wouter van Ooijen:
[...]

Dus als je GCC vraagt zomaar iets te doen (je geeft niet precies wat), doet ie iets anders dan als je IAR vraagt zomaar iets te doen? En jij bent daar verbaasd over? Goooh...

tjah, kijk... ik ben een simpele ziel. Als ik dit programmatje schrijf in 'c' ( das effectief wat ik gecompileerd heb !)

int x=0;
void main (void){
x=x+1;
}

Als ik gewoon op 'build' click en de ene compiler 'schijt' 6.4 kilobyte (GCC) en de ander 40 bytes (IAR) .... dan is er toch iets serieus mis hoor. Als je dat allemaal maar 'normaal' vindt .. ik niet!

Als het nu nog 60 bytes tegen 40 geweest was , zou ik er nooi tene punt van gemaakt hebben. Maar 6484 (-O3. met -O1 was het 6508 bytes ...) tegen 40... daar valt niet over te discuteren. We hebben het tenslotte over een tool om embedded code te maken.

embedded code moet aan 3 dingen voldoen :

1- zo klein mogelijk zijn in rom
2- zo weinig mogelijk ram gebruiken
3- zo snel mogelijk draaien.

we hebben sedert gisteren een nieuw demobordje . wordt verkocht voor 39 $ ... http://www.stm32circle.com/
voor die prijs kan je dat niet zelf in elkaar zetten. usb erop , usb jtag probe erin . grafisch lcd.. vanalles... en er wordt een 32k code toolchian gratis weggegeven ook...

de 2294 van NXP had ik nog niet bekeken... kzal direct eens gaan zien.

Op 16 oktober 2007 17:51:21 schreef MagicBox:
Gezien de situatie mag iets minder bot dan wel bij-de-hand ook wel.

Ik weet niet op welke situatie je doelt, maar free_electron trekt lekker van leer tegen een paar ARM processors (op onjuiste gronden) en tegen GCC compilers (op discutabele gronden). Ik antwoord ongeveer in de zelfde stijl, maar wel met correcte informatie.

Op 16 oktober 2007 18:14:35 schreef free_electron:
Als ik gewoon op 'build' click en de ene compiler 'schijt' 6.4 kilobyte (GCC) en de ander 40 bytes (IAR) .... dan is er toch iets serieus mis hoor.

Je klikt op compile, dus je gebruikt GCC niet direct? Dan klaag je dus eigenlijk alleen over de keuzes die jouw GUI maakt? wat heeft dat met GCC te maken?

Optimaliseren voor size (-Os) lijkt me in ieder geval een betere keuze dan -O3 of -O1.

Op 16 oktober 2007 18:16:39 schreef Wouter van Ooijen:
[...]
Je klikt op compile, dus je gebruikt GCC niet direct? Dan klaag je dus eigenlijk alleen over de keuzes die jouw GUI maakt? wat heeft dat met GCC te maken?

Dat klinkt logisch voor jou en mij, maar ik vermoed dat wij beiden uit de software sector komen. Ik kan mij best voorstellen dat iemand die onder deadline druk staat en wiens beroep er niet uit bestaat om elke dag voor de volle 100% met software development bezig te zijn het ietwat anders ziet. Of het nu al dan niet kan met GCC of niet is in dat geval op zijn zachts gezegd academisch. Wat telt is kan IK het en binnen MIJN deadline? GCC is een prachtige tool, mits je de tijd krijgt om hem grondig te leren. Maar dat is gewoon niet in alle gevallen en voor iederen even practisch.

Als er een tijdsdruk is dan moet je niet door een hardware designer een stuk software laten maken met tools waar ie geen kaas van gegeten heeft.
En eh, bot reageren is FE ook niet zo vreemd, dus dat Wouter zich verlaagd naar datdelfe nivo lijkt me hier volledig terecht.

FE: waarom check je niet even de assembly die GCC ervan maakt? (misschien later als de storm is gaan liggen) Dan weet je waarom je zo'n grote image krijgt. Nu blijft het gokken.

[Bericht gewijzigd door flipflop op dinsdag 16 oktober 2007 19:33:03 (25%)]

Op 16 oktober 2007 18:29:35 schreef Omicron:
[...]
Dat klinkt logisch voor jou en mij, maar ik vermoed dat wij beiden uit de software sector komen. Ik kan mij best voorstellen dat iemand die onder deadline druk staat en wiens beroep er niet uit bestaat om elke dag voor de volle 100% met software development bezig te zijn het ietwat anders ziet.

Dan lijkt het me logisch dat zo iemand zich realiseert dat zijn zienswijze maar een losse gooi is.

Op 16 oktober 2007 18:29:35 schreef Omicron:
GCC is een prachtige tool, mits je de tijd krijgt om hem grondig te leren. Maar dat is gewoon niet in alle gevallen en voor iederen even practisch.

Maar FE gebruikt geen kale GCC. In plaats van het te hebben over GCC kunnen we het dus beter hebben over de toolset die hij gebruikt (die hij overigens niet genoemd heeft?)

Op 16 oktober 2007 19:31:27 schreef flipflop:
FE: waarom check je niet even de assembly die GCC ervan maakt? (misschien later als de storm is gaan liggen) Dan weet je waarom je zo'n grote image krijgt. Nu blijft het gokken.

Niet nodig om te gokken. Zo'n verschil in code wordt niet veroorzaakt door de codegenerator maar door de meegelinkte libraries. Kijk naar de linker opties en/of in de linker map file.

Op 16 oktober 2007 18:14:35 schreef free_electron:
[...]

tjah, kijk... ik ben een simpele ziel. Als ik dit programmatje schrijf in 'c' ( das effectief wat ik gecompileerd heb !)

int x=0;
void main (void){
x=x+1;
}

Als ik gewoon op 'build' click en de ene compiler 'schijt' 6.4 kilobyte (GCC) en de ander 40 bytes (IAR) .... dan is er toch iets serieus mis hoor. Als je dat allemaal maar 'normaal' vindt .. ik niet!

Ik heb jouw programma met Eclipse /Gnuarm gecompileerd. Optie nostartfiles aangevinkt en optimalisatie op O2 gezet. Dit is het resultaat van arm-elf-objump -DS test.elf:

Disassembly of section .text:

00008000 <main>:
    8000:	e59f200c 	ldr	r2, [pc, #12]	; 8014 <.text+0x14>
    8004:	e5923000 	ldr	r3, [r2]
    8008:	e2833001 	add	r3, r3, #1	; 0x1
    800c:	e5823000 	str	r3, [r2]
    8010:	e12fff1e 	bx	lr
    8014:	00008118 	
Disassembly of section .bss:

00008118 <x>:
    8118:	00000000 	

Dat zijn in totaal 20 bytes code en 8 bytes data. Op adres 8014 staat een pointer naar x.

Strict genomen kan je de code naar alleen een return (als zoiets al bestaat voor main) compileren, de code doet namelijk helemaal niets (tenzij x volatile is).

Op 16 oktober 2007 19:47:24 schreef Wouter van Ooijen:
[...]

Niet nodig om te gokken. Zo'n verschil in code wordt niet veroorzaakt door de codegenerator maar door de meegelinkte libraries. Kijk naar de linker opties en/of in de linker map file.

Moet je voor de gein eens naar de benchmarks van de IAR arm compiler kijken. Om te gillen!

http://www.iar.com/p43943/p43943_eng.php

Hier wordt statistiek weer eens gebruikt om te liegen alsof het gedrukt staat. Door deze zielige poging tot misinformatie van IAR weet ik zeker dat de GCC compiler voor ARM de IAR ARM compiler ver achter zich laat voor wat betreft compactheid en snelheid.

Op 16 oktober 2007 20:23:34 schreef madwizard:
Strict genomen kan je de code naar alleen een return (als zoiets al bestaat voor main) compileren, de code doet namelijk helemaal niets (tenzij x volatile is).

Dat kan wel als x binnen main is gedefinieerd.
Omdat x buiten main gedefinieerd is, kan main niet zien waar x vandaan komt. Volatile geeft alleen maar aan dat voor iedere nieuwe operatie op x, x opnieuw uit het geheugen moet worden gelezen en gedurende de uitvoer van main (of een andere functie) niet in een register mag worden opgeslagen.

Stel x wordt in een interrupt verhoogd, dan werkt

while(x<10)
{
//doe iets
}

alleen in main als x als volatile is gedeclareerd. Is dat niet het geval, dan wordt x bewaard in een register en zal de while nooit eindigen als x kleiner was dan 10 op het moment van het starten van de while lus.

Op 16 oktober 2007 20:28:38 schreef Nico.c:
[...]
Moet je voor de gein eens naar de benchmarks van de IAR arm compiler kijken. Om te gillen!

Als redactuer van een blad zou ik zo'n bijdrage meteen weggooien:
- de code is niet beschikbaar, dus het is niet controleerbaar
- voor dit soort 'kleine' applicaties is meestal de size van de libraries dominant, maar er wordt niet vermeld welke libraries zijn gebruikt, wat de linker opties precies zijn, en met welke compiler opties de libraries gecompileerd zijn.

Gewoon niet lezen dus.

Maar het zou wel zielig zijn voor de engineers die de compiler hebben gemaakt om die direct af te schrijven omdat marketing er een zooitje van maakt.

oh maar ik ben niet geshokeerd hoor. ben wel meer gewend.

ik trek niet van leer tegen arm. das nu gebleken beter te zijn dan NIOS. een arm kan een interrupt handlen in 12 tot 16 ticks ( der is blijkbaar ene 'store multiple register' instructie aanwezig ) tegen 722 op NIOs ....
maar its nog altijd zwakker dan een 8051 die interrupts handled in 4 clockticks.... en das 25 jaar oud dat ding... nuja die 51 is gebouwd om sturingen te doen heeft meerdere registerbanken dus je hoeft eigenlijk niks te bewaren. switch gewoon van bank en klaar. een arm is more 'generic'.

over de compiler daarentegen...

Dit is de situatie:

Ik installeer de NIOS ontwikkelomgeving die een voorgeconfigureerde GCC bevat voor de NIOS II processor (1 processor). daar zijn wel 500 instellingen aan waar je allemaal kan mee gaan prullen. ik blijf daar af.

ik installeer IAR voor de STR710 ( 1 processor ).
daar zijn ook allerhande instellingen aan. ik blijf daar ook af.

Ik kom NERGENS aan. ik blijf van al die instellingen vanaf. De fabrieksinstellingen zijn 'goed genoeg' voor dergelijke 'kleine' projectjes.

ik maak in alle twee een BLANCO nieuw 'C' project aan.

ik schrijf het volgende programma :

int x=0;
void main (void){
   while (1){
       x=x+1;
   }
}

de ene compiler maakt daar 6484 bytes van . de andere 40.... das is compleet abnormaal.

die compiler moet het volgende zien:

- er wordt 1 integer gedeclareerd. die moet ik ergens stoppen.
- er is slechts 1 routine: de main. die pakt niks binnen en levert ook niks af ( in die GCC omgeving moet ik main al als 'int main(void)' definieren. mijn 'main' retourneert helemaal niks ... dus waarom is dat weeral nodig ? dat uitvlooien alleen al heeft mij 15 minuten gekost. compiler kwam steeds met 1 error af...)

while 1... das dus altijd ...

en x=x+1 das de inhoud van geheugenplaats x pakken. dat in de accumulator gooien er 1 bijtellen en terugplaatsen in x.

Dus de compiler gaat aan de slag : (in gesimplifieerde assembler. ik ken de arm instructieset niet volledig, ik weet dat er 2 cycles zijn om lange adressen te moven etc.als ik een arm assembler dump zie kan ik ongeveer snappen wat het doet.)

compiler smijt 'a' op eerste vrije locatie in ram : 10000000h

main:  mov acc,10000000
       addc 1
       mov 10000000,acc
       jmp main

en klaar.

Dat is hetgeen ik daar geschreven heb in 'C' en das ook hetgeen de IAR compiler er van bakt. ik kan het optimaliseren door mat offset en base te werken en dan wordt de code nog iets kleiner. maar dat zijn nuances in de processor architectuur.

Die code die uit GCC komt begint vanalles te initialiseren: uart , baudrate zetten, ( heb ik NIET gevraagd !) en nog 500 andere dingen. Die compiler 'ziet' toch dat ik nergens 'printf' of scanf of floating point stuff gebruik. waarom wordt dat dan meegelinkt ? dat is toch waanzin ? iedereen jankt continue over 'bloatware'... als je van de duivel spreekt...

Link het mee als het gebruikt wordt. niks makkelijker dan dat. als je het gebruikt zit het erin. en als je het niet gebruikt spaar je rom uit. klaar als pompwater.

En je kan dat misschien allemaal instellen, maar waarom hoeft dat ? als die preprocessor snugger is bouwt hij eerst een tabel op van alle functie die nodig zijn en linkt hij alleen wat nodig is.

enfin. voor mij heeft GCC afgedaan. Der zijn teveel instellingen , en je moet teveel stuff doorworstelen die je weghouden van de opdracht.

het is dit verhaal: Bij IAR koop je een auto en je krijgt de sleutel. leren rijden moet je nog steeds doen ( leren programmeren . das bij GCC ook zo.)

Bij gcc krijg je een grote doos met blokjes, 10.000 bladzijden die je eerst moet doorworstelen om te weten hoe je het in elkaar moet zetten en als je een vraag hebt erover (op de NIOs forums), ontstaat er discussie of je nu een benzinemotor of een diesel in elkaar gaat zetten en welke er beter is voor het milieu. en of je misschien niet beter een fiets in elkaar zet en vegetarier wordt...

De opdracht was : kruip in de auto en ga om brood, kaas en vlees en haast je, want de winkel is binnen 5 minuten dicht!

Geen brood, kaas en vlees is geen eten vanavond...Das mijn punt. En met alle miserie die ik gehad heb met de NIOS en de GCC toolchain ervoor heb ik al 14 dagen geen brood in huis gehad...

ik besef maar al te goed dat ik gene programmeur ben en het ook nooit zal worden. het interesseert mij ook niet. ik heb een probleem op te lossen. en de kortste , snelste en meest pijnloze weg is de beste.