Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - mhi

Stran: 1 2 [3] 4 5 ... 16
31
Vývoj / Re:STM32 - minimalisticky vyvoj, chyby, objednavky
« kdy: 11. 08. 2020, 16:43:45 »
Chvili jsem koukal na ty decapnute IC a je zjevne, ze to neni klon 1:1. Designy jsou ruzne, GD32xx pouziva dokonce nejspis seriovou flash pamet ! Viz https://www.richis-lab.de/images/STM32/11_02.jpg  ; CKS32F103 je zase dalsi (jiny) design. Pak jsou jeste nejake pro mne uplne nezname a jen castecne kompatibilni SoC.

Nekdy si budu muset pohrat s STM32RV (Risc-V).

Zarazi mne ale ta kompatibilita, to je neco co dle meho nazoru cinan sam moc neumi udelat. Alespon z me zkusenosti, vzdycky tam je nejaky hacek. Mam kod, ktery pouziva rekl bych celkem mezni vlastnosti STM32, treba pokud jde o casovani, DMA, ... a na tom CKS32 to proste chodi "as is". Nekdy vyzkousim jeste USB a CAN.

Gigadevices maji evidentne i "vyssi" procesory, ovsem tam uz vidim rozdily - treba CAN/USBD sdilena pamet ma jinou velikost u STM32 a jinou u GD32.

Jako logicke vysvetleni bych prijal to, ze do ciny pristaly podklady z ST (netlisty/HDL) a cinan dostal za ukol udelat neco, co bude moci prohlasit za vlastni a jen si to slepili dohromady.

32
Vývoj / Re:STM32 - minimalisticky vyvoj, chyby, objednavky
« kdy: 11. 08. 2020, 02:48:46 »
Nekdy to prozkoumam dukladneji, treba to ADC pouzivam s DMA v takovem dost zvlastnim rezimu a stejne to chodi na urovni bin kompatibility. Prislo mi divne, ze by se jim povedlo navrhnout tak "dokonaly" klon nezavisle. Nicmene die vypadaji jinak ... to je pravda. A treba vypis z takove te systemove oblasti flash vypada stejne jako u STM32. Zajimave je https://www.richis-lab.de/STM32.htm ; to mozna rozlouskne spoustu otazek.

Ne ze bych ty CK32F103 / GD32F103 chtel pouzivat, dokonce mam pocit, ze STMcko koupim original levneji nez umim koupit GD32 (mozna proto, ze neumim cinsky a nevim kde to najit levneji :) ).

33
Vývoj / Re:STM32 - minimalisticky vyvoj, chyby, objednavky
« kdy: 10. 08. 2020, 20:57:35 »
Jen pro info, asi jsem to s nekym resil v jinem threadu, ale padla otazka ruznych klonu STM32; aktualne mi na stole pristal bluepill s necim co je oznaceno CKS32F103C8T6 a pod tim napis CKS; pry je to to same jako GigaDevices GD32F103C8T6 ; jedna pani povidala, ze to jsou plagiaty STM32 (gigadevices delaji i Risc-V verzi, ktera by mela mit stejne periferie, takze asi maji v ruce vic nez jen finalni podklady pro vyrobu).

Hodil jsem do toho aplikaci, ktera pouziva GPIO, timery, ADC, chodi to zda se identicky s original STM32F103C8T6. st-link vraci jiny JTAG ID, takze musi byt novejsi st-flash:

