Bruk i pointer med jump

[Enthroner]

"Alt dette ønsker jeg å avlaste mikrokontrolleren hvis mulig sånn at mikrokontrolleren har mer regnekraft til andre ting, f.eks terminal med 20 linjer og 32 bokstaver med sånne monochrome bokstaver."

Mitt tips er å tenke helt motsatt.

 

Bruk mikrokontrolleren til å ta i mot DataRef endringer og send endringene til relevant kontroll. Hver kontroll burde derfor også være smarte nok til å håndtere seg selv. For en slik dotmatrix finnes det f.eks http://playground.arduino.cc/Main/LedControl for MAX72xx.

 

Men vi har hver vår smak og måte vi liker å tenke og gjøre ting på.

Jeg er tilhenger av Keep It Simple Stupid og ville laget meg en liten python plugin som sendte data seriellt med 115200 baud. I python koden kunne du også oppdatert de forskjellige instrumentene i ulike intevaller (noen 20 ganger i sekundet, andre hvert 5. sekund alt ettersom hva du selv synes er OK).

 

Lager du din egen plugin står du fri til å gjøre hva du vil. Jeg foreslår at du gjør det enkelt her også, og sender en byte for å indikere hvilket instrument det er, etterfult av fire bytes for å representere float verdien til DateRef-en. Det er 5 bytes per instrument.

Da tar det 5 * 12 / 115200 = 0.5ms å overføre en DataRef, som betyr at du kan sende 1 / (5 * 12 / 115200) = 1920 slike pakker i sekundet. Burde holde det?

På arduinosiden har du fortsatt god tid mellom hver gang Serial.available()>=5 intreffer, og når den intreffer skal du bare finne ut hva første byte er, slik at du vet hvilket instrument, deretter sende data til devicen som representerer det instrumentet (kan jo selvsagt også bare være en LED på en pinne).

Men nå er vi tilbake på den første eksempelkoden jeg skrev til deg.

 

EDIT: Et annet interessant alternativ er å bruke UDP/ethernet, da kan du bruke Data Input / Output siden fra X-Plane uten noe annen jobb enn å sette IP og selvsagt parse UDP pakkene.

Endret 23. februar 2016 av Enthroner

[Gjest medlem-401307]

"Alt dette ønsker jeg å avlaste mikrokontrolleren hvis mulig sånn at mikrokontrolleren har mer regnekraft til andre ting, f.eks terminal med 20 linjer og 32 bokstaver med sånne monochrome bokstaver."

Mitt tips er å tenke helt motsatt.

 

Bruk mikrokontrolleren til å ta i mot DataRef endringer og send endringene til relevant kontroll. Hver kontroll burde derfor også være smarte nok til å håndtere seg selv. For en slik dotmatrix finnes det f.eks http://playground.arduino.cc/Main/LedControl for MAX72xx.

 

Men vi har hver vår smak og måte vi liker å tenke og gjøre ting på.

Jeg er tilhenger av Keep It Simple Stupid og ville laget meg en liten python plugin som sendte data seriellt med 115200 baud. I python koden kunne du også oppdatert de forskjellige instrumentene i ulike intevaller (noen 20 ganger i sekundet, andre hvert 5. sekund alt ettersom hva du selv synes er OK).

 

Lager du din egen plugin står du fri til å gjøre hva du vil. Jeg foreslår at du gjør det enkelt her også, og sender en byte for å indikere hvilket instrument det er, etterfult av fire bytes for å representere float verdien til DateRef-en. Det er 5 bytes per instrument.

Da tar det 5 * 12 / 115200 = 0.5ms å overføre en DataRef, som betyr at du kan sende 1 / (5 * 12 / 115200) = 1920 slike pakker i sekundet. Burde holde det?

 

På arduinosiden har du fortsatt god tid mellom hver gang Serial.available()>=5 intreffer, og når den intreffer skal du bare finne ut hva første byte er, slik at du vet hvilket instrument, deretter sende data til devicen som representerer det instrumentet (kan jo selvsagt også bare være en LED på en pinne).

Men nå er vi tilbake på den første eksempelkoden jeg skrev til deg.

 

EDIT: Et annet interessant alternativ er å bruke UDP/ethernet, da kan du bruke Data Input / Output siden fra X-Plane uten noe annen jobb enn å sette IP og selvsagt parse UDP pakkene.

Du nevnte 5 bytes * 12 instrumenter / 115200 baud, men jeg skal lage 100 analoge instrumenter, og 100 LEDs, 100 toggle switches, 50 knapper.

La oss regne ut litt.

1 stk analog instrument tar 16-bits for oppløsning for da blir det 2 bytes. 2 * 100 = 200 bytes.

100 LEDs tar 7*7 bits, da blir det jo nærmest 2 bytes.

