Tog och beställde den men det tar 2-3v för leverans.
Sitter man och kikar på olika exempel med just gpsen så verkar alla köra software serial istället för hardware. Min kod gör ju väldigt lite så det borde ju gå att lösa. Tänkte ta och koppla ihop min PIC och Arduinon och prata på 4800 buad för att se vad som händer. Gpsen är på 9600. Är lite enklare att testa saker när man styr båda sidorna och inte pratar genom en mystiskt hål
USART arduino
Re: USART arduino
Har du tillgång till en LCD att koppla upp mot arduinot? jag föredrar nämligen just LCD som övervakning istället för terminal då jag tycker det är smidigare... och ifall du kör med en LCD så blir ju den "riktiga" seriell porten ledig, då provar du att köra den istället... (pin 0 & 1)
Re: USART arduino
Jag har ingen lcd ledig men terminalen är inget jag behöver, har en LED som kan visa när korrekt data kommer. Så jag gjorde när jag körde med PICen.
Men är det bara att köra rakt på? Satt o letade lite på det och hittade faktiskt inte så mycket info om det. Dvs behöver man sätta upp den på nått vis?
Jag testade även att köra detta:
https://learn.adafruit.com/adafruit-ult ... ter-wiring
Men det var iof innan jag satte pinmode, kanske fungerar om jag sätter de till in och out...
Men är det bara att köra rakt på? Satt o letade lite på det och hittade faktiskt inte så mycket info om det. Dvs behöver man sätta upp den på nått vis?
Jag testade även att köra detta:
https://learn.adafruit.com/adafruit-ult ... ter-wiring
Men det var iof innan jag satte pinmode, kanske fungerar om jag sätter de till in och out...
Re: USART arduino
pinmode skall du inte sätta ifall du tänker köra "original" seriell, då räcker det med Serial.begin(9600); så sätter den ju 0 & 1 efter sitt eget behag
länken du hade visar hur de får GPS modulen att direkt snacka med datorn, därav kör de TX-TX RX-RX. vill du att arduinot skall prata med GPS så vänder du på dem... TX-RX, RX-TX
Nu har jag precis bara påbörjat att hålla på med just seriell trafik så jag kan ha något fel, men då hoppas jag att någon annan rättar mig! =) (ska ju själv ha en ELM323 at snacka med arduinot via seriell)
länken du hade visar hur de får GPS modulen att direkt snacka med datorn, därav kör de TX-TX RX-RX. vill du att arduinot skall prata med GPS så vänder du på dem... TX-RX, RX-TX
Nu har jag precis bara påbörjat att hålla på med just seriell trafik så jag kan ha något fel, men då hoppas jag att någon annan rättar mig! =) (ska ju själv ha en ELM323 at snacka med arduinot via seriell)
Re: USART arduino
Jag testade det och massa annat och inget fungerade. Igår fick jag min MEGA och ikväll satt jag o lekte igen. Gissa om det fungerade? Självklart inte! Var nära på o slänga skiten o ge upp för gott. Nu hade jag ju två hw serials vad kunde då vara felet? Kopplade om så att GPSen tog ström från Arduinon(som tar ström från USB) istället för eluttaget. Gav det en sista chans o kopplade upp det och allt fungerar 
Frågan är varför det fungerade med PICen (där jag iaf lyckades få ok data) men inte alls med Arduinon?
Nu undrar jag om jag ska fortsätta mitt projekt med denna eller ej.
Fördelen med Arduinon är att jag kan få flera USART vilket jag inte kan med PICen då jag inte kan löda ytmonterat. Samt mer hjälp finns att hitta på nätet. Nackdelen är att den är skitseg, hade ju problem direkt med PICen i 16MHz och den kan jag sätta i 64MHz. Samt att jag är nöjd med MPLAB och redan har min kod där för nästan hela projektet.
Projektet är som sagt en laptimer och kraven är som följande:
$PGTOP,11,2*6E <- Går tyvärr inte att få bort
$GPRMC,003022.099,V,,,,,0.00,0.00,060180,,,N*41 <- Saknar lite siffror pga att jag sitter inne
Nu har jag båda plattformarna så vad väljer jag att fortsätta med? Kan Arduinon fixa detta i 16MHz? Kan PICen klara det i 64? Eller ska jag skita i dessa o köra på en rasberry pi?
Frågan är varför det fungerade med PICen (där jag iaf lyckades få ok data) men inte alls med Arduinon?Nu undrar jag om jag ska fortsätta mitt projekt med denna eller ej.
Fördelen med Arduinon är att jag kan få flera USART vilket jag inte kan med PICen då jag inte kan löda ytmonterat. Samt mer hjälp finns att hitta på nätet. Nackdelen är att den är skitseg, hade ju problem direkt med PICen i 16MHz och den kan jag sätta i 64MHz. Samt att jag är nöjd med MPLAB och redan har min kod där för nästan hela projektet.
Projektet är som sagt en laptimer och kraven är som följande:
- Ta emot datan från GPSen som kommer i 10Hz
Parsa datan för att få fram positionen
Hålla koll på tiden
Hålla koll om jag passerat mållinjen
Skriva ut tiden på en LCD
Spara rådatan alternativt (endast varvtider om det skulle faila pga detta)
$PGTOP,11,2*6E <- Går tyvärr inte att få bort
$GPRMC,003022.099,V,,,,,0.00,0.00,060180,,,N*41 <- Saknar lite siffror pga att jag sitter inne
Nu har jag båda plattformarna så vad väljer jag att fortsätta med? Kan Arduinon fixa detta i 16MHz? Kan PICen klara det i 64? Eller ska jag skita i dessa o köra på en rasberry pi?
Re: USART arduino
De kriterier som du satt upp för ditt projekt (och som jag förstår dem) bör inte kräva någon "extremt" snabb uC. Skulle tro en "normal" 4MHz PIC eller 8MHz Arduino/Atmega skulle funka. Det enda som jag inte riktigt vet vad du menar med är "få fram positionen"? Skall positionsdatan konverteras till någon annan form (graf eller vektorbaserad) genom några komplicerade matematiska formler?
Jag tror mer det är "planering av kodexekveringen" som spelar roll i detta fall.
. Ta emot data 10ggr/s seriellt med 115200 baud borde inte vara något problem. Vet inte hur många tecken du måste ta emot för att få ut det du behöver dock, men jag antar att det är runt 100?
. Parsa datan och få fram positionen borde gå relativt fort (med en smart algoritm) beroende på hur du skall efterbehandla positionsdatan.
. Kolla tiden borde inte vara nåt problem.
. Hålla koll på om du passerat mållinjen. Vet inte vad du har för lösning för detta? Möjligt att detta kräver lite beräkningar beroende på hur du tacklar problemet.
. Skriva ut tiden på LCD. LCD är relativt långsamma. Tiderna kan skilja lite, men för en jag har tar det c.a. 40us att skriva ut ett tecken. Att "cleara" displayen tar 15ms. Det går fortare att skriva över med ny data än "tömma" skärmen.
. Spara rådatan. Beroende på vart du tänkt spara rådatan kan detta ta tid.
Det jag kan tänka mig gör det hela "skitsegt" är taskig parsing algoritm eller att du använder interrupt på fel sätt eller båda. Dock svårt att avgöra utan att ha sett koden.
Jag tror mer det är "planering av kodexekveringen" som spelar roll i detta fall.
. Ta emot data 10ggr/s seriellt med 115200 baud borde inte vara något problem. Vet inte hur många tecken du måste ta emot för att få ut det du behöver dock, men jag antar att det är runt 100?
. Parsa datan och få fram positionen borde gå relativt fort (med en smart algoritm) beroende på hur du skall efterbehandla positionsdatan.
. Kolla tiden borde inte vara nåt problem.
. Hålla koll på om du passerat mållinjen. Vet inte vad du har för lösning för detta? Möjligt att detta kräver lite beräkningar beroende på hur du tacklar problemet.
. Skriva ut tiden på LCD. LCD är relativt långsamma. Tiderna kan skilja lite, men för en jag har tar det c.a. 40us att skriva ut ett tecken. Att "cleara" displayen tar 15ms. Det går fortare att skriva över med ny data än "tömma" skärmen.
. Spara rådatan. Beroende på vart du tänkt spara rådatan kan detta ta tid.
Det jag kan tänka mig gör det hela "skitsegt" är taskig parsing algoritm eller att du använder interrupt på fel sätt eller båda. Dock svårt att avgöra utan att ha sett koden.
Re: USART arduino
Tack för bra svar!
-De kriterier som du satt upp för ditt projekt (och som jag förstår dem) bör inte kräva någon "extremt" snabb uC. Skulle tro en "normal" 4MHz PIC eller 8MHz Arduino/Atmega skulle funka. Det enda som jag inte riktigt vet vad du menar med är "få fram positionen"? Skall positionsdatan konverteras till någon annan form (graf eller vektorbaserad) genom några komplicerade matematiska formler?
Jag tror mer det är "planering av kodexekveringen" som spelar roll i detta fall.
Datan kommer som som en NMEA sträng och den innehåller positionen dock i ett tokigt format (sträng format istället för decimal) så jag måste ta och splitta upp strängen och välja de delar jag vill ha samt att konvertera de till rätt format. Så det är inget komplicerat.
. Ta emot data 10ggr/s seriellt med 115200 baud borde inte vara något problem. Vet inte hur många tecken du måste ta emot för att få ut det du behöver dock, men jag antar att det är runt 100?
Det är 80st per gång varav 16 tecken är antenn status($PGTOP) som jag inte bryr mig om. Antar att det bara finns fördelar med att köra 115200 istället för sig 9600?
. Hålla koll på om du passerat mållinjen. Vet inte vad du har för lösning för detta? Möjligt att detta kräver lite beräkningar beroende på hur du tacklar problemet.
Kommer inte ihåg exakt hur formeln såg ut men i grova drag så handlar det om att jag har 2 punkter vid mål och 2 punkter där jag har kört. Sen väljer jag tre punkter och hoppar jag igenom dom från en startpunkt och kollar så att jag inte byter håll. Sen går jag vidare till nästa startpunkt. Det finns några specialfall så den är inte jätteenkel men heller inte allt för komplicerad.
- Skriva ut tiden på LCD. LCD är relativt långsamma. Tiderna kan skilja lite, men för en jag har tar det c.a. 40us att skriva ut ett tecken. Att "cleara" displayen tar 15ms. Det går fortare att skriva över med ny data än "tömma" skärmen.
Går det att göra annat medans man skriver till en LCD?
- Spara rådatan. Beroende på vart du tänkt spara rådatan kan detta ta tid.
Tanken är att skicka ut den via SPI till nått SD kort (Arduino har ett lib och exempel för detta) eller ha ett eget flashminne som någon rekommenderade i min förra tråd.
- Det jag kan tänka mig gör det hela "skitsegt" är taskig parsing algoritm eller att du använder interrupt på fel sätt eller båda. Dock svårt att avgöra utan att ha sett koden.
Då tar jag och sätter igång och portar över min gamla kod till Arduinon!
-De kriterier som du satt upp för ditt projekt (och som jag förstår dem) bör inte kräva någon "extremt" snabb uC. Skulle tro en "normal" 4MHz PIC eller 8MHz Arduino/Atmega skulle funka. Det enda som jag inte riktigt vet vad du menar med är "få fram positionen"? Skall positionsdatan konverteras till någon annan form (graf eller vektorbaserad) genom några komplicerade matematiska formler?
Jag tror mer det är "planering av kodexekveringen" som spelar roll i detta fall.
Datan kommer som som en NMEA sträng och den innehåller positionen dock i ett tokigt format (sträng format istället för decimal) så jag måste ta och splitta upp strängen och välja de delar jag vill ha samt att konvertera de till rätt format. Så det är inget komplicerat.
. Ta emot data 10ggr/s seriellt med 115200 baud borde inte vara något problem. Vet inte hur många tecken du måste ta emot för att få ut det du behöver dock, men jag antar att det är runt 100?
Det är 80st per gång varav 16 tecken är antenn status($PGTOP) som jag inte bryr mig om. Antar att det bara finns fördelar med att köra 115200 istället för sig 9600?
. Hålla koll på om du passerat mållinjen. Vet inte vad du har för lösning för detta? Möjligt att detta kräver lite beräkningar beroende på hur du tacklar problemet.
Kommer inte ihåg exakt hur formeln såg ut men i grova drag så handlar det om att jag har 2 punkter vid mål och 2 punkter där jag har kört. Sen väljer jag tre punkter och hoppar jag igenom dom från en startpunkt och kollar så att jag inte byter håll. Sen går jag vidare till nästa startpunkt. Det finns några specialfall så den är inte jätteenkel men heller inte allt för komplicerad.
- Skriva ut tiden på LCD. LCD är relativt långsamma. Tiderna kan skilja lite, men för en jag har tar det c.a. 40us att skriva ut ett tecken. Att "cleara" displayen tar 15ms. Det går fortare att skriva över med ny data än "tömma" skärmen.
Går det att göra annat medans man skriver till en LCD?
- Spara rådatan. Beroende på vart du tänkt spara rådatan kan detta ta tid.
Tanken är att skicka ut den via SPI till nått SD kort (Arduino har ett lib och exempel för detta) eller ha ett eget flashminne som någon rekommenderade i min förra tråd.
- Det jag kan tänka mig gör det hela "skitsegt" är taskig parsing algoritm eller att du använder interrupt på fel sätt eller båda. Dock svårt att avgöra utan att ha sett koden.
Då tar jag och sätter igång och portar över min gamla kod till Arduinon!
Re: USART arduino
Lullen: "Sitter man och kikar på olika exempel med just gpsen så verkar alla köra software serial istället för hardware."
Och då är det ju hur fel som helst! Att många är dumma betyder inte att du behöver vara det också eller hur?
Du har såklart kollat att "alla andra" faktisk har två UART i deras µC - eller hur?
Detta var allvarligt talat sämste argument jag sett för detta - någonsin.
Fördelen med hög baudrate är att data överförs snabbare. Kör man soft-UART är detta av betydelse då alla interrupts och alla annan exekvering ju måste vara avstängd under tiden vilket betyder att en ökning från 9600 till 115200 ger 76,39ms extra att bearbeta data i per 80 byte paket.
Att omvandla från sträng till binärt är knappast ett problem, det är ju hur enkelt som helst!
Starta med en variabel som kan hålla det största tal som kan förekomma, kom ihåg förtecken!
Nolla denna variabel som startpunkt.
Sedan tar man varje tal i strängen som ska omvandlas, från mest betydande, och utför följande:
A: Multiplicera resultatet med 10. (finns ett snabbt sätt att göra detta på också)
B: Addera siffran - '0'.
Upprepa till alla siffror är inlästa.
Är det frågan om ett decimaltal kan man läsa in det som heltal och hålla koll på kommats position och såklart hoppa över detta i omvandlingen.
Och då är det ju hur fel som helst! Att många är dumma betyder inte att du behöver vara det också eller hur?
Du har såklart kollat att "alla andra" faktisk har två UART i deras µC - eller hur?
Detta var allvarligt talat sämste argument jag sett för detta - någonsin.
Fördelen med hög baudrate är att data överförs snabbare. Kör man soft-UART är detta av betydelse då alla interrupts och alla annan exekvering ju måste vara avstängd under tiden vilket betyder att en ökning från 9600 till 115200 ger 76,39ms extra att bearbeta data i per 80 byte paket.
Att omvandla från sträng till binärt är knappast ett problem, det är ju hur enkelt som helst!
Starta med en variabel som kan hålla det största tal som kan förekomma, kom ihåg förtecken!
Nolla denna variabel som startpunkt.
Sedan tar man varje tal i strängen som ska omvandlas, från mest betydande, och utför följande:
A: Multiplicera resultatet med 10. (finns ett snabbt sätt att göra detta på också)
B: Addera siffran - '0'.
Upprepa till alla siffror är inlästa.
Är det frågan om ett decimaltal kan man läsa in det som heltal och hålla koll på kommats position och såklart hoppa över detta i omvandlingen.
Re: USART arduino
. Det är 80st per gång varav 16 tecken är antenn status($PGTOP) som jag inte bryr mig om. Antar att det bara finns fördelar med att köra 115200 istället för sig 9600?
Det beror på hur störningsbenägen miljön är och hur långa sladdar du skall ha seriellt mellan uC och GPS. Du måste ju hursomhelst läsa data från GPSen tills du kommer till den del du vill ha, så det är inte säkert att du direkt får enbart de 80 tecken du vill ha. Detta gör att 9600 kan vara lite gränsfall eftersom du vill hämta 10 ggr per sekund så på 9600 baud får du c.a. 960 tecken per sekund / 10 = 96 tecken för varje iteration. Du får då inte mycket tid över till övrigt.
. Kommer inte ihåg exakt hur formeln såg ut men i grova drag så handlar det om att jag har 2 punkter vid mål och 2 punkter där jag har kört. Sen väljer jag tre punkter och hoppar jag igenom dom från en startpunkt och kollar så att jag inte byter håll. Sen går jag vidare till nästa startpunkt. Det finns några specialfall så den är inte jätteenkel men heller inte allt för komplicerad.
Med den informationen kan jag inte säga mycket. Använder du flyttal, heltal? Använder du komplicerade funktioner som t.ex sqrt(), sin(), cos(), rad(), tan()... ?
Om du använder flyttal så kommer beräkningarna ta betydligt längre tid. Använder du andra operatorer än +,-,* så tar det också betydligt längre tid. Division är mer tidskrävande än multiplikation t.ex. Om du använder sin/cos t.ex så är det (beroende på vilken precision du önskar) bättre att använda uppslagstabeller.
Tänk också på att om du använder 16 eller 32 bits integers på en 8 bits processor ökar beräkningstiden avsevärt.
Skulle rekommendera att du konverterar formlerna till att använda i första hand integers, plus, minus och multiplikation och uppslagstabeller så långt det går för att optimera beräkningarna.
. Går det att göra annat medans man skriver till en LCD?
En enkärnig microcontroller kan bara utföra en instruktion i taget. Däremot går det att försöka fixa det genom IRQ och buffrar. Vet inte om Arduinos LCD bibliotek sköter det på det viset eller om dom helt enkelt pullar ready biten eller kör blockerande delay-loop. det får du kolla upp själv. Annars får du skriva en egen LCD hantering. Väntar du 40us så innebär det att på en arduino/atmega på 16MHz eldar du upp 640 instruktionscykler på ingenting.
Du skriver dock inte hur många tecken du tänker skriva ut. Du måste ju naturligtvis väga om t.ex 800us för 20 tecken är acceptabelt i ditt fall. Det kanske inte är ett problem.
. Tanken är att skicka ut den via SPI till nått SD kort (Arduino har ett lib och exempel för detta) eller ha ett eget flashminne som någon rekommenderade i min förra tråd.
Flashminnen är inte direkt snabba. SD kort beror på hur du tänkt skriva data. Raw data direkt eller via FAT filsystem?
För att summera skulle jag tro att det är möjligt att fixa det du vill om man är en finurlig och tålmodig programmerare och har förståelse vad som tar tid och hur man optimerar kod och logistiskt bygger upp applikationen. Är man java programmerare och van vid 3GHz 64-bitars 4 kärniga intel/AMD och ointresserad av att optimera kod och gå ner på metallen så kanske man skall välja Raspberry Pi eller åtminstone en 16 eller 32 bits uC istället.
Det beror på hur störningsbenägen miljön är och hur långa sladdar du skall ha seriellt mellan uC och GPS. Du måste ju hursomhelst läsa data från GPSen tills du kommer till den del du vill ha, så det är inte säkert att du direkt får enbart de 80 tecken du vill ha. Detta gör att 9600 kan vara lite gränsfall eftersom du vill hämta 10 ggr per sekund så på 9600 baud får du c.a. 960 tecken per sekund / 10 = 96 tecken för varje iteration. Du får då inte mycket tid över till övrigt.
. Kommer inte ihåg exakt hur formeln såg ut men i grova drag så handlar det om att jag har 2 punkter vid mål och 2 punkter där jag har kört. Sen väljer jag tre punkter och hoppar jag igenom dom från en startpunkt och kollar så att jag inte byter håll. Sen går jag vidare till nästa startpunkt. Det finns några specialfall så den är inte jätteenkel men heller inte allt för komplicerad.
Med den informationen kan jag inte säga mycket. Använder du flyttal, heltal? Använder du komplicerade funktioner som t.ex sqrt(), sin(), cos(), rad(), tan()... ?
Om du använder flyttal så kommer beräkningarna ta betydligt längre tid. Använder du andra operatorer än +,-,* så tar det också betydligt längre tid. Division är mer tidskrävande än multiplikation t.ex. Om du använder sin/cos t.ex så är det (beroende på vilken precision du önskar) bättre att använda uppslagstabeller.
Tänk också på att om du använder 16 eller 32 bits integers på en 8 bits processor ökar beräkningstiden avsevärt.
Skulle rekommendera att du konverterar formlerna till att använda i första hand integers, plus, minus och multiplikation och uppslagstabeller så långt det går för att optimera beräkningarna.
. Går det att göra annat medans man skriver till en LCD?
En enkärnig microcontroller kan bara utföra en instruktion i taget. Däremot går det att försöka fixa det genom IRQ och buffrar. Vet inte om Arduinos LCD bibliotek sköter det på det viset eller om dom helt enkelt pullar ready biten eller kör blockerande delay-loop. det får du kolla upp själv. Annars får du skriva en egen LCD hantering. Väntar du 40us så innebär det att på en arduino/atmega på 16MHz eldar du upp 640 instruktionscykler på ingenting.
Du skriver dock inte hur många tecken du tänker skriva ut. Du måste ju naturligtvis väga om t.ex 800us för 20 tecken är acceptabelt i ditt fall. Det kanske inte är ett problem.
. Tanken är att skicka ut den via SPI till nått SD kort (Arduino har ett lib och exempel för detta) eller ha ett eget flashminne som någon rekommenderade i min förra tråd.
Flashminnen är inte direkt snabba. SD kort beror på hur du tänkt skriva data. Raw data direkt eller via FAT filsystem?
För att summera skulle jag tro att det är möjligt att fixa det du vill om man är en finurlig och tålmodig programmerare och har förståelse vad som tar tid och hur man optimerar kod och logistiskt bygger upp applikationen. Är man java programmerare och van vid 3GHz 64-bitars 4 kärniga intel/AMD och ointresserad av att optimera kod och gå ner på metallen så kanske man skall välja Raspberry Pi eller åtminstone en 16 eller 32 bits uC istället.
Re: USART arduino
-Är det frågan om ett decimaltal kan man läsa in det som heltal och hålla koll på kommats position och såklart hoppa över detta i omvandlingen.
Är det sådan stor vinst med heltal att det är värt att hålla reda på decimaltalen?
Min uträkning för att se om jag passerat mållinjen bygger på denna lösning:
http://www.geeksforgeeks.org/check-if-t ... intersect/
Detta samt parsningen är i princip det som ska göras hela tiden.
Ska kolla på om man kan optimera detta på något vis eller om det ens behövs. Nu är det ju kul o komma igång igen
-För att summera skulle jag tro att det är möjligt att fixa det du vill om man är en finurlig och tålmodig programmerare och har förståelse vad som tar tid och hur man optimerar kod och logistiskt bygger upp applikationen. Är man java programmerare och van vid 3GHz 64-bitars 4 kärniga intel/AMD och ointresserad av att optimera kod och gå ner på metallen så kanske man skall välja Raspberry Pi eller åtminstone en 16 eller 32 bits uC istället.
Det sammanfattar mig rätt bra fast jag gillar att optimera saker
Tack för alla svar, nu ikväll ska det kämpas så får vi se vart jag hamnar!
Är det sådan stor vinst med heltal att det är värt att hålla reda på decimaltalen?
Min uträkning för att se om jag passerat mållinjen bygger på denna lösning:
http://www.geeksforgeeks.org/check-if-t ... intersect/
Kod: Markera allt
För att få ut avståndet från mållinjen använder jag denna funktion. Där lat2/lon2 är punkten jag passerar mållinjen på.
Då det är på en raka så tar jag bara "fågelvägen" till den punkten från den jag är på.
double getDistance(double lat1, double lon1, double lat2, double lon2) {
double theta, dist;
theta = lon1 - lon2;
dist = sin(deg2rad(lat1)) * sin(deg2rad(lat2)) + cos(deg2rad(lat1)) * cos(deg2rad(lat2)) * cos(deg2rad(theta));
dist = acos(dist);
dist = rad2deg(dist);
dist = dist * 60 * 1.1515;
dist = dist * 1609.344;
return (dist);
}
Ska kolla på om man kan optimera detta på något vis eller om det ens behövs. Nu är det ju kul o komma igång igen
-För att summera skulle jag tro att det är möjligt att fixa det du vill om man är en finurlig och tålmodig programmerare och har förståelse vad som tar tid och hur man optimerar kod och logistiskt bygger upp applikationen. Är man java programmerare och van vid 3GHz 64-bitars 4 kärniga intel/AMD och ointresserad av att optimera kod och gå ner på metallen så kanske man skall välja Raspberry Pi eller åtminstone en 16 eller 32 bits uC istället.
Det sammanfattar mig rätt bra fast jag gillar att optimera saker
Tack för alla svar, nu ikväll ska det kämpas så får vi se vart jag hamnar!