st-flash write lcd18.bin  0x8000000
st-flash 1.6.1-88-g0a6fe3a
2020-08-10T20:35:14 INFO common.c: F1xx Medium-density: 20 KiB SRAM, 64 KiB flash in at least 1 KiB pages.
file lcd18.bin md5 checksum: d978fcb81aa72893407eab658b1b98e7, stlink checksum: 0x000bf206
2020-08-10T20:35:14 INFO common.c: Attempting to write 9194 (0x23ea) bytes to stm32 address: 134217728 (0x8000000)
2020-08-10T20:35:14 INFO common.c: Flash page at addr: 0x08000000 erased
2020-08-10T20:35:14 INFO common.c: Flash page at addr: 0x08000400 erased
2020-08-10T20:35:14 INFO common.c: Flash page at addr: 0x08000800 erased
2020-08-10T20:35:15 INFO common.c: Flash page at addr: 0x08000c00 erased
2020-08-10T20:35:15 INFO common.c: Flash page at addr: 0x08001000 erased
2020-08-10T20:35:15 INFO common.c: Flash page at addr: 0x08001400 erased
2020-08-10T20:35:15 INFO common.c: Flash page at addr: 0x08001800 erased
2020-08-10T20:35:15 INFO common.c: Flash page at addr: 0x08001c00 erased
2020-08-10T20:35:15 INFO common.c: Flash page at addr: 0x08002000 erased
2020-08-10T20:35:15 INFO common.c: Finished erasing 9 pages of 1024 (0x400) bytes
2020-08-10T20:35:15 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-08-10T20:35:15 INFO flash_loader.c: Successfully loaded flash loader in sram
  9/9 pages written
2020-08-10T20:35:15 INFO common.c: Starting verification of write complete
2020-08-10T20:35:15 INFO common.c: Flash written and verified! jolly good!



34
Tohle začíná být už jen ztráta času... [...] To potřebuješ vždy mít poslední slovo? [...] Zamysli se [...] potom ti třeba docvakne
Fakt nechápu tvoji agresivitu. Normálně se bavíme o vlastnostech nějakého řešení, co máš za problém?!

offoptic 2: Doporucuji knizku Eric Berne, Jak si lide hraji / Games people play
https://uloz.to/hledej?q=eric+berne  Da se k tomu pripojit i domaci ukol identifikovat hry, ktere se v tomto vlakne hraji (a kterou tady hraju nejspis ted' i ja)

Nedalo mi to :). Slibuju, ze uz sem psat nebudu.

35
Oproti tomu ty "bazmeky" přeprogramuju přes wifi, bez problémů, svobodným softwarem, který bude vždycky existovat, nic neřeším :)

Asi unasim tema do offtopicu, ale jak si uvedomuji, je to pro mne celkem zasadni. Opensource projekty delim pro sebe na 2 kategorie:

- ty delane "seriozne", kde se dba na stabilitu API, format parametru, da se celkem spolehnout na to, ze to co chodilo ve verzi A nejak velmi podobne nebo uplne stejne chodi i ve verzi B. Sem bych zaradil kernel Linuxu, ruzna BSDcka, gcc, binutils, vlastne spoustu veci "ze stare skoly" treba od GNU.

- ty, kde se "rapidne inovuje": Verze B na rozdil od A nemusi mit vubec nejakou funkcionalitu, protoze se mezitim uz zmenila hromada kodu, hromada API, verze B je mnohem "vyspelejsi". Typicke pro tyto projekty je, ze kdyz jsou navazene do neceho dalsiho, tak existuje seznam verzi ktere musite mit  aby to spolu chodilo :-). Pred delsi dobou jsem si hral s gnuradio a tam to presne tak nejak bylo. Navic pohledem do zdrojaku nejakych komponent kde se ty verze nedaly dodrzet se mi casto chtelo zvracet. Proto bych ty uvozovkove vyrazy nahradil spis tvrzenim: nejak jsme to doprasili, bylo to rychle a zadarmo, ale ted' to musime predelat, zase moc nevime jak, ale lepsi nejaka snaha nez zadna.

Takze pokud mate ve svem toolkitu neco z druheho typu, coz je docela pravdepodobne, nejake verze software na programovani sice budete mit, ale otazka je jak moc budou za 10 let pouzitelne.

Samozrejme u komercniho prostredi to je uplne to same, treba ja mam na par historickych projektu stary prekladac C18 od Microchipu a udrzuju si kod jednoduse tak, aby to v nem slo vzdy prelozit (je to nekdy jako se drbat levou nohou za pravym uchem).

