Svenska ElektronikForumet

Ah, ja jag tänkte ju att du skulle räkna fram CRC med mjukvara, hade ingen aning om att det fanns en sådan modul inyggd i CPU'n. Det är så klart ännu bättre - om den fungerar som de ska.

Kollade upp det, och F4 så är det hur simpelt som helst
Så tack för tipset

Nu ska jag bara hitta ett snabbt sätt att räkna ut CRC i C# då det inte finns något färdigt/inbyggt för det där.

snabbgoogling, http://stackoverflow.com/questions/5059 ... ementation ?

remne: Crc16CcittKermit, måste kolla upp vilken CRC typ det är som STM32 kan hantera.

Hmm CRC resultatet är 32bitar, och då min första bit i varje byte är paket start ID, så kommer det ta 102bit
och skickar jag två paket för varje kommando och kolla om dessa är lika så går det är 128bit

känns inte som jag vinner så mycket på det. de beror mer på hur mycket tid CRC tar i C#

Nu förstår jag inte....
Om det allt som allt, inklusive 32 bitar CRC blir 102 bitar så är det väl 80 bitar utan CRC inkluderat? Två sådana paket blir väl 160bitar? Om du räknar in en start och en stopbit för varje byte måste du göra det för de 4 CRC byten också, totalt 12bytes*10 bitar=120bitar. Oavsett så måste du väl räkna med de i båda fallen för att jämförelsen ska bli rättvis? Men antagligen är det bara jag som inte förstår hur det är tänkt....

Ett alternativ som säkert är tillräckligt på så smp paket är ju att använda 16 bitars CRC istället. Men det kanske inte hårdvarumodulen stödjer så då måste du göra det i mjukvara på STM32'an också....

Jag ska testa och se vad jag får för prestanda med CRC jämfört utan CRC men man skickar 2 likadana paket som jämförs ist.

Då jag använder MSB till startbit id så kan jag bara använda 7 bit per byte, 32bit + 4bit -> avrundning i byte = 40bit (5*8bit)
Så 64bit + 40bit = 104bit, "snabbräkning stämde inte helt ändå för mig "

Jag behöver bara kolla mina 64bitar med CRC vad jag kan tänka mig.

Är inte 32 bitars crc lite overkill för 80 bitar data (eller hur många bitar det exakt nu var..)?
Jag skulle gissa att en 8 bitars CRC skulle räcka väldigt länge, 16 bitar mer än tillräckligt...

Det finns någonstans uträkningar på sannolikheter osv mellan datalängd/crclängd..

Ursäkta om jag inte läst alla inlägg nu igen, skummade bara igenom sista två sidorna. Men med vilket interface pratar du med PCn? Du har ju fin USB 2.0 på det där chippet. Jag kör Atmels typ motsvarighet till den där, och jag kommer upp i 80 MBit/s på den när jag kör DMA över USB. Dessutom med USB 2.0 så är varje USB-paket 512 bytes Så det spelar ingen roll om du skickar 1 eller 512 bytes, det tar samma tid. 1 ms om du skickar varje full-frame och 1/8 ms om du kör microframes. Några bitar hit eller dit spelar ingen roll då.

Tänkte på USB, dock så kommer en av dessa kort sitta ute på själva pick and place huvudet. Vilket gör att kabeln kommer gå i en kabel ränna som det kommer gå en hel del annan elektronik i.
Så längden och störningsrisk så gick jag över till RS422 ist.

Har ytterligare ett kort som ska göras som kommer sitta på huvudet, och det är inte så viktigt hur de funkar då det är endast för debug. Kan testa att använda USB till den ist.
Så kan jag värdera om det funkar i längden.

Att testa är att veta

Jobbar på de mesta parallellt just nu

Har äntligen (och då menar jag verkligen ÄNTLIGEN) fått samma respons från den interna CRC perfieri enheten i STM32 som från C# CRC32 implementation

USB på STM32F1 är i gång och under stress test.

Har skapat ett C# loopback test program som kan hålla X antal UART/FTDI anslutningar öppna/skriva/läsa parallellt för att kunna utföra varierande tester.

