Akustiska måltavlor

[Fält]

Sius ursprungliga lösning med kretsschema: https://patents.google.com/patent/USRE32123E/en
Dessutom flödesscheman för logiken

Verkar vara byggd med en analog frontend/mätkedja som filtrerar signalen och tar hand om dess dynamiska range.

Det här är allts från 1977, men de analoga filtren är fortfarande användbara.

Bra googlat! Och vilket ovanligt detaljerat patent. Det märks att det har några år på nacken; är från den tiden då man inte patenterade vad skit som helst.

Jag håller med, bra googlat!

Angående patentet , sjukt detaljerat. Lägg sedan till att pdf filen är OCRad och sökbar!

Jag har skummat genom den och får en känsla av att det finns en del i den som kan förhindra att något biter oss i häcken. Tex om vi behöver kompensera för något.

Signalkoniditioneringen de gör har jag inte tittat på ännu då det inte känns som om vi är riktigt där ännu. Men någon dag kommer det ske.

[Fält]

1.
Interrupter tycks vara lite svårare än jag trodde på alla plattformar. I en ATMega så vet jag att det är lite långsamt då processorn är långsam, men jag var övertygad om att de enormt mycket snabbare processorerna skulle lösa det. Nu verkar det inte vara fallet då de istället har ineffektiv interrupthantering i en del miljöer, tex ESP32. Det går givetvis att optimera med avancerad programmering.

2.
Input captures går att lösa med rätt ATMega (2560), enligt det exempel som jag snodde ihop (Bokstavligen!). Det är inte riktigt klart ännu, men det som är kvar att göra är att ta hand om när räknaren hinner slå över mellan att mikrofonerna triggar. Det är enkelt. Men skall vi mäta på det här sättet och tycker att det är ok att använda en ATMega 2560 baserad Arduino så skriver jag koden för det. Synkronisering av de fyra klockorna tycks inte vara ett problem, de går att stoppa, Nollställa och starta. Med reservation för att jag missat något vitalt och inte vet vad jag sysslar med.

3.
Men det finns ett tredje sätt som kanske inte är så elegant. Men det har en del fördelar. Om en Arduino med alla interrupt avstängda hela tiden kontrollerar status på pinnarna och sparar tiden när det sker något så kommer det att gå ganska snabbt. Då koden är linjär så går det till viss del att kompensera för tiden det tar att köra instruktionerna, det gör att metoden kan bli ganska exakt.

Men vilkoret är att interrupts är avstängda då vilken interrupt som helst gör kontrollen av pinnarnas status avbryts.

Det innebär att man inte kan skriva något till serieporten eller till någon display utan att det försämrar mätnogrannheten. Men när man gjort tidsmätningarna så kan man göra annat, som att räkna fram var träffen sitter och presentera resultat. Så länge bara en skytt skjuter på tavlan så tror jag att vi kan räkna med att ha minst 0.1s på oss utan att det sätter några begränsningar för skyttet.

Så till det som jag vill fråga om. Ser någon ett problem med att ha en processor som i stort sätt bara sköter mätningen, men inte någon presentation direkt till skytten?

Under testperioden så går det att ha presentation i den eftersom vi under testförhållanden kan acceptera att vi bara kan skjuta när enheten är redo.

En av metodens fördelar är att jag tror att vi kan ha flera triggernivåer för en mikrofon. Så vi kan spara tiden när nivån når 0.1, 0.5, 1v, 2v och så vidare. Sedan kan vi välja rätt triggernivå i efterskott baserat på vad den högsta nivån är och även vad de andra mikrofonerna triggat på. Det går också att använda fler mikrofoner.

[lasse-a]

2.
Input captures går att lösa med rätt ATMega (2560), enligt det exempel som jag snodde ihop (Bokstavligen!). Det är inte riktigt klart ännu, men det som är kvar att göra är att ta hand om när räknaren hinner slå över mellan att mikrofonerna triggar. Det är enkelt. Men skall vi mäta på det här sättet och tycker att det är ok att använda en ATMega 2560 baserad Arduino så skriver jag koden för det. Synkronisering av de fyra klockorna tycks inte vara ett problem, de går att stoppa, Nollställa och starta. Med reservation för att jag missat något vitalt och inte vet vad jag sysslar med.

Fråga: Hur blir det med tidsmätningen på den? (Jag har den inte i huvudet). Atmels AVR-familj har (ju) bara 16 bitars räknare, så för att kunna mäta tillräckligt lång tid så har man satt ett "timer0 overflow" interrupt som slår när räknaren är full. I den rutinen så ökar man en annan räknare, samt nollställer timer0. På det sättet så kan man mäta mycket längre tider (längre än vi behöver) utan att ha en för stor räknare.