36
Vývoj / Re:Windows API - typové aliasy
« kdy: 06. 08. 2020, 19:26:11 »
Ted' jsem si uvedomil jak pri programovani dbam na to, abych nepouzival 'nebezpecna' jmena typu to minmax a jmena API funkci, i kdyz tam beru jen ty co znam a ten zbytek mi nedelal problemy, mozna kvuli tomu ze makra maji parametry a zatim jsem se netrefil.

Popravde receno nechapu, proc dualitu xxxW/xxxA nevyresili nejak jinak.

37
Vývoj / Re:Windows API - typové aliasy
« kdy: 06. 08. 2020, 14:25:54 »
Pokud se vám #include <windows.h> rozuteče po větším projektu, tak vaše zadek pozná středověk.
Windows.h definuje mračno nenápadných a maximálně destruktivních maker, které můžou dělat neskutečný binec při překladu a linkování.

To mne pobavilo :-). Muzete nejaka makra zminit ?  Ono tam toho je dost co muze byt potenc. nebezpecne, ale pri trose opatrnosti v tom nevidim takovy problem, API jako takove mi prijde celkem rozumne navrzene, doprasili to IMHO az zmenami, kdy uz v MS nejspis puvodni architekti z VMS nebyli...

38
Vývoj / Re:Software-only USB host
« kdy: 26. 07. 2020, 23:56:04 »
No moment, vzdyt je to NRZI s bitstuffingem, takze to neni az tak jednoduche. Vezmu-li STM32 s nejakym Cortex-M3(-M4) na 72MHz, tak mam na jednu J/K transition zjednodusene 6 taktu a v tom urcite nespocitam aktivni cas po ktery ma bezet u TX dany stav (J,K), ani u RX nezjistim kolik jakych bitu mam prihodit do bitstreamu, natoz abych to tam prihodil a ulozil. Vse v meznich pripadech, ale ty jsou jedine podstatne. Neprisel jsem na to jak to udelat jinak, takze ten megabuffer na casy, ktery sezere hromadu pameti (tech neco okolo 637 bitu + rekneme 520 B jako buffer pro dekodovany paket).

Technicka otazka, mel jsem takovou predstavu, ze bych to neresil skrze interrupty, ale ciste SW s tim, ze po timeoutu (1ms) by se USB zarizeni znovu probouzelo. Nejsem si jist, zda je takovy pristup mozny/prakticky.

39
Vývoj / Re:Software-only USB host
« kdy: 26. 07. 2020, 19:01:30 »
Chvili jsem ted koukal na to USBcko a FS device (12Mbps) neni az zase takova sranda. Resp. nejak to asi pujde dat dohromady za predpokladu, ze prijem dat budu nejprve sypat do nejakeho bufferu casy zmen signalu a dekodovat az ex post, protoze to nestiham (dalo se cekat...).

Jako neznalek si kladu otazku jake pakety pouziva mass storage device, hlavne jak jsou ty nejdelsi pakety dlouhe. Tusite nekdo? Podle me je to 64*8 bitu + 8+8 (SYNC,PID) + 16 (CKS) + 3b, do toho muze prijit az cca 90 bitstuffovych bitu...

A pak je samozrejme otazka co se stane kdyz nestihnu poslat nejaky paket dostatecne rychle vcas, protoze si nemyslim, ze dekodovat to budu umet az zase  tak rychle.

Myslenka je tedy zatim takova:

timing_buf bude obsahovat casy segmentu (format bude rozdilny pro odesilani a prijem, u odesilani asi muzu jit po bytech, ale u prijmu budu nejspis zapisovat najednou 4 bity)

Odesilani bude probihat nejspis tak, ze se do timging_buf napocitaji prechody J-K stavu, ktere se pak pomoci jednoducheho cyklu odeslou.

