Dik. byl sem se ženou na vodní dýmce a teprve teď sem přišel domu.
M
Linuxcnc vs SSERIAL
Díky za tohle vlákno, hodně pomohlo.
Už u toho pár dní sedím, kouří se mi z hlavy ale podařilo se mi rozblikat ledku
Narazil jsem na nějaké nejasnosti v chování LinuxCNC když poslouchám mou 7i73:
1, moje verze LinuxCNC ( 2.9.8 ) při startu režimu (v discovery po 0xBB) čte nejdříve PTOC parametry, což by mělo být ve výsledku jedno ale je to k zamyšlení a způsobuje to možná následující jevy:
2, u GTOC když čte parametry 0xB0 tak se zasekne, vrátí se a začne číst sadu parametru (řádek) znovu (nedočtené řádky jsem označil červeně). Kromě delšího času čtení to ale asi ničemu nevadí
3, u některých sad parametrů nečte string s popisem a hned skočí do další sady parametru (označeno žlutě). Chybí mi tak Output, Input, ENC, enc a NVBaudRate. Kromě NVBaudRate mi ale v Halshow nic nechybí. Možná to je tím že LinuxCNC již tyto parametry načetl v PTOC (parametry v PTOC mají stejnou ADDRESS OF PARM) a tak si název přenese z PTOC?
Zkoušel jsem různé HW a SW mody, LinuxCNC 2.9.8 na mašině vedle, 2.9.2 na jiné mašině ale nikdy jsem v Halshow NVBaudRate neviděl. Dokonce i 7i84 se projevuje stejně.
Né že bych NVBaudRate u 7i73 postrádal ale ze stránky správné integrace SSERIAL do STM32 musím znát co vše se děje a proč.
Vím že už je to spoustu let zpět, ale nevzpomeneš si jakou jsi používal verzi LinuxCNC?
Pokud se mi vše podaří oživit tak zde hodím zase nějaké své poznatky na které jsem narazil
Už u toho pár dní sedím, kouří se mi z hlavy ale podařilo se mi rozblikat ledku
Narazil jsem na nějaké nejasnosti v chování LinuxCNC když poslouchám mou 7i73:
1, moje verze LinuxCNC ( 2.9.8 ) při startu režimu (v discovery po 0xBB) čte nejdříve PTOC parametry, což by mělo být ve výsledku jedno ale je to k zamyšlení a způsobuje to možná následující jevy:
2, u GTOC když čte parametry 0xB0 tak se zasekne, vrátí se a začne číst sadu parametru (řádek) znovu (nedočtené řádky jsem označil červeně). Kromě delšího času čtení to ale asi ničemu nevadí
3, u některých sad parametrů nečte string s popisem a hned skočí do další sady parametru (označeno žlutě). Chybí mi tak Output, Input, ENC, enc a NVBaudRate. Kromě NVBaudRate mi ale v Halshow nic nechybí. Možná to je tím že LinuxCNC již tyto parametry načetl v PTOC (parametry v PTOC mají stejnou ADDRESS OF PARM) a tak si název přenese z PTOC?
Zkoušel jsem různé HW a SW mody, LinuxCNC 2.9.8 na mašině vedle, 2.9.2 na jiné mašině ale nikdy jsem v Halshow NVBaudRate neviděl. Dokonce i 7i84 se projevuje stejně.
Né že bych NVBaudRate u 7i73 postrádal ale ze stránky správné integrace SSERIAL do STM32 musím znát co vše se děje a proč.
Vím že už je to spoustu let zpět, ale nevzpomeneš si jakou jsi používal verzi LinuxCNC?
Pokud se mi vše podaří oživit tak zde hodím zase nějaké své poznatky na které jsem narazil
- Přílohy
-
- Parameter_7i73_2.9.8_Meki.pdf
- (293.06 KiB) Staženo 18 x
Ahoj,
tak prvně gratulace k úspěchu, ikdyž ještě kousek do cíle chybí.
hrál sem si s tím v roce 2017 a většinou jsem fungoval na oficialni verzi a vedle toho nejnovejsi kompilovanou dev verzi, takže tipuju neco jako 2.7.8 a vedlo toho 2.8.x ale fakt netuším. Jestli si matně vzpominam, tak neco v jedne verzi chodilo a v druhe ne, ale to byla dřevní doba a sserial v plenkach. predpokladam, ze dneska uz to bude chodit na vsem. vzpominam si, ze se treba zvysil limit z96 bitu na 196b nebo tak něco.
Bohužel už jsem se k tomu moc nedostal, řešil jsem jiné hádanky.
M
tak prvně gratulace k úspěchu, ikdyž ještě kousek do cíle chybí.
hrál sem si s tím v roce 2017 a většinou jsem fungoval na oficialni verzi a vedle toho nejnovejsi kompilovanou dev verzi, takže tipuju neco jako 2.7.8 a vedlo toho 2.8.x ale fakt netuším. Jestli si matně vzpominam, tak neco v jedne verzi chodilo a v druhe ne, ale to byla dřevní doba a sserial v plenkach. predpokladam, ze dneska uz to bude chodit na vsem. vzpominam si, ze se treba zvysil limit z96 bitu na 196b nebo tak něco.
Bohužel už jsem se k tomu moc nedostal, řešil jsem jiné hádanky.
M
Zajímavé, o tom jsem nevěděl, dočetl jsem se jen že jsou na straně LinuxCNC 3 registry pro data po 32bit.
Řešil jsi nějak příchozí crc? v kódu jsem našel jen výpočet pro Transmit.
Zítra se asi zase napíchnu na 7i73 a budu zkoumat jak vlastně funguje rx a tx většího balíčku dat než kolik je nastaveno počet rx a tx byte pro jeden přenos. Nejdříve jsem myslel že budou chodit data a příkazy co se má s daty dít, tak je to zakreslené myslím i v návodu, a při zaplnění rx nebo tx byte se data rozloží do více přenosů. Teď jsem ale zjistil že po lince běhají jen holé data v pořadí vedle sebe v jakém se při discovery deklarovaly. Co mě ale zarazilo - když jsem ze zvědavosti zkusil poslat z LinuxCNC víc byte než jsem nastavil příkazem 0xBB, nenastalo automaticky přepínání a rozložení do více přenosů jak jsem si myslel ale všechny data nad se usekly a zahodily.
Buď mám něco špatně nastavené, nebo něco nastavené nemám a nebo hold musím mít tak široký přenos aby se vešly všechny data - ale vím že 7i73 ty data točí ve více přenosech, i v manuálu je něco popsané, budu rád za jakékoliv nakopnutí
Řešil jsi nějak příchozí crc? v kódu jsem našel jen výpočet pro Transmit.
Zítra se asi zase napíchnu na 7i73 a budu zkoumat jak vlastně funguje rx a tx většího balíčku dat než kolik je nastaveno počet rx a tx byte pro jeden přenos. Nejdříve jsem myslel že budou chodit data a příkazy co se má s daty dít, tak je to zakreslené myslím i v návodu, a při zaplnění rx nebo tx byte se data rozloží do více přenosů. Teď jsem ale zjistil že po lince běhají jen holé data v pořadí vedle sebe v jakém se při discovery deklarovaly. Co mě ale zarazilo - když jsem ze zvědavosti zkusil poslat z LinuxCNC víc byte než jsem nastavil příkazem 0xBB, nenastalo automaticky přepínání a rozložení do více přenosů jak jsem si myslel ale všechny data nad se usekly a zahodily.
Buď mám něco špatně nastavené, nebo něco nastavené nemám a nebo hold musím mít tak široký přenos aby se vešly všechny data - ale vím že 7i73 ty data točí ve více přenosech, i v manuálu je něco popsané, budu rád za jakékoliv nakopnutí
Nemáš nějaký lehčí otázky. já si nepamatuju nic.
Dokonce se mi stalo, že sem něco řešil, našel článek kterýmu sem pěkně rozumněl a nakonci sem zjistil, že sem ho psal já před x lety a neměl sem ani páru že sem se danému tématu v minulosti věnoval.
Ale myslím že CRC na příjmu tvoji desticky není úplně na testování/rozběhání potřeba hlídat. jiná otázka je při vysílání, tam když ti nebude sedět CRC tak to protistrana odmitne. Ve finále bych ale hlidani CRC použil at neprijmes nejakou blbost. logika je stejna jako pro vysílání.
https://www.forum.linuxcnc.org/27-drive ... ons#219072 tady je zminka o tom rozsireni na 224bitu.
ted sem letmo kouknul sem
https://github.com/fupe/sserial-template/ tam nejaky crc kontroly jsou v obou smerech.
Martin
já si nepamatuju nic. Dokonce se mi stalo, že sem něco řešil, našel článek kterýmu sem pěkně rozumněl a nakonci sem zjistil, že sem ho psal já před x lety a neměl sem ani páru že sem se danému tématu v minulosti věnoval.
Ale myslím že CRC na příjmu tvoji desticky není úplně na testování/rozběhání potřeba hlídat. jiná otázka je při vysílání, tam když ti nebude sedět CRC tak to protistrana odmitne. Ve finále bych ale hlidani CRC použil at neprijmes nejakou blbost. logika je stejna jako pro vysílání.
https://www.forum.linuxcnc.org/27-drive ... ons#219072 tady je zminka o tom rozsireni na 224bitu.
ted sem letmo kouknul sem
https://github.com/fupe/sserial-template/ tam nejaky crc kontroly jsou v obou smerech.
Martin
Díky za odkaz na github, tuto verzi jsem přehlídl. To je teda pořádný upgrade oproti předchozím verzím zde v tomto vlákně. Krásný kus práce, přehledné i popsané.
Docela láká vzít Ctrl+C Ctrl+V a slíznout jen smetanu ze tvých xx hodin práce , ale chtěl bych se naučit STM32 a prokousat se tím. Stavím teda osekanější verzi, jen jeden hw a sw mod (stavím to pro konkrétní aplikaci, univerzálnost neplánuju). Koukám že v té github verzi do LinuxCNC v discovery taky servíruješ virtuální adresy PTOC a GTOC, vydal jsem se taky touto cestou. Tx i Rx crc počítám a špatné data mám zatím nastavené zahazovat, později možná napojím na CRCerror aby měl LinuxCNC echo, v tvé předchozí verzi jsem neviděl že by jsi příchozí crc počítal tak mě napadlo se zeptat jestli jsi to neodpojil kvůli nějaké nestabilitě nebo tak.
To rozšíření na 224bit jsem musel hned testnout na LinuxCNC 2.9.8 a zdá se že to není tak žhavé. nad 15tx bajtu neseděl z LinuxCNC crc součet ale do 15 se to tvářilo funkčně. Když jsem ale chtěl odesílat data tak se to stejně ořezalo na 12bajt. Ještě je ale ve hře jeden faktor- protože příkazy do SmartSerial neposílá přímo LinuxCNC ale FPGA a je možné že (konkrétně v mé 5i25) nemám nejaktuálnější .BIN file. Měla by to mít na starosti tuším tato komponenta: https://github.com/LinuxCNC/hostmot2-fi ... serial.vhd
Docela mě láká to zjistit, nejprve ale oživím to stm32.
Na můj panel mi vychází že bych potřeboval posílat 390bit do STM32 (jen 264bit sežerou 7seg displeje) a 129bit do LinuxCNC, pokud ty data nerozložím do více přenosů tak by mě ani 224bit nespasilo. Přehlídl jsem ale jednu vychytávku DATA_TYPE 0x06 = STREAM takže by to mělo jít rozložit do více přenosů. Pokud to bude fungovat tak jak si myslím, tak by odpadl ten limit s šířkou jednoho přenosu 96bit.
STM32 které používám má 4uarty takže by teoreticky šlo nastavit aby se choval jako 4virtuální Smartserial karty, to je ale jen takové záložní řešení.
Jinak po načtení PTOC a GTOC (to už zde fupe popsal) nastane další část - načtení hodnot pro konkrétní parametr (např. NVWatchDogTimeout atd.). LinuxCNC se dotazuje přes příkazy 0x4x 0xyy 0xyy . Kde 0xyy 0xyy je ADDRESS OF PARM kterou se LinuxCNC dozvěděl z ADDRESS OF PARM z PTOC a GTOC předešlé discovery fázi.
- Příkaz 0x4C je specifický tím, že Slave (7i73 v mém případě) odpovídá 1byte + CRC a LinuxCNC data skládá tak jako když načítal PTOC a GTOC tabulku jen v tomto případě už zná délku z DATA SIZE IN BITS takže nečeká na 0x00. Tzn pro větší data než DATA SIZE IN BITS = 08 se LinuxCNC dotazuje opakovaně na ADDRESS OF PARM, ADDRESS OF PARM + 1 atd. Je na to třeba myslet a nechat mu dostatečné místo aby se ADDRESS OF PARM dalšího parametru PTOC nepřekrylo s předchozím.
- Příkazy 0x44, 0x45, 0x46, 0x47 už jsou chytřejší a slave na ně odpovídá 0x44 - 1byte, 45 - 2byte, 46 - 4byte, 47 - 8byte. Po a před těmito příkazy se ještě vyskytují 0xEC 0x00 a 0xEC 0x01, netuší co znamenají, v dokumentaci 0xEC není popsaný, ale vidím že fupe to rozluštil
Nechápu proč se volatile čtou tak podivně 0x4C po 1 byte když existuje daleko chytřejší přenos 0x44-7 (třeba to nějak souvisí s staršími čipy, rozdílným adresováním různých pamětí, netuším)
Až se LinuxCNC dozví všechny parametry přes příkaz 0x4x , začne druhá fáze - posílání parametrů do slave příkazem 0x6x yy yy zz ... . x je zase stejné jako minule - 0x64 - 1byte, 65 - 2byte, 66 - 4byte, 67 - 8byte, y je ADDRESS OF PARM také jako minule, a z je hodnota (o délce podle x). Posílají se pouze parametry s DATA DIRECTION 0x40 a 0x80 (vstupně/výstupní a výstupní) a z nich pouze parametry které mají v LinuxCNC jinou hodnotu než v Slave
Jakmile se vše dokončí, ukončí se discovery, nastane normální komunikace 0xBD a LinuxCNC už se k žádnému parametru nevrací. Pokud se jakýkoliv parametr který chceme dostat do slave změní, musí nastat znovu discovery = restart LinuxCNC nebo restart komunikace příkazem:
halcmd setp hm2_....sserial.port.0.run 0
halcmd setp hm2_....sserial.port.0.run 1
Celý proces discovery u 7i73 trvá okolo 0,5s u jiných karet i rychleji. Discovery je hotové dřív než se rozběhne GUI
Snad mě někdo opraví/upřesní pokud jsem napsal něco špatně
Docela láká vzít Ctrl+C Ctrl+V a slíznout jen smetanu ze tvých xx hodin práce
, ale chtěl bych se naučit STM32 a prokousat se tím. Stavím teda osekanější verzi, jen jeden hw a sw mod (stavím to pro konkrétní aplikaci, univerzálnost neplánuju). Koukám že v té github verzi do LinuxCNC v discovery taky servíruješ virtuální adresy PTOC a GTOC, vydal jsem se taky touto cestou. Tx i Rx crc počítám a špatné data mám zatím nastavené zahazovat, později možná napojím na CRCerror aby měl LinuxCNC echo, v tvé předchozí verzi jsem neviděl že by jsi příchozí crc počítal tak mě napadlo se zeptat jestli jsi to neodpojil kvůli nějaké nestabilitě nebo tak.To rozšíření na 224bit jsem musel hned testnout na LinuxCNC 2.9.8 a zdá se že to není tak žhavé. nad 15tx bajtu neseděl z LinuxCNC crc součet ale do 15 se to tvářilo funkčně. Když jsem ale chtěl odesílat data tak se to stejně ořezalo na 12bajt. Ještě je ale ve hře jeden faktor- protože příkazy do SmartSerial neposílá přímo LinuxCNC ale FPGA a je možné že (konkrétně v mé 5i25) nemám nejaktuálnější .BIN file. Měla by to mít na starosti tuším tato komponenta: https://github.com/LinuxCNC/hostmot2-fi ... serial.vhd
Docela mě láká to zjistit, nejprve ale oživím to stm32.
Na můj panel mi vychází že bych potřeboval posílat 390bit do STM32 (jen 264bit sežerou 7seg displeje) a 129bit do LinuxCNC, pokud ty data nerozložím do více přenosů tak by mě ani 224bit nespasilo. Přehlídl jsem ale jednu vychytávku DATA_TYPE 0x06 = STREAM takže by to mělo jít rozložit do více přenosů. Pokud to bude fungovat tak jak si myslím, tak by odpadl ten limit s šířkou jednoho přenosu 96bit.
STM32 které používám má 4uarty takže by teoreticky šlo nastavit aby se choval jako 4virtuální Smartserial karty, to je ale jen takové záložní řešení.
Jinak po načtení PTOC a GTOC (to už zde fupe popsal) nastane další část - načtení hodnot pro konkrétní parametr (např. NVWatchDogTimeout atd.). LinuxCNC se dotazuje přes příkazy 0x4x 0xyy 0xyy . Kde 0xyy 0xyy je ADDRESS OF PARM kterou se LinuxCNC dozvěděl z ADDRESS OF PARM z PTOC a GTOC předešlé discovery fázi.
- Příkaz 0x4C je specifický tím, že Slave (7i73 v mém případě) odpovídá 1byte + CRC a LinuxCNC data skládá tak jako když načítal PTOC a GTOC tabulku jen v tomto případě už zná délku z DATA SIZE IN BITS takže nečeká na 0x00. Tzn pro větší data než DATA SIZE IN BITS = 08 se LinuxCNC dotazuje opakovaně na ADDRESS OF PARM, ADDRESS OF PARM + 1 atd. Je na to třeba myslet a nechat mu dostatečné místo aby se ADDRESS OF PARM dalšího parametru PTOC nepřekrylo s předchozím.
- Příkazy 0x44, 0x45, 0x46, 0x47 už jsou chytřejší a slave na ně odpovídá 0x44 - 1byte, 45 - 2byte, 46 - 4byte, 47 - 8byte. Po a před těmito příkazy se ještě vyskytují 0xEC 0x00 a 0xEC 0x01, netuší co znamenají, v dokumentaci 0xEC není popsaný, ale vidím že fupe to rozluštil
Jestli to správně chápu tak (podle dokumentace mají příkazy NV (např. NVWatchDogTimeout) dvojníka v ramce (WatchDogTimeout) o stejné adrese) a tyto příkazy po příchodu z LinuxCNC čekají někde v proměnné v slave ale až po 0xEC se rozhodne do které paměti se zapíšou? RAM (0x00) / EEPROM (0x01)?LBP_COMMAND_LOCAL_WRITE_NVMEM_FLAG = 0xEC, // 0x01 nvacces 0x00normal acces
Nechápu proč se volatile čtou tak podivně 0x4C po 1 byte když existuje daleko chytřejší přenos 0x44-7 (třeba to nějak souvisí s staršími čipy, rozdílným adresováním různých pamětí, netuším)
Až se LinuxCNC dozví všechny parametry přes příkaz 0x4x , začne druhá fáze - posílání parametrů do slave příkazem 0x6x yy yy zz ... . x je zase stejné jako minule - 0x64 - 1byte, 65 - 2byte, 66 - 4byte, 67 - 8byte, y je ADDRESS OF PARM také jako minule, a z je hodnota (o délce podle x). Posílají se pouze parametry s DATA DIRECTION 0x40 a 0x80 (vstupně/výstupní a výstupní) a z nich pouze parametry které mají v LinuxCNC jinou hodnotu než v Slave
Jakmile se vše dokončí, ukončí se discovery, nastane normální komunikace 0xBD a LinuxCNC už se k žádnému parametru nevrací. Pokud se jakýkoliv parametr který chceme dostat do slave změní, musí nastat znovu discovery = restart LinuxCNC nebo restart komunikace příkazem:
halcmd setp hm2_....sserial.port.0.run 0
halcmd setp hm2_....sserial.port.0.run 1
Celý proces discovery u 7i73 trvá okolo 0,5s u jiných karet i rychleji. Discovery je hotové dřív než se rozběhne GUI
Snad mě někdo opraví/upřesní pokud jsem napsal něco špatně
Narazil jsem na pár zapeklitých situací v discovery při servírování adres do LinuxCNC:
- Adresa adresy (to co je nastaveno v 0xBB) nesmí být 0x0000 jinak se discovery nevykoná (to je popsáno i v návodu)
- Adresa už konkrétního parametru PTOC nebo GTOC taky nesmí začínat 0x0000 jinak ji LinuxCNC přeskočí na další adresu adresy (to už v návodu uvedeno není)
- Adresa ADDRESS OF PARM (tam kde se nachází už konkrétní hodnota parametru) nesmí začínat 0xD0xx (formát LSB = 0xxx 0xD0) - tohle mě docela vypeklo, linuxCNC házel error parametru a trvalo mi několik hodin než jsem zjistil že je špatná adresa nikoliv hodnota. V návodu o tom není ani zmínka a tak nevím které hodnoty jsou OK, ale asi bych se držel čísel podle odposlechu 7i73 (tzn. adresy do 0x0Fxx) a zde už adresa 0x0000 být může. Koukám že fupe posílá adresy 0x4000 a výš, tak je tam asi taky bezpečný prostor.
- Adresa adresy (to co je nastaveno v 0xBB) nesmí být 0x0000 jinak se discovery nevykoná (to je popsáno i v návodu)
- Adresa už konkrétního parametru PTOC nebo GTOC taky nesmí začínat 0x0000 jinak ji LinuxCNC přeskočí na další adresu adresy (to už v návodu uvedeno není)
- Adresa ADDRESS OF PARM (tam kde se nachází už konkrétní hodnota parametru) nesmí začínat 0xD0xx (formát LSB = 0xxx 0xD0) - tohle mě docela vypeklo, linuxCNC házel error parametru a trvalo mi několik hodin než jsem zjistil že je špatná adresa nikoliv hodnota. V návodu o tom není ani zmínka a tak nevím které hodnoty jsou OK, ale asi bych se držel čísel podle odposlechu 7i73 (tzn. adresy do 0x0Fxx) a zde už adresa 0x0000 být může. Koukám že fupe posílá adresy 0x4000 a výš, tak je tam asi taky bezpečný prostor.
Dneska bouchám šampáňo, povedlo se
Včera jsem rozdýchal 8x 7segment display s max7219, to už byla celkem brnkačka oproti zmáknutí discovery.
Dnes jsem zjistil jak funguje přenos dat jako stream. Jde to vidět v komponentě lcd.c která je na github (musím říct že ChatGPT v tomto šetří hodiny času, celý kod krásně předžvýkal a naservíroval mi jen to výživné aniž bych musel studovat vše řádek po řádku. LCD mě neláká a tak se mi to nechtělo studovat).
Jde o to že samotný DATA_TYPE = stream data automaticky nezalomí do dalšího přenosu, k tomu slouží HAL komponenta která každou periodu musí servírovat další data v pořadí.
Podařilo se mi napsat vlastní HAL komponentu - která vytvoří piny 0 až 191 a ty rozloží do 8přenosů přes sserial po 24bit. 24bit proto, protože LinuxCNC zmákne max. u32 a první byte mi slouží jako index. Takže např.: 0x01 0x00 0x00 0x00 jsou pin[24] až pin[47], 0x02 0x00 0x00 0x00 jsou pin[48] až pin[71] atd... Pokud bych přidal další komponenty tak se můžu roztáhnout na celou šířku přenosu (u mé verze 96bit = 3x u32) a samozřejmě můžu data natáhnout na víc přenosů, přičemž každý další přidá 72bit dat. Možnosti jsou skoro neomezené, limitující je pouze článek mezi monitorem a sedačkou
je vidět že už je k dispozici víc DATA_TYPE, v dokumentaci se nezmiňují ani o encoder:
https://github.com/LinuxCNC/linuxcnc/bl ... /sserial.h
#define LBP_ENCODER 0x08
#define LBP_FLOAT 0x10 // New for STMBL
#define LBP_NONVOL_FLOAT 0x11
#define LBP_ENCODER_H 0x18 // For Fanuc Absolute Encoders with separate
#define LBP_ENCODER_L 0x28 // part and full count fields.
Ps. omlouvám se že používám slovo LinuxCNC komunikuje s STM32. (Plete se mi master a slave tak jsem si to takto nesprávně zjednodušil). Jak už zde správně fupe na začátku psal, komunikace mezi LinuxCNC a FPGA je pro vytvoření vlastní sserial karty nepodstatná, STM32 komunikuje s FPGA, do FPGA při mesaflash nahráváme kod .bin nebo .bit a jeho součástí je sserial.vhd který řídí sserial jako master a s kterým sserial karty komunikují.
Včera jsem rozdýchal 8x 7segment display s max7219, to už byla celkem brnkačka oproti zmáknutí discovery.
Dnes jsem zjistil jak funguje přenos dat jako stream. Jde to vidět v komponentě lcd.c která je na github (musím říct že ChatGPT v tomto šetří hodiny času, celý kod krásně předžvýkal a naservíroval mi jen to výživné aniž bych musel studovat vše řádek po řádku. LCD mě neláká a tak se mi to nechtělo studovat).
Jde o to že samotný DATA_TYPE = stream data automaticky nezalomí do dalšího přenosu, k tomu slouží HAL komponenta která každou periodu musí servírovat další data v pořadí.
Podařilo se mi napsat vlastní HAL komponentu - která vytvoří piny 0 až 191 a ty rozloží do 8přenosů přes sserial po 24bit. 24bit proto, protože LinuxCNC zmákne max. u32 a první byte mi slouží jako index. Takže např.: 0x01 0x00 0x00 0x00 jsou pin[24] až pin[47], 0x02 0x00 0x00 0x00 jsou pin[48] až pin[71] atd... Pokud bych přidal další komponenty tak se můžu roztáhnout na celou šířku přenosu (u mé verze 96bit = 3x u32) a samozřejmě můžu data natáhnout na víc přenosů, přičemž každý další přidá 72bit dat. Možnosti jsou skoro neomezené, limitující je pouze článek mezi monitorem a sedačkou
je vidět že už je k dispozici víc DATA_TYPE, v dokumentaci se nezmiňují ani o encoder:
https://github.com/LinuxCNC/linuxcnc/bl ... /sserial.h
#define LBP_ENCODER 0x08
#define LBP_FLOAT 0x10 // New for STMBL
#define LBP_NONVOL_FLOAT 0x11
#define LBP_ENCODER_H 0x18 // For Fanuc Absolute Encoders with separate
#define LBP_ENCODER_L 0x28 // part and full count fields.
Ps. omlouvám se že používám slovo LinuxCNC komunikuje s STM32. (Plete se mi master a slave tak jsem si to takto nesprávně zjednodušil). Jak už zde správně fupe na začátku psal, komunikace mezi LinuxCNC a FPGA je pro vytvoření vlastní sserial karty nepodstatná, STM32 komunikuje s FPGA, do FPGA při mesaflash nahráváme kod .bin nebo .bit a jeho součástí je sserial.vhd který řídí sserial jako master a s kterým sserial karty komunikují.
- Přílohy
-
Ahoj,
velká gratulace k úspěchu. ted už to zbývá jen dodělat.
Mám radost, že moje a hlavně uživatele martyxxx "bádáni" má nové nástupce. Při pohledu na tu fotku úplně vidím svůj stůl s klubkem drátu a cítím ten pocit když poprvé zablikala dioda protože sem to chtěl já.
jak píšeš o Chat gpt, tak musím souhlasit, že je to velký pomocník. Bohužel tenkrát ještě nebyl k dispozici, tak nezbyvalo než to celý pročítat, zkoušet a snažit se o pochopení cizího a někdy i vlastního kodu
Ted si hraju s jednim svým projektem, kterej není uplně malej. Cca 500 000 řádků ve stovkach souborech a používám Codex připojenej na git.
Codex je schopnej to celý projít, navrhnout upravy a ty pak sam implementovat do kodu rozhazeneho po mnoha souborech. Samozřejme že je stále potřeba mit svojí představu jak to má celé fungovat, ale třeba na navrh různých kontrol je to bomba. řekneš mu co chceš, chvili si upřesnujete dojmy a pojmy a on to pak sám navrhne. Vytvorí pull request, kterej mužes nezavisle otestovat a když to funguje tak udělaš merge a je hotovo. V gitu je krásně vidět celý vývoj krok po kroku a muzes se i vratit. A co my přijde úplně skvělý je jeho pochopení a popsání kodu jako celku. Třeba sem řešil nějakou kalibraci zařízení a vymejšlel jsem to to asi dva měsíce (ještě bez Codexu). Mám tam nejaky numericky derivace, hromadu gonimetrickych funkci a hledaní zavislostí na poloze ramen na kruznici. Udělal jsem to, fungovalo to a mělo to řádově 2000 řádků. Následne jsem mu to předhodil, on popsal bez znalosti problematiky o co mi vlastně jde (na to si přišel sám) navrhl novou metodu pomoci nejmejších čtvercu a nejakyho matematickýho modelu, kterej ani neznam. Celý to ma ted 100 řádků a dělá to to samé jen 10x rychlejc. Když muj program přerostl určitou velikost, tak sem ho požádal, aby to rozdělil do více funkčích nezavislých celku a bum udělal a fungovalo to. A jako bonus navrhl rozdělení do vice thredu tak aby se vzajemne neovlivnovala grafika vykreslovaní a komunikace se zařízením. Představa že řeším, v kterým souboru definuju třídy a jejich metody, který pak jinde používám a pak to rozděluju ručně mě nejak nalákala, ale takhle to bylo za hodinu hotový. ručně bych to ladil ještě ted. Takže ano, třeba v programování je to fakt pomocník. Možná popisuju něco co ostátní dávno používají ale pro mě je to nová záležitost max pár měsícu stará.
Už se těším až popíšeš další úspěchy.
M
velká gratulace k úspěchu. ted už to zbývá jen dodělat.
Mám radost, že moje a hlavně uživatele martyxxx "bádáni" má nové nástupce. Při pohledu na tu fotku úplně vidím svůj stůl s klubkem drátu a cítím ten pocit když poprvé zablikala dioda protože sem to chtěl já.
jak píšeš o Chat gpt, tak musím souhlasit, že je to velký pomocník. Bohužel tenkrát ještě nebyl k dispozici, tak nezbyvalo než to celý pročítat, zkoušet a snažit se o pochopení cizího a někdy i vlastního kodu
Ted si hraju s jednim svým projektem, kterej není uplně malej. Cca 500 000 řádků ve stovkach souborech a používám Codex připojenej na git.
Codex je schopnej to celý projít, navrhnout upravy a ty pak sam implementovat do kodu rozhazeneho po mnoha souborech. Samozřejme že je stále potřeba mit svojí představu jak to má celé fungovat, ale třeba na navrh různých kontrol je to bomba. řekneš mu co chceš, chvili si upřesnujete dojmy a pojmy a on to pak sám navrhne. Vytvorí pull request, kterej mužes nezavisle otestovat a když to funguje tak udělaš merge a je hotovo. V gitu je krásně vidět celý vývoj krok po kroku a muzes se i vratit. A co my přijde úplně skvělý je jeho pochopení a popsání kodu jako celku. Třeba sem řešil nějakou kalibraci zařízení a vymejšlel jsem to to asi dva měsíce (ještě bez Codexu). Mám tam nejaky numericky derivace, hromadu gonimetrickych funkci a hledaní zavislostí na poloze ramen na kruznici. Udělal jsem to, fungovalo to a mělo to řádově 2000 řádků. Následne jsem mu to předhodil, on popsal bez znalosti problematiky o co mi vlastně jde (na to si přišel sám) navrhl novou metodu pomoci nejmejších čtvercu a nejakyho matematickýho modelu, kterej ani neznam. Celý to ma ted 100 řádků a dělá to to samé jen 10x rychlejc. Když muj program přerostl určitou velikost, tak sem ho požádal, aby to rozdělil do více funkčích nezavislých celku a bum udělal a fungovalo to. A jako bonus navrhl rozdělení do vice thredu tak aby se vzajemne neovlivnovala grafika vykreslovaní a komunikace se zařízením. Představa že řeším, v kterým souboru definuju třídy a jejich metody, který pak jinde používám a pak to rozděluju ručně mě nejak nalákala, ale takhle to bylo za hodinu hotový. ručně bych to ladil ještě ted. Takže ano, třeba v programování je to fakt pomocník. Možná popisuju něco co ostátní dávno používají ale pro mě je to nová záležitost max pár měsícu stará.
Už se těším až popíšeš další úspěchy.
M