200 toggle switches tar enten 25 bytes eller 50 bytes hvis begge sider skal leses.

Så 30 knapper som er nærmest 32 som blir 4 bytes.

 

Nå skal vi regne ut alle bytes: 200 + 2 + 50 + 4 = 256 bytes eller 456 bytes hvis float. Så 256 eller 456 * 8 for å regne ut i baud, da blir det 2048 eller 3648.

Så 115200 / 2048 = 56.25 frames per second eller 31,6. Så del det på to for inngang og utgang, da blir det 28.125 eller 15,8.  Jeg antar at Arduinoen har god tid mellom I/O, så det blir mindre krav til baudrate hvis jeg lar Arduino ta seg av noen input, evt balansere baud og arduino regnekraft 16 MHz/16 MIPS. En instruksjon er ca 1 byte, så det er ca 1.6mb per sekund i kun 8 bits data, men mindre hvis 16-bits, så jeg antar med 16-bits i 8-bits mikrokontroller så er det kanskje 600 kb per sekund fordi CPU i mikrokontroller er 8-bits.

 

Jeg tenkte å la arduino kalkulere seg av noen elementer som f.eks fuel flow selv om simulator gjør det, amperemålene, fuel dump, navigasjon med input til simulator når flyet skal flytte til høyre eller til venstre. I denne flyet har autopiloten ikke kontroll over høyde som i de nyeste flyene der FMS har kontroll over nedstigning og oppstigning. Dvs, autopilot har bare kontroll over høyre og venstre, fartskontroll, høydestabiliator.

La meg si noe om X-Plane simulator's autopilot håndtering, den er meget dårlig. Når jeg aktiverer autopilot, så vingler den alltid som en slange beveger seg i loddrett og vannrett, bortsett hvis svært høy høyde, så blir den tilsynelatende stabil. Så derfor må jeg la Arduino ta seg av autopilot. I X-Plane SDK er det mulig å overstyre flyet manuelt, det er derfor joystick, slew mode, og plugin eksisterer.

Endret 24. februar 2016 av medlem-401307

[Enthroner]

Du misforstod meg du kan oppdatere 1920 instrumenter i sekundet. Siden du har 350 devicer, kan du oppdatere hver av de 5.4 ganger i sekundet.

 

EDIT: tallet 12 kommer av at hver byte trenger start  parity 2 x stop bits. Så en byte (eller fem som du trenger) bruker 5 * 12 bits på faktisk overføring, og må brukes i videre kalkulasjon mot baud.

Endret 24. februar 2016 av Enthroner

[Gjest medlem-401307]

Du misforstod meg du kan oppdatere 1920 instrumenter i sekundet. Siden du har 350 devicer, kan du oppdatere hver av de 5.4 ganger i sekundet.

 

EDIT: tallet 12 kommer av at hver byte trenger start  parity 2 x stop bits. Så en byte (eller fem som du trenger) bruker 5 * 12 bits på faktisk overføring, og må brukes i videre kalkulasjon mot baud.

5.4 ganger i sekundet er for lite, jeg trenger minst 25 fordi x-plane 10 motoren oppdaterer seg 20 så jeg tar med 5 mer for sikkerhets skyld.

Så det er bedre med få verdier i baud overføring og la MEGA2560 regne ut noen regnekraft som den har til overs som jeg nevnte.

Endret 24. februar 2016 av medlem-401307

[Enthroner]

Du har mulighet til å sende 1920 pakker i sekundet. Jeg ordla meg feil da jeg sa instrumenter.

Såklart må man sende bare det som endres, både fra PC og fra Arduino!

 

Jeg klarer ikke skjønne hvorfor du vil regne ut ting SIM allerede regner ut...

 

Dog, å lage egen autopilot er en artig challenge

Endret 24. februar 2016 av Enthroner

[Gjest medlem-401307]

Du har mulighet til å sende 1920 pakker i sekundet. Jeg ordla meg feil da jeg sa instrumenter.

Såklart må man sende bare det som endres, både fra PC og fra Arduino!

 

Jeg klarer ikke skjønne hvorfor du vil regne ut ting SIM allerede regner ut...

 

Dog, å lage egen autopilot er en artig challenge

Joda, jeg vet at sim allerede regner ut men jeg vil redusere avhengighet av baud rate.