MEN, när jag prövade så visade det sig att timer0 overflow ISR:en tog ganska lång tid, så med jämna mellanrum så har man avbrotten avstängda under ganska lång tid. Vilket ger opålitlig tidsmätning av externa avbrott som blockeras under timer0 overflow-hanteringen.

Det går naturligtvis att slå av "overflow" avbrottet, men då får man göra sin egen hantering av tidsräknandet.

3.
Men det finns ett tredje sätt som kanske inte är så elegant. Men det har en del fördelar. Om en Arduino med alla interrupt avstängda hela tiden kontrollerar status på pinnarna och sparar tiden när det sker något så kommer det att gå ganska snabbt. Då koden är linjär så går det till viss del att kompensera för tiden det tar att köra instruktionerna, det gör att metoden kan bli ganska exakt.

Men vilkoret är att interrupts är avstängda då vilken interrupt som helst gör kontrollen av pinnarnas status avbryts.

Det innebär att man inte kan skriva något till serieporten eller till någon display utan att det försämrar mätnogrannheten. Men när man gjort tidsmätningarna så kan man göra annat, som att räkna fram var träffen sitter och presentera resultat. Så länge bara en skytt skjuter på tavlan så tror jag att vi kan räkna med att ha minst 0.1s på oss utan att det sätter några begränsningar för skyttet.

Så till det som jag vill fråga om. Ser någon ett problem med att ha en processor som i stort sätt bara sköter mätningen, men inte någon presentation direkt till skytten?

Nej, det är väl en alldeles utmärkt idé. Det är ofta så man gör i lite större system idag, dvs låter en dedicerad processor/SoC sköta en ganska begränsad uppgift och sedan bara rapportera till resten av systemet. (Tom JAS har gått över till det nu i E/F-modellen! ) Fördelen med moderna "jelly bean" SoC:ar är ju att de är så billiga att man inte behöver utnyttja dem till max i alla lägen.

Men man måste hantera avsaknaden av timer0 overflow hanteringen även i det fallet.

[lone_wolf]

En variant på SoC är ju FPGAn som nämdes tidigare. Det som behövs är 3 timers som klockas och nollställs synkront samt en externa ingångar som stoppar var och en separat.

Overflow är lätt att hantera bara timern är längre än den längsta fördröjning man behöver mäta. Man kollar bara i efterskott om man fick overflow med följande pseudokod

Kod: Markera allt

X = timer1
Y = timer2
Z = timer3  /* trigger timer */

x_diff = ABS( X-Z) /* x_diff should be signed long or float */
'
IF X < Z THEN
  IF x_diff > "maximum plausible time diff" THEN
    x_diff = X+ " max timer timer counter value"  - Z
  END
ELSE /* Z arrived earlier than X */
  IF  x_diff > "maximum plausible time diff" THEN
    x_diff = X- " max timer timer counter value"  + Z
  END
END
  

osv

ovanstående kan förenklas, men nu lite omständigt för att förklara iden.

[Fält]

2.
Input captures går att lösa med rätt ATMega (2560), enligt det exempel som jag snodde ihop (Bokstavligen!). Det är inte riktigt klart ännu, men det som är kvar att göra är att ta hand om när räknaren hinner slå över mellan att mikrofonerna triggar. Det är enkelt. Men skall vi mäta på det här sättet och tycker att det är ok att använda en ATMega 2560 baserad Arduino så skriver jag koden för det. Synkronisering av de fyra klockorna tycks inte vara ett problem, de går att stoppa, Nollställa och starta. Med reservation för att jag missat något vitalt och inte vet vad jag sysslar med.

Fråga: Hur blir det med tidsmätningen på den? (Jag har den inte i huvudet). Atmels AVR-familj har (ju) bara 16 bitars räknare, så för att kunna mäta tillräckligt lång tid så har man satt ett "timer0 overflow" interrupt som slår när räknaren är full. I den rutinen så ökar man en annan räknare, samt nollställer timer0. På det sättet så kan man mäta mycket längre tider (längre än vi behöver) utan att ha en för stor räknare.

Angående metod2:
Precis som lonewolf säger så är overflow hanterbart i efterskott så länge som mätintervallen är kortare än den tid det tar för timern att slå över. Vi har mycket goda marginaler här.

Timer overflow interrupt är dessutom inte ett så stort problem när man använder input captures. Det enda vi måste hinna med är att gå in och spara tiden på ett säkrare ställe innan nästa puls kommer och Input Capture lagrar en ny tid på samma ställe. Att hålla reda på timer overflow gör det lättare att detektera fel som orealistiska mätvärden på grund av falsktrigg eller att ett skott inte triggat en av mikrofonerna.