Prijem bude fungovat tak, ze si budu zapisovat do timing_buf  jednotlive casy zmen JK (otazkou je, zda vubec budu stihat dekodovat dif. D+/D- signal!) do doby nez zaplnim buffer, nebo timer prekroci hodnotu 6*83,3ns.; nasledovat by melo prekodovani do stavu (J-K) a dekodovani.

zlepseni ze bych misto casu jen ukladal nejakou bitovou delku+stav (J,K,SE0,error) asi nepujde, protoze i kdybych predpocital tabulku prevadejici cas na pocet zakladnich jednotek, ten pametovy pristup mi to prilis zpomali...

40
Odkladiště / Re:Židle k PC do 6k
« kdy: 26. 07. 2020, 14:45:54 »
Dříve jsem měl vždy kože[né|nkové] židle, a byly super na údržbu, ale hrozně se mi potily záda, tak jsem minulý rok koupil židli se síťkou, co týden čistím, a stejně je pořád zaprášená a nebo taková "ušmudlaná", a nedaří se mi ničím ji pořádně "vyčistit".

Mam taky takovou, cistim to kompresorem (stlaceny vzduch). Bohuzel se mi uz prodrel za ty roky sedak, jestli nekdo tusite kde na to koupit material, klidne bych si to rucne nasil, zidle mi vyhovuje a uz ji neumim znovu koupit.

41
Odkladiště / Re:Židle k PC do 6k
« kdy: 25. 07. 2020, 23:50:36 »
Ja bych doporucil investovat tisicovku za navstevu fyzioterapeuta a nechal se vysetrit a poradit, lidi z kancelare bude napravovat celkem dost, takze nejakou zkusenost bude mit.

Mne treba rekla, ze rozhodne nemam spat na anatomickych polstarich (koupila mi ho zena), protoze jsem atyp (nejen) fyziologicky a jen mne to poskozuje. Pripomnelo mi to detstvi, kdy se doktorka divila od ceho mam 'tu divnou otlaceninu' na zadech. No, tata preferoval jedinou spravnou zidli, ktera mne konecne nauci sedet poradne :-o, a to i kdybych se v ni mel nanekolikrat zlomit.

Ke zvazeni jsou i takove blbosti jako mit moznost se nekde povesit, to mi casto pomaha pokud zada boli.

Osobne moc nechapu lidi, kteri pracuji na ruznych balonech, klekackach, apod.

42
Vývoj / Re:Software-only USB host
« kdy: 24. 07. 2020, 23:51:55 »
LS hub: nekde jsem videl prave takovy scenar, bylo to snad dokonce v oficialnich USB doku. Ale mozna se pletu, nevim. Z toho jsem doufal, ze by mohla chodit moje obezlicka, pro nejake MCU staci bohate 1,5mbps a zpracovani by bylo jednodussi.

Nejaky cypressacky USB devkit mam taky, kupoval jsem to prave kvuli necemu takovemu (logovat kvanta dat), ale uz jsem se nedostal k tomu s nim neco udelat.

Problem je v tom, ze to dela OBCAS a ja samozrejme poznam ze se to vysypalo az treba za par vterin. Dela to na nekterych pocitacich, zjisteno jenom pod Windows. Bohuzel test typu budu posilat data sem-tam funguje jak ma, je nutne realne pouziti (tzn. i dalsi periferie, atd.). Samozrejme jsem si ve firmware udelal dump pres rychly seriovy port vseho co prichazi po USB (jen stav controlleru) a tam to vypadalo OK, jen Windows jeden z bloku dat neprijaly.

S ohledem na to, ze tam je MCU od Microchipu a vim jake maji jinde 100% demonstrovane problemy  (jednoducha aplikace, ktera spolehlive selhava ... a oni reknou ze to je "vlastnost" a nedaji to ani do errata), nedivil bych se, kdyby byla nejaka bota v tom USBcku, treba nejaka kolize s dalsi periferii, nebo tak neco.