Hvordan er det en mulighet å sende 1920 pakker i sekundet, men del det med 25 frames, da blir det jo bare 76,8 enheter per sekund. Men reduser til ekstra character som detekterer hvilken pakke det er, så blir det kraftig redusert. Hvis jeg bruker f.eks 4 character. For eksempel hdg0, hdg1, mag0, spd0, mach, alt0, fpm0, etc så blir det bare ca 15 frames per sekund å bruke baud til. Du sier 1920 ganger i sekundet, men jeg trenger 1920 * 5 for 25 frames, så multiplisere omtrent 4 for character, da blir det 38400 pakker i sekundet. Det er hva jeg egentlig prøver å si; så er jeg fornøyd hvis mulig 38400 men jeg må klare meg med omtrent 384 i mot 38400, det er 100 ganger mindre. Derfor må jeg være kreative.

Endret 24. februar 2016 av medlem-401307

[Enthroner]

Tenk enkelt

Du trenger ikke i nærheten av 1920 pakker. En pakke er 5 fordi du har en byte til å si hvilket instrument det er, så fire bytes for å indikere hvilken float verdi pakken (DataRefen, evnt gir det deg mulighet til å packe verdier for 4*8 leds i en pakke f.eks om du virkelig må det) har.

 

 

Baud er ikke problemet. Bare konsentrer om å lage logikk på PCn som sender det som endrer seg, så kan du raskt se at det ikke er så mye som du antakelig tror. Trenger du å packe ting er det alltids rom for det senere i prosjektet, men start så enkelt som mulig.

Tenk enkelt.

 

Tenk enkelt. Bruk data fra SIM der du kan.

Det er rett og slett det jeg kan si om saken.

 

PS: Post video hvis du lager "hardware accelerated auto pilot", det er en kul ting i seg selv

[Gjest medlem-401307]

Tenk enkelt

Du trenger ikke i nærheten av 1920 pakker. En pakke er 5 fordi du har en byte til å si hvilket instrument det er, så fire bytes for å indikere hvilken float verdi pakken (DataRefen, evnt gir det deg mulighet til å packe verdier for 4*8 leds i en pakke f.eks om du virkelig må det) har.

 

 

Baud er ikke problemet. Bare konsentrer om å lage logikk på PCn som sender det som endrer seg, så kan du raskt se at det ikke er så mye som du antakelig tror. Trenger du å packe ting er det alltids rom for det senere i prosjektet, men start så enkelt som mulig.

Tenk enkelt.

 

Tenk enkelt. Bruk data fra SIM der du kan.

Det er rett og slett det jeg kan si om saken.

 

PS: Post video hvis du lager "hardware accelerated auto pilot", det er en kul ting i seg selv

Du nevnte hardware accelerated autopilot... Det blir kanskje vrient, men teknisk mulig, men ikke med sånn mikrokontroller men mulig med mikroprosessor f.eks https://www.elfadistrelec.no/en/microprocessor-dil-40-zilog-z84c0008peg/p/17329840?q=*&sort=Price:asc&filter_Category3=Digital+Circuits+%2F+Development+Tools&filter_Category4=Processors&filter_Function=CPU&filter_Buyable=1&page=1&origPageSize=25&simi=99.8

Så det med der er mulig for med logic flip flop i hvert eneste byte; så, kan jeg ha direkte tilgang til pinner Med ledninger og logikk enheter så er det mulig men foreløpig altfor avansert.

[Enthroner]

µCUen din i Arduino er 2-4 ganger raskere pga instruksjonssett og klokken

 

RE Autopilot: Det var du som snakket om at software AP var så dårlig, og at du ville ha arduino til å styre den Det er en morsom addon til cockpiten din.

 

Meeen igjen. Start med noe trivielt og bygg ut i fra det. Tenk enkelt.

[Gjest medlem-401307]

µCUen din i Arduino er 2-4 ganger raskere pga instruksjonssett og klokken

 

RE Autopilot: Det var du som snakket om at software AP var så dårlig, og at du ville ha arduino til å styre den Det er en morsom addon til cockpiten din.

 

Meeen igjen. Start med noe trivielt og bygg ut i fra det. Tenk enkelt.

OK.

 

Ja, software AP i X-Plane 10 simulator duger nesten ingenting. For meg ser det ut at det er enklere å la Arduino styre enn en plugin til X-Plane som kan kommunisere mellom Arduino og X-Plane 10 SDK. Men med default flyene som følger med X-Plane 10 er god. Arduino bør klare å styre autopilot i X-Plane 10 med Software Development Kit.

Ja, jeg skal først bygge noe enkelt, jeg tenkte på fuel tank indikator, den består av 5-7 8cm instrumenter med 2 nål hver .

Autopiloten får vente.

 

For en stund siden ga jeg min mob.nr til en romansk dame tigger, ca 27 år gammel og ville se hva som skjedde fordi jeg var litt interessert, nettopp fant jeg ut at jeg skulle treffe hennes søster men så en mann i en bil som er antakeligvis bakmann. Heldigvis merket han ikke meg i det hele tatt og jeg stakk og avviste all anrop og SMS i søppelnr.