Mest vettiga 32-bit mikroprocessor?

[Icecap]

DavidS: Och sedan är det nog ganska feltänkt att skippa C för att räkna i assembler. Det tunga i systemet är inte koden men uträkningen, det blir lite snabbare med assembler - med betoning på lite! Det är nog hela uträkningen som behöver strömlinjeformas istället, det kommer att ge utdelning!

Det verkar vara ett vanligt 80/20-problem: lägg 80% energi på att åtgärda fel sak och det ger 20% effekt. Men lägg 20% energi på att åtgärda rätt fel och du får 80% effekt.

Du verkar lägga 80% på fel problem...

[psynoise]

Precis som vid alla stora projekt är det en fördel att dela upp systemet i flera små block. När man väl har klart för sig hur man kan lösa alla uppgifter kan man börja med att konstruera. Sedan under konstruktionens gång beroende på hur det utvecklar sig kan man välja vad som ska vara med på kretskortet och vad som ska vara externt. I detta fallet kanske det tom kan handla om vad som ska vara med i en viss enhet och inte vara med. T.ex kan ett kretskort bestå vara flera olika beräkningsenheter (µC, DSP, FPGA...) som i en första prototyp enbart koncentrerar sig på en uppgift.

[jesse]

Med tanke på vad du ska göra och vad som redan sagts i den här tråden så är det självklart att du ska använda en 32-bitars processor. Då slipper du optimera allt till bristningsgränsen för att det ska fungera i en 8-bitars. Ju större marginaler desto lättare att få det att fungera. Men du behöver mycket väl genomtänkta algoritmer för uträkningarna. Hur ofta och när det ska räknas. En linjär förflyttning kräver inga kvadratrötter (mer än en gång).

[blueint]

Finns uträkningarna som behövs för X/Y/Z förflyttning och G-kod presenterade någonstans?

[bearing]

Icecap, han säger inte att han ska skriva i assembler, utan vill studera koden som genererats av kompilatorn. De flesta kompilatorer kan skapa en .lst-fil som innehåller C-koden följt av genererad maskinkod och assembler. Där är det ju rätt enkelt att baserat på genererad maskinkod avgöra om C-koden är bra.

Ifall han ska göra en komplett G-kod tolk är det nog en stor fördel med en 32-bit processor, det tror jag med.

Kod för G-kodtolk finns, om inte även annan plats, i källkoden för EMC2.

[DavidS]

Jag har tagit bort allt oväsentligt och mäter tiden det tar på detta sätt:

Kod: Markera allt

void setup() {
  Serial.begin(115200);
}
extern volatile unsigned long timer0_overflow_count;
long xpos = 10265;
long ypos = 23032;
long zpos = 25889;

void loop() {
  static unsigned long hptime = hpticks()*4;
  int xPulses = (xpos *10) / 25; // 99999*10/25 < 0xFF inget fel med att sätta xPulses som int.
  int yPulses = (ypos *10) / 25; //25 = (5000*10)/2000
  int zPulses = (zpos *10) / 25;
  hptime = hpticks()*4 - hptime;
  
  Serial.print(xPulses, DEC);
  Serial.print(" ");
  Serial.print(yPulses, DEC);
  Serial.print(" ");
  Serial.println(zPulses, DEC);
  Serial.print("computation time: ");
  Serial.println(hptime, DEC);
  delay(1000);
}
unsigned long hpticks(void) {
	return (timer0_overflow_count << 8) + TCNT0;
}

Resultat:

Kod: Markera allt

4106 9212 10355
computation time: 88
4106 9212 10355
computation time: 92
4106 9212 10355
computation time: 88
4106 9212 10355
computation time: 88
4106 9212 10355
computation time: 96

Stigning: 5mm/varv (5000um/varv)
Pulser/varv: 2000


Jag har ju som sagt ingen hårdvara för att mäta tiden på annat sätt just nu men jag tycker det måste vara något fel någonstans för ~90us är väldigt mycket.

[blueint]

Fast hur mycket MIPS, RAM, osv.. krävs eg?

Sedan kanske inte allt behöver lagras i mikrokontrollern?

[sneaky]

Är du säker på att timern går i rätt hastighet också? (har inte den blekaste om hur lång tid detta skall ta men det var en tanke som slog mig och något som JAG skulle ha missat...)

[sodjan]

> Jag har tagit bort allt oväsentligt och mäter tiden det tar på detta sätt:

På vadå? Vilken hårdvara?

> något fel någonstans för ~90us är väldigt mycket.

Definiera "mycket"? Vad betyder det i din värld?

Sen så kanske inte 90 us för 3 multiplikation och 3 divisioner
med "longs" kanske inte är speciellt mycket, men det beror helt
på vilken plattform det är...

[bearing]

99999*10/25 < 0xFF inget fel med att sätta xPulses som int.

99999*10/25 = ca 40000 vilket inte ryms i en int, men i en unsigned int.

Den där divisionen lär ta grymt lång tid... Ett sätt att snabba upp beräkningen är att göra om den till division med en multipel av två. Du skulle du t.ex. kunna göra:

Kod: Markera allt

xPulses = (xpos * (65536UL*10/25)) / 65536UL

d.v.s:

Kod: Markera allt

xPulses = (xpos * 26214UL) / 65536UL

Sista siffran kommer bli fel ibland, men det blir den nog med din andra metod också.

Fördelen är att här sker bara multiplikation, och AVR har inbyggd multiplikator. Visserligen är den bara 8x8, så det lär ta en stund ändå, men antagligen betydligt snabbare än division.

[DavidS]

@bearing Tack, det är ju sådana knep jag själv inte kommer på.

Timern verkar fungera, testade med Arduinos officiella timer som är micros() och får samma resultat. Tiden beräkningarna tar nu är nere på 8-12us. (upplösningen på micros() och hptime är 4us)

För övrigt så är det just Arduino med en Atmega168 som körs i 16MHz och det är en 8bit-processor.
Själva G-koden i den form det nu blir kommer ligga i EEPROM men dit är det ju långt så tills vidare lägger jag allting i flash eller läser in seriellt om det finns tid över...

-edit- Har beställt chipKit Uno32 och en Open Workbench logic sniffer så får hoppas det duger tills vidare. Kan ju handla ett mer komplett PIC32-utvecklingskit senare om det är något jag vill fortsätta med.
Snålade även till med en Pickit3-klon från kina för 190kr inkl frakt och kablar...