just nu får jag väldigt konstant respons från en enkel loopback test.

ett kommando skickas till STM32 som i sin tur skickar tillbaka ett kommando som tolkas som äkta av C# programmet och skickar ett nytt kommando till STM32, osv.

Det verkar som jag har något som begränsar hastigheten när man switchar upp/ner data då jag får nästan samma tid för alla UART hastigheter,

för 1000 loopar så får jag detta resultat.
så de flesta ligger på ca 20ms för en kommando loop.
921600 ->FT_OK
00:00:19.17

460800 ->FT_OK
00:00:22.91

230400 ->FT_OK
00:00:20.51

115200 ->FT_OK
00:00:20.27

57600 ->FT_OK
00:00:18.43

38400 ->FT_OK
00:00:19.68

19200 ->FT_OK
00:00:20.98

9600 ->FT_OK
00:00:29.46

De konstiga är att tiden inte varierar om jag skickar ett kommando som är 1 byte eller 60 byte lång.
krävs mer tester helt enkelt

Krävs en del fixande o testande för att hitta en optimal data drivrutin.

Kan det vara så att det tar tid att räkna 1000 CRC i C#?

Testade CRC funktionen och det är inte den som är orsaken, 1 000 000 loops * 100bytes tar 470ms
Vilket ger ~0.5us för 100bytes vilket är helt oki. Detta är på PC sidan, har inte kollat STM32 men jag har för mig att den gör det på någon enstaka klockcykel

Men de har med UART rutinerna, ska grotta vidare

Nu har jag jobbat på överförings drivrutiner och protokoll hantering i snart en vecka och de har gett resultat.
Dock blandat

Nu har jag verkligen fått upp hastigheten, högst blir det med en FTDI krets som mottagare.
just nu så loopas bara datan -> Rx & Tx sitter i hopp på FTDI/STM32

STM32 använder sin interna USB och så kopplar jag bara i hopp Rx->Tx buffer internt.

Start -> Timer Start
Jag genererar 10000 paket med data och lägger till CRC och stoppar dessa i en Kö, en egen tråd ligger och skickar dessa till chippet (STM32/FTDI).
Datan kommer tillbaka och CRC32 checkas, Data variabler separeras och stoppas in i en Kö med allt som skickats, dessa jobbar i varsina trådar.
Testprogrammet väntar tills sista paketet har mottagits och bearbetats -> timer stop

Paket ID finns med som sedan används för att fråga efter paketet som inte klarade CRC eller som saknas.

ACK hantering Timeout/omskick finns inbyggd.
Man kan skicka och ta i mot data i alla möjliga former.
PackageID, Command, Address, Data[]

Nu till resultat siffrorna

Mot FTDI som virutell comport.
Mot STM32F1 , ingen delay mellan varje Tx Data skick
Mot STM32F1 ,20ms delay mellan varje Tx Data skick (Data flöde ut är strypt) Till FTDI chippet så får jag alltid 0% paket förlust, dock så får jag alltid paketförlust till STM32
om jag nu inte skickar riktigt långsamt, ska testa mera.

Men det ser verkligen lovande ut

Datamängden som överförings hastigheten räknas på är bara i Rx hållet, och all encoding och decoding av data samt CRC är medräknat,
så överförings hastigheten i bara data är säkert högre.

Så nu har jag pysslat med STM32 drivarna ett tag till och även testat USB koden samt protokollet på en STM32L1

Jag börjar gilla den interna USB funktionen, dock så har jag inte löst paket bortfallet som jag nämnde tidigare.

Nu har jag skickat CRC kodade paket på 2Kbyte och det gick undan, dock har jag inte gjort stresstest med statistik när jag skickar stora paket. men de kommer

Kan visa en bild, (många gillar juh bilder, inc mig själv så ), inte för att de visar så mycket.



Baudrate = 9600 har ingen betydelse när jag är ansluten via USB på stm32, det spelar ingen roll vad jag sätter, får samma hastighet ändå.

Ska bli intressant sen när jag har tid att testa STM32F4 full speed USB