Engående metod 3:
Om vi enligt metod 3 låter bli input captures och interrupts så är overflow hanteringen också enkel.

Timer overflow flaggan (som är det som triggar interrupten) fungerar även när interrupter inte är aktiverade för overflow. Så något i still med pseudokoden nedan:
if (TOV1)
{
overflowcounter++;
TOV1=0;
}

En input capture kan köras utan interrupts också, då smyger sig värdet in i bakgrunden under tiden som man gör annat. Så input captures är en fördel även med metod3.

[lasse-a]

En variant på SoC är ju FPGAn som nämdes tidigare. Det som behövs är 3 timers som klockas och nollställs synkront samt en externa ingångar som stoppar var och en separat.

Ja, det räcker som sagt med en (liten) CPLD. Det är nästan inget som skall göras. Det går som sagt tom bra att implementera med lös logik. Det blir 3-4 kapslar per kanal. (Se exv. mina kronograf-trådar.)

Overflow är lätt att hantera bara timern är längre än den längsta fördröjning man behöver mäta. Man kollar bara i efterskott om man fick overflow med följande pseudokod

Jo, men det måste som sagt göras "manuellt" som du visar. Man kan inte förlita sig på färdiga funktioner i exv. Arduinons API.

(Det behöver egentligen ändå göras, men med tillräckligt stora räknarregister så kan man i de flesta fall ignorera det. Anläggningen är inte i drift tillräcklig länge för att det skall kunna bli ett problem. Man kan nollställa vid varje skott. Pss. som mitt fusk med att inte stänga av avbrotten tidigare; om man inte skjuter nästa skott förrän man hunnit läsa resultatet från det förra så kommer det inte att bli ett problem, människor är långsamma...

Och inte alltid sanningsenliga. Se exv. kommentarerna i koden för Apollo kommandokapseln :

Kod: Markera allt

P63SPOT3	CA	BIT6			# IS THE LR ANTENNA IN POSITION 1 YET
		EXTEND
		RAND	CHAN33
		EXTEND
		BZF	P63SPOT4		# BRANCH IF ANTENNA ALREADY IN POSITION 1

		CAF	CODE500		# ASTRONAUT:	PLEASE CRANK THE
		TC	BANKCALL		#			SILLY THING AROUND
		CADR	GOPERF1
		TCF	GOTOP00H	# TERMINATE
		TCF	P63SPOT3		# PROCEED	SEE IF HE'S LYING

P63SPOT4	TC	BANKCALL		# ENTER		INITIALIZE LANDING RADAR
		CADR	SETPOS1

		TC	POSTJUMP	# OFF TO SEE THE WIZARD ...
		CADR	BURNBABY

[lasse-a]

Angående metod2:
Precis som lonewolf säger så är overflow hanterbart i efterskott så länge som mätintervallen är kortare än den tid det tar för timern att slå över. Vi har mycket goda marginaler här.

Timer overflow interrupt är dessutom inte ett så stort problem när man använder input captures. Det enda vi måste hinna med är att gå in och spara tiden på ett säkrare ställe innan nästa puls kommer och Input Capture lagrar en ny tid på samma ställe. Att hålla reda på timer overflow gör det lättare att detektera fel som orealistiska mätvärden på grund av falsktrigg eller att ett skott inte triggat en av mikrofonerna.

Engående metod 3:
Om vi enligt metod 3 låter bli input captures och interrupts så är overflow hanteringen också enkel.

Timer overflow flaggan (som är det som triggar interrupten) fungerar även när interrupter inte är aktiverade för overflow. Så något i still med pseudokoden nedan:
if (TOV1)
{
overflowcounter++;
TOV1=0;
}

En input capture kan köras utan interrupts också, då smyger sig värdet in i bakgrunden under tiden som man gör annat. Så input captures är en fördel även med metod3.

Dåså. Men man måste ändå stänga av det om man inte vill nollställa de globala räknarna hela tiden. Det kör i bakgrunden oavsett vad man gör för övrigt. Jag fick som sagt problem med det även när jag körde input capture.

Men om man stänger av och nollställer (intressant att overflow-flaggan triggade ändå, det är ju självklart när jag tänker efter men så djupt har jag inte botaniserat i databladet) så blir det ju hanterbart. Men mycket av resten av Arduino ("Wiring") abstraktionen lär sluta fungera då så skall man basera på det, så får man hålla tungan lite rätt i munnen.

[Fält]

Dåså. Men man måste ändå stänga av det om man inte vill nollställa de globala räknarna hela tiden. Det kör i bakgrunden oavsett vad man gör för övrigt. Jag fick som sagt problem med det även när jag körde input capture.

Jag förstod inte vad du syftade på. Räknarna går ju 0-65535 hela tiden, när de når toppen så slår de över från 65535 till 0. Varje gång de nollställs så sätts TOVx flaggan för den aktuella räknaren. Det är inget beteende som jag vill ändra. Vi vill aldrig nollställa räknarna själva, förutom när vi kör igång dem och synkroniserar dem när systemet startar.

Vi förlitar oss istället på att ett värde på 10000 antagligen är senare än ett på 500 och att ett värde på 500 är senare än ett värde på 65000. Det blir ganska tryggt i sig, men om man också tittar på TOVx flaggan för den aktuella räknaren så kan man vara säker på om tex 32768 är före eller efter 32768, eller om det är exakt samtidigt.

Input captures kan som sagt dubbeltrigga, skickar man in ett snabbt pulståg på ingången så kommer värdet att ha uppdaterats flera gånger från innan man låser värdet genom att spara det på en annan plats.

Men om man stänger av och nollställer (intressant att overflow-flaggan triggade ändå, det är ju självklart när jag tänker efter men så djupt har jag inte botaniserat i databladet) så blir det ju hanterbart. Men mycket av resten av Arduino ("Wiring") abstraktionen lär sluta fungera då så skall man basera på det, så får man hålla tungan lite rätt i munnen.

Enstaka extra funktioner i Arduino använder timer1. Tex tror jag att RC servo funktionerna gör det. Men det är undantag.
Timer0 och kanske timer2 tror jag att vi skall låta bli. Det är lätt då de inte erbjuder några funktioner som vi vill använda för timing. Arduino använder tex timer0 för micros() så det blir dåligt att göra något med timer0.

[lone_wolf]

Man kan ju hantera interrupt latency så att man alltid drar av beräknad fördröjning. Den verkar vara ganska statiskt 20uS enligt den här https://www.youtube.com/watch?v=k7MlEgnlfak

20 uS är ganska lång tid. Prosessorn eget datablad säger 4 klockcykler (4 uS med 1MHz klocka). Skillnaden som man får i videon beror troligen på någon extra kodbyte som kompilator sätter in + koden för att sätta utgången till 1.

EDIT: I skälva verket så kanske det inte ens är ett problem om koden bygger på successiva läsningar av uS timern och därefter differenser. Om alla läsningar är fördröjda lika mycket så kommer det inte att inverka på differenserna.

[lasse-a]

Jag förstod inte vad du syftade på. Räknarna går ju 0-65535 hela tiden, när de når toppen så slår de över från 65535 till 0. Varje gång de nollställs så sätts TOVx flaggan för den aktuella räknaren. Det är inget beteende som jag vill ändra. Vi vill aldrig nollställa räknarna själva, förutom när vi kör igång dem och synkroniserar dem när systemet startar.

Vi förlitar oss istället på att ett värde på 10000 antagligen är senare än ett på 500 och att ett värde på 500 är senare än ett värde på 65000. Det blir ganska tryggt i sig, men om man också tittar på TOVx flaggan för den aktuella räknaren så kan man vara säker på om tex 32768 är före eller efter 32768, eller om det är exakt samtidigt.

[...]

Enstaka extra funktioner i Arduino använder timer1. Tex tror jag att RC servo funktionerna gör det. Men det är undantag.
Timer0 och kanske timer2 tror jag att vi skall låta bli. Det är lätt då de inte erbjuder några funktioner som vi vill använda för timing. Arduino använder tex timer0 för micros() så det blir dåligt att göra något med timer0.

Japp. Men jag hade som sagt problem med att ISR:en som uppdaterar Arduinons uppfattning om tiden (som slår vid timer overflow) den blockerar avbrott så länge att man missar även vid input captures. Och om man stänger av den för timer0 så pajjar t ex micros(). Då måste man göra det på något annat sätt.

Men jag måste erkänna att jag inte kommer ihåg detaljerna nu, utan går efter mina anteckningar från innan jag bestämde mig att bygga allt i HW direkt istället.


DOCK, ett lite annat spår. Jag kom på att det ju kommit en ny spelare på marknaden med intressanta features. Raspberry Pi Pico, som bygger på Raspberrys egna SoC. (Tvåkärnig ARM-Cortex M0+ 133MHz, 2MB flash och 264KB RAM. 26 GPIO pinnar, tre ADC:er om 12 bitar)

Den har programmerbara tillståndsmaskiner som är till för IO och de är blixtsnabba. Man kan läsa parallella bitströmmar och föra över dem till minne mha DMA i full systemhastighet, dvs 125MHz. Man kan även starta dem baserat på en extern signal (exv. level-change).

I dokumentationen så finns ett exempel på en logikanalysator som borde gå att anpassa till den här tillämpningen rakt av. (Jag har ännu inte lyckats läsa mig till om det går att få ett räknarvärde sparat istället, men det är inte omöjligt).

Här är exemplet: https://datasheets.raspberrypi.org/pico ... _c_sdk.pdf sektion 3.2.3 s. 44

Man får en dylik för för 49:- från ElectroKit här i Sverige: https://www.electrokit.com/produkt/raspberry-pi-pico/ och eftersom det är Raspberry Pi så är det original-HW, och mycket väl dokumenterat (samt stor community).

Jag har lekt lite med dem, men egentligen inte satt mig in i vad de kan göra. Jag får dock känslan att bättre än så här för den här tillämpningen blir det nog inte i enkelt och billigt tillgänglig hårdvara.

[lasse-a]

Man kan ju hantera interrupt latency så att man alltid drar av beräknad fördröjning. Den verkar vara ganska statiskt 20uS enligt den här https://www.youtube.com/watch?v=k7MlEgnlfak

20 uS är ganska lång tid. Prosessorn eget datablad säger 4 klockcykler (4 uS med 1MHz klocka). Skillnaden som man får i videon beror troligen på någon extra kodbyte som kompilator sätter in + koden för att sätta utgången till 1.

EDIT: I skälva verket så kanske det inte ens är ett problem om koden bygger på successiva läsningar av uS timern och därefter differenser. Om alla läsningar är fördröjda lika mycket så kommer det inte att inverka på differenserna.

Japp, det blir extra eftersom latensen inte räknar med undansparningen av register osv. som också behövs innan ISR:en kan exekvera. De fyra klockcyklerna är bara den maximala längden på en instruktion CPUn, avbrottet slår ju inte förrän den förra instruktionen är avslutad. Den kortaste instruktionen är fö en cykel, så själva avbrottslatensen är tyvärr variabel mellan en och fyra cykler. Men resten är som du säger statisk, och det kan man ta höjd för.

När jag skulle göra det tidigare så lyckades jag dock aldrig. Det var alltid något annat avbrott som drog först och blockerade vårt capture avbrott (eller vilket avbrott det nu må vara) tillräckligt länge för att det skulle bli mycket större variabilitet.

Så jag fick ingen rak kurva där jag kunde räkna ut min tomgångstid. Istället gav jag upp och byggde lös logik. Jag hade dock tightare timing-krav än här.

MEN, jag tror som sagt nu på byte av plattform till Raspberry Pi Pico. Den tror jag klarar det här galant och med mer noggrannhet än vad vi någonsin behöver.

[detstorabla]

Så jag har börjat med att implementera lite enkel logik. Jag har i nuläget fokuserat på själva konceptet och har inte alls hunnit verifiera allt. Men grunden verkar iallafall fungera när jag simulerar.
Så förutom klocka och reset så kommer det inte 4 digitala signaler från mikrofonerna (antar att vi har någon form av komparator där). Signalerna måste vara minst 1 klockcykel lång. Dessa signaler klockas om för att undvika metastabilitet då de är asynkrona. Sen låser vi signalerna internt tills vi har gått igenom tillståndsmaskinen.

Om vi börjar från botten så har vi 4 st instansierade räknare som är implementerade så här:

at_counter.png

Sen själva tillståndsmaskinen:

fsm.png

och till sist en vågform som illusterar tänket:

waves.png

Dvs när alla fyra mikrofoner skickat sitt svar så skickar vi ett interrupt och om det inte är en timeout (dvs minst en räknare har nått max) så kan vi läsa av de 4 räknarna. En av räknarna kommer alltid att vara 0 eftersom det är referensen.

Återstår lite mer verifiering av bla timeout och det fallet när två mikrofoner reagerar samtidigt.
Antalet bitar för räknaren är just nu 8 men är lätt att öka (har inte orkat räkna på hur många bitar som krävs...).

Här en schematisk bild av designen:

2022-02-07 20_08_13-CentOS7 64-bit - VMware Workstation.png

När jag väl orkar ska jag lägga upp koden på github eller bitbucket...

[Fält]

Japp. Men jag hade som sagt problem med att ISR:en som uppdaterar Arduinons uppfattning om tiden (som slår vid timer overflow) den blockerar avbrott så länge att man missar även vid input captures. Och om man stänger av den för timer0 så pajjar t ex micros(). Då måste man göra det på något annat sätt.

Men jag måste erkänna att jag inte kommer ihåg detaljerna nu, utan går efter mina anteckningar från innan jag bestämde mig att bygga allt i HW direkt istället.

Jag har för mig att det du mätte krävde lite mer från timingen, Arduinon du använde kan också ha andra timers. Det jag minns från exemplen var att du hade en input capture och en interrupt pinne på grund av hur hårdvaran var byggd och begränsingar i Arduinon du använde. En vanlig Arduino har bara en input capture, de modernare har två och värstingen med Mega 2560 chip har fyra. Så man måste välja MCU noga.

Men det kan ju också finnas något i arduino lagret som gör att den inte fungerar som den gör när man programmerar processorn i riktig C. Det är möjligt att man är tvungen att stänga av lite inbyggda arduino funtioner för att få förväntat resultat. Det borde gå att lösa. Men en input capture kan inte blockeras, däremot kan man kanske missa en interrupt så att man inte får reda på att den fångat något.

DOCK, ett lite annat spår. Jag kom på att det ju kommit en ny spelare på marknaden med intressanta features. Raspberry Pi Pico, som bygger på Raspberrys egna SoC. (Tvåkärnig ARM-Cortex M0+ 133MHz, 2MB flash och 264KB RAM. 26 GPIO pinnar, tre ADC:er om 12 bitar)

Jag har bara skummat förbi RPI Pico, när jag såg den släppas så såg det ut som om man bara programmerade den i Python. Jag har inte titta på den sedan dess. Det var uppenbarligen ett misstag. Särskilt då jag letat runt ganska mycket de sista dagarna efter något med bra fart och bra mjukvarustöd. Mjukvarustödet för En RPI product är normalt svårslaget.

[Fält]

Så jag har börjat med att implementera lite enkel logik. Jag har i nuläget fokuserat på själva konceptet och har inte alls hunnit verifiera allt. Men grunden verkar iallafall fungera när jag simulerar.
Så förutom klocka och reset så kommer det inte 4 digitala signaler från mikrofonerna (antar att vi har någon form av komparator där). Signalerna måste vara minst 1 klockcykel lång. Dessa signaler klockas om för att undvika metastabilitet då de är asynkrona. Sen låser vi signalerna internt tills vi har gått igenom tillståndsmaskinen.

Återstår lite mer verifiering av bla timeout och det fallet när två mikrofoner reagerar samtidigt.
Antalet bitar för räknaren är just nu 8 men är lätt att öka (har inte orkat räkna på hur många bitar som krävs...).

Om vi räknar med 1MHz för att få 0.34mm precision på mätningen vid 340m/s så ger 12bitar 1392mm och 13 bitar ger 2785mm.

Det du gör ser väldigt intressant ut, blir nästan lite sugen på att sätta mig in i det så att jag kan vara dålig på det istället för att inte veta något om det!

[Fält]

Två RPI Pico beställda, skall komma på Torsdag. 69kr styck från Inet med frakten inkluderad.

Det blir lite nytt att lära sig, men det verkar vara flexibelt.

[lasse-a]

Två RPI Pico beställda, skall komma på Torsdag. 69kr styck från Inet med frakten inkluderad.

Det blir lite nytt att lära sig, men det verkar vara flexibelt.

Gott! Men hade de inga på ElectroKit? De är billigare där. Och den är intressant, men de har (i mitt tycke) missat lite. De har t ex bara 16-bitars räknare för PWM, och bara en enkelt 1MHz central räknare. Den är å andra sidan 64 bitar, så man kan strunta i overflow...

Men PIO-maskinerna är intressanta. Jag tror att de kan misshandlas för att lösa det här problemet (och även det jag byggt lös logik för) med lite smart programmering.

Och klart du skall lära dig lite programmerbar logik. Lägg en helg så är vi två som är lika dåliga. (Jag tvingades att lära mig grunderna när det begav sig, och kan göra allt "för hand", men jag missade övergången till beskrivande språk, alltså VHLD/Verilog, och jag tycker de lämnar en del i övrigt att önska.)

Ett problem är att även om kretsarna kommit ner i pris så är utvecklingskort osv. fortfarande ohemult dyra. Man kan dock få tag på CPLD-kort (alltså en lillebror till FPGA) från Kina för 100-200:- och en kabel kostar några hundralappar (den finns billigt från Kina, men brukar inte fungera något vidare).

[lasse-a]

Så jag har börjat med att implementera lite enkel logik. Jag har i nuläget fokuserat på själva konceptet och har inte alls hunnit verifiera allt. Men grunden verkar iallafall fungera när jag simulerar.
Så förutom klocka och reset så kommer det inte 4 digitala signaler från mikrofonerna (antar att vi har någon form av komparator där). Signalerna måste vara minst 1 klockcykel lång. Dessa signaler klockas om för att undvika metastabilitet då de är asynkrona. Sen låser vi signalerna internt tills vi har gått igenom tillståndsmaskinen.

Eftersom det är enklare att vara kritisk än korrekt så kommer jag med följande förslag istället för att sätta mig in i alla detaljerna i din lösning.

Det blir lite komplikationer iom att du startar räknaren på första signalen från mikrofon, utan att kunna veta vilken mikrofon det här. (I mina kronografer så slipper man det problemet iom att man alltid vet vilken sensor som kommer först, vilket förenklar avsevärt).

MEN, du har ju en hel stor FPGA. Så istället så skulle jag låta klockan köra räknarna "free running" direkt från reset och helt enkelt ha större räknare. Med exv. 64 bitars räknare så kan man ju räkna på i drygt 500 år med 1 GHz-klocka innan man får overflow, så det finns ju stora marginaler att ta av. Om man inte får iväg skottet på (säg) ett år efter att man startat systemet, eller från förra skottet, så tycker jag man kan få skylla sig själv.

Då får man istället fyra helt separata och parallella kanaler där riskerna för interaktioner (exv. om två skott kommer "samtidigt") är obefintliga. Om man dessutom lägger en vippa på ingången som låser den hög när man fått "stopp-signal" på den kanalen (här kan man ju meckla med hysteres osv.) så blir avbrottslogiken till resten av processorn trivial; en fyra ingångars AND-grind med "stopp" signalerna från mikrofonerna som ingång. (Ja, man kan ta den signalen från själva räknaren med, dvs ta ut en stopp-signal där).

Med en dylik lösning så försvinner i stort sett hela styrlogiken, till en kostnad av högre energiåtgång (fyra räknare skall klockas kontinuerligt), men det kan man nog leva med här. Det blir också trivialt att skala upp eller ner till fler eller färre kanaler eftersom de är helt separata och bara består av ingång (stopp från extern sensor) och en räknare som stoppar när den får signal.

Det enda man saknar i en dylik lösning (även din om jag inte ser fel, och även i mina kronografer, så jag är inte bättre själv) är någon form av time-out som kan återställa ifall man bara får signal på en, eller två, men inte samtliga mikrofoner i rimlig tid.

Det hade jag löst genom att dra stoppsignalerna/ingångarna till en OR-grind som jag dragit ut som ytterligare ett interrupt till extern processor. Då får man en signal man kan starta en timeout med, och om man inte fått "färdigt"-avbrottet inom rimlig tid så resettar man, lämnar felmeddelande till användaren, och kör igen.

Det är naturligtvis trivialt att göra detta på FPGA:n med; bara starta en räknare och trigga en reset om den hinner räkna klart (den måste naturligtvis stoppas av "färdig"-signalen). Nackdelen med det är att man inte kan ändra sin timeout enkelt, och man måste fortfarande lämna en separat signal ut för att tala om att något gick fel. (Ja, dvs, man kan naturligtvis göra den räknaren programmerbar utifrån genom att låta extern processor ladda ett register, och man måste iofs ha buss osv. ändå, men det blir extra krångel, helt klart).

[Fält]

Två RPI Pico beställda, skall komma på Torsdag. 69kr styck från Inet med frakten inkluderad.

Det blir lite nytt att lära sig, men det verkar vara flexibelt.

Gott! Men hade de inga på ElectroKit? De är billigare där. Och den är intressant, men de har (i mitt tycke) missat lite. De har t ex bara 16-bitars räknare för PWM, och bara en enkelt 1MHz central räknare. Den är å andra sidan 64 bitar, så man kan strunta i overflow...

Men PIO-maskinerna är intressanta. Jag tror att de kan misshandlas för att lösa det här problemet (och även det jag byggt lös logik för) med lite smart programmering.

Jodå, men jag tänkte köpa en först och då var Inet lite billigare på grund av inräknad frakt. Men jag ändrade mig och köpte två. Men det är nog hugget som stucket med priset.

Det ser ut som om det skall gå att implementera en räknare i PIO, jag har sett liknande saker när jag kollat runt nu.

En annan intressant detalj är att interrupt fördröjningen ligger på en helt annan nivå än de andra alternativen. Det finns fallgropar som kan dra upp tiden rejält, Men 200nS eller bättre låter mer än bra. Mycket tas upp i den här tråden: https://forums.raspberrypi.com/viewtopic.php?t=306132

Så kretsen har mycket som talar för den, både det mycket låga priset, hög prestanda, låg interrupt latency och de två PIO enheterna med 4 state machines var. Jag tror att det här blir bra.

[lasse-a]

Det ser ut som om det skall gå att implementera en räknare i PIO, jag har sett liknande saker när jag kollat runt nu.

En annan intressant detalj är att interrupt fördröjningen ligger på en helt annan nivå än de andra alternativen. Det finns fallgropar som kan dra upp tiden rejält, Men 200nS eller bättre låter mer än bra. Mycket tas upp i den här tråden: https://forums.raspberrypi.com/viewtopic.php?t=306132

Bra funnet! Det var ju imponerande prestanda (särskilt för en krets som främst var tänkt att lära ungarna Python och lite knapptryckningar).

Jag sitter utan hårdvara den här veckan, men när jag läser så håller jag med du att det ser bra ut så långt.

Jag hoppas bara att vi inte nördat så illa att vi skrämt bort TS, det var ju inte meningen i så fall, hänger du med/här fortfarande Kattafan?

[detstorabla]

Eftersom det är enklare att vara kritisk än korrekt så kommer jag med följande förslag istället för att sätta mig in i alla detaljerna i din lösning.

Det blir lite komplikationer iom att du startar räknaren på första signalen från mikrofon, utan att kunna veta vilken mikrofon det här. (I mina kronografer så slipper man det problemet iom att man alltid vet vilken sensor som kommer först, vilket förenklar avsevärt).

MEN, du har ju en hel stor FPGA. Så istället så skulle jag låta klockan köra räknarna "free running" direkt från reset och helt enkelt ha större räknare. Med exv. 64 bitars räknare så kan man ju räkna på i drygt 500 år med 1 GHz-klocka innan man får overflow, så det finns ju stora marginaler att ta av. Om man inte får iväg skottet på (säg) ett år efter att man startat systemet, eller från förra skottet, så tycker jag man kan få skylla sig själv.

Då får man istället fyra helt separata och parallella kanaler där riskerna för interaktioner (exv. om två skott kommer "samtidigt") är obefintliga. Om man dessutom lägger en vippa på ingången som låser den hög när man fått "stopp-signal" på den kanalen (här kan man ju meckla med hysteres osv.) så blir avbrottslogiken till resten av processorn trivial; en fyra ingångars AND-grind med "stopp" signalerna från mikrofonerna som ingång. (Ja, man kan ta den signalen från själva räknaren med, dvs ta ut en stopp-signal där).

Med en dylik lösning så försvinner i stort sett hela styrlogiken, till en kostnad av högre energiåtgång (fyra räknare skall klockas kontinuerligt), men det kan man nog leva med här. Det blir också trivialt att skala upp eller ner till fler eller färre kanaler eftersom de är helt separata och bara består av ingång (stopp från extern sensor) och en räknare som stoppar när den får signal.

Det enda man saknar i en dylik lösning (även din om jag inte ser fel, och även i mina kronografer, så jag är inte bättre själv) är någon form av time-out som kan återställa ifall man bara får signal på en, eller två, men inte samtliga mikrofoner i rimlig tid.

Det hade jag löst genom att dra stoppsignalerna/ingångarna till en OR-grind som jag dragit ut som ytterligare ett interrupt till extern processor. Då får man en signal man kan starta en timeout med, och om man inte fått "färdigt"-avbrottet inom rimlig tid så resettar man, lämnar felmeddelande till användaren, och kör igen.

Det är naturligtvis trivialt att göra detta på FPGA:n med; bara starta en räknare och trigga en reset om den hinner räkna klart (den måste naturligtvis stoppas av "färdig"-signalen). Nackdelen med det är att man inte kan ändra sin timeout enkelt, och man måste fortfarande lämna en separat signal ut för att tala om att något gick fel. (Ja, dvs, man kan naturligtvis göra den räknaren programmerbar utifrån genom att låta extern processor ladda ett register, och man måste iofs ha buss osv. ändå, men det blir extra krångel, helt klart).

Jag har 4 separata mikrofoningångar (digitala) och en tillståndsmaskin. Och nu har jag verifierat och fixat några buggar i koden på vägen.
Timeout finns. Om någon räknare når "max" så har man en timeout och det flaggas. flera "samtidiga" mikrofoner hanteras. Ska lägga till ett register som talar om vilken mikrofon som orsakade timeouten viket kan vara bra vid felsökning. Att tala om AND och OR är lite ointressant när man kodar HDL (förutom att såna villkor finns i koden).

Här kommer nu koden för själva toppnivån i nuläget.
https://bitbucket.org/detstorabla2/acoustictarget
(rtl är alltså själva koden till det hela).