43
Vývoj / Re:Software-only USB host
« kdy: 24. 07. 2020, 18:34:13 »
LS/FS: myslel jsem si to, ale tak treba jsem doufal, ze je nejaky fallback kdyz je po ceste LS HUB, aby na nem slapaly FS zarizeni.

Proc to delat? Potrebuju to v podstate na nejaky vyvoj, a je rozdil jestli na nejakou desku navesim 2 draty USB, nebo resim jiny MCU (kdyz v produktu ma byt neco co nema OTG, to neni o bastleni par kusu kde si muzu koupit doslova co chci). A ten MAX to kompikuje uz uplne extremne-myslim. Nebudu zastirat, ze tam je i vyssi motivace - potrebuju odladit jedno problematicke USB-CDC zarizeni (mam podezreni, ze MCU odesle nejaka data, ktera host nepotvrdi, a vykasle se na retransmit, resp. neco se tam pokoni-nevim co, USB analyzator nemam, tak to asi nasypu do nejakeho FPGA, jakoze poslednich X prenosu).

Mozna jsem naivni a bude to o hodne slozitejsi, ale par sbernic jsem podobnym zpusobem uz implementoval, napr. SAE J1850 (VPW i PWM), navic v pomalem 8bitu :); a tam to byl skutecne masakr. Prvni verze na stole chodila OK, ale pak se objevily ruzne problemy po zapojeni do aut, kdy jsou ruzne nahnile draty, necekane odpory a kapacity vedeni, odpory mezi vodici, ruzne mezni stavy (vynuceny BUS ERR nejakou ridici jednotkou), atd. Ted mne to ceka preimplementovat na ARMa, vubec se na to netesim.

ad DMA: To samozrejme lze pouzit jak na odesilani (pres SPI, GPIO bitbang), i pro prijem, kdy to navesim na capture/compare.

44
Vývoj / Re:Přerušení v Linuxu
« kdy: 24. 07. 2020, 16:09:57 »
Celkem standardni reseni je naprogramovat kernel driver; neni k tomu treba modifikovat kernel tree, driver jde odladit i uplne mimo nej, samozrejme za predpokladu ze z toho bude modul. Neni to az tak slozite, jak se na prvni pohled zda, hlavne kdyz clovek vystaci s nejakym existujicim prikladem - pak neni ani nutne nejak hluboce studovat ruzne locking mechanismy, apod.

Fungovat to pak muze treba tak, ze komunikuju s driverem pres read/write/ioctl bez nejake nutnosti resit realtimovost (tzn. mereni casu probiha v KERNELu, ne userspace).

45
Vývoj / Software-only USB host
« kdy: 24. 07. 2020, 15:37:42 »
Existuje nekolik implementaci ciste SW USB device (nejznamejsi je asi vusb, ale je jich cela rada); tzn. v MCU, ktery nema USB periferii se pomoci 2 GPIO udela softwarove USB zarizeni.

Hodilo by se mi ted opacne reseni, ktere by implementacne nemuselo byt nijak extremne slozite - aby genericky MCU (pocitejme nejaky ARM Cortex-Mx/MIPS na 50+ MHz) umel udelat USB host pro pripojitelny FS device (12Mbps). Cilem je pripojit mass storage, o rychlost tu nejde-spis velikost kodu a nutne periferie hostitelskeho MCU, pocitejme ze pujde pouzit DMA (a nejaky capture/compare, aby byl co nejvetsi offload do HW). Akceptovatelna je i druha alternativa kdy to na chvili plne vytizi MCU a bude to treba i bez interruptu. Znate nekdo nejaky takovy projekt ? Staci mi ta USB komunikace, mass storage se pokusim na to potom nejak naroubovat, pripadne mi staci i nejaka inspirace "jak na to".

Predpokladam, ze to je uplne mimo USB spec, ale je mozne FS zarizeni ktere mi spravne signalizuje pres pullup ze je FS provozovat jako LS, tzn. na 1,5Mbps ? Ze bych mu vnutil LS komunikaci i kdyz je FS ?

Stran: 1 2 [3] 4 5 ... 16