Fórum témák
» Több friss téma |
Skill bővítésSziasztok!Én is most merülnék bele az ARM világba. Anno sok évvel ezelőtt beszereztem egy STM32F407Discovery board-ot, és csináltam is vele 1-2 hello world programot, de annyi. 15 éve PIC-ezek (8 bit, asm) és PC-n programozok (ez utóbbit munkahelyen is). Viszont szeretnék kicsit piacképesebb lenni, gondolom az ARM-es fejlesztést jobban honorálják. Az iparban/cégeknél melyik család az elterjedtebb? Láttam pont itt előttem tárgyaltátok, hogy az ST kicsit problémás, de én lehet mégis ezt választanám. A terv, hogy HAL, LL, bare-metal szinteket kb. ebben a sorrendben sajátítom el. És ha már van egy board-om, kezdem azzal. Felraktam a STM32CubeIDE és STM32CubeMX progikat (most már külön vannak, régen egybe voltak), és össze is ütöttem egy progit. Tetszik hogy a CubeMX-ben bármit módosítok, rányomok a kódgenerálásra, és az IDE-ben is rögtön változik az érintett kód. Csak mielőtt nagyon belemerülnék kérdezem, hogy érdemes-e. Egyelőre azt látom, hogy ez az egyik legelterjedtebb/legtámogatottabb/legmegbízhatóbb (mármint az ST). Illetve, van-e valakinek tapasztalata a munkaerőpiacon a témában... Előre is köszönöm!
Fél szemmel a RISC-V felé is érdemes odanézni, mert az is terjed...
Gondolom a licenszdíj kötöttsége (illetve, annak hiánya) miatt.
Ebben lehet valami. Egyre több kiforrott mag lesz, egy idő után megfontolandó lesz a cégeknek váltani, vagy mennek a süllyesztőbe ha az lesz uralkodó. Persze ez most még erős feltételezés. Most nézem, az ESP32C szériája már nem a korábbi Xtensa-t használja, hanem RISC-V-t.
"az ESP32C szériája már nem"
A C5 használata komolyan tervben van, persze csak hobbiként. Pár hónapja még ott tartott a dolog, hogy az SDK (mármint az ESP-IDF) nem volt hibátlan, ill. tán funkcióiban sem volt teljes az új procikhoz. A hozzászólás módosítva: Szo, 13:34
Az sima esp32, vagy S3 dual core proci nekem szimpatikusabb
Belső oszci pontosságNa belevágtam, egyelőre még csak HAL szinten.Ami kicsit aggaszt, hogy irgalmatlan sok beállítást látok egy egyszerű bármilyen periféria beindításához. Ezeket fejből vágni.. Hát eléggé ki vagyok egyelőre szolgáltatva a CubeMX kódgenerátornak és AI-nak. Ja igen, a lényeg ![]() Van valakinek gyakorlati tapasztalata a STM32G030F6 belső (HSI) 16MHz-es oszcijának pontosságáról? Adatlapban van róla infó, csak nem tudom a gyakorlat mit mutat. PIC-nél szerettem biztosra menni, és általában inkább beraktam egy kvarcot.
A belső oszcillátorokat általában (nem tudom, hogy ennél a típusnál van-e éppen) lehet egy regiszter állítással kicsit hangolni, pontosítani.
Azonban ezzel nem biztos, hogy megoldottad a problémát, mert a hőfüggésük jóval magasabb, mint egy külső oszcillátornak, vagy kvarcnak. Ha pl. kültérbe rakod, vagy melegedő tápegység mellé, akkor a 20Celsius fok helyett egy 50 fokos dobozban akár 2 %-kal is eltérhet egy belső RC oszcillátor frekvenciája. Ha csak LED-et villogtatsz észre sem veszed, de más esetben ez már akár probléma is lehet. Én nem szoktam sajnálni a kb. 3 mm (vagy kisebb) méretű tokozást a panelról. A2 "irgalmatlan sok" beállítást illetően sajnos ez van. A nagyobb, profibb szolgáltatáscsomag magával vonja a több regisztert és a bonyolultabb beállításokat. A gyártók nemhiába adnak kisegítő kódgenerátorokat és API-kat (LL és HAL az ST esetében). Az ST "hitvallása" pedig az általános felhasználás, hogy legyen mindenre is jó, mindent is lehessen benne beállítani. Ezért van egy I2C-hez legalább 7 flag, amit API használata nélkül már kissé időigényes lekezelni. Ez nem csak az ST sajátja, más gyártóknál sem biztos, hogy jobb a helyzet. A hozzászólás módosítva: Hé, 11:13
Köszi!
Idézet: „a hőfüggésük jóval magasabb” Igen, ezen agyalok most, hogy mennyire gáz ez vagy sem. Adatlap szerint -40°C és +85°C között -2% és +1.5% között van a freki drift. Hát lehet maradok inkább a kvarcnál itt is.
Előre nem nyilatkozom, de annyit tudnak már ezek a chipek az I/O-t is beleértve, hogy nem lenne meglepő, ha specializáltabb szeletekre hasadnának és akár többféle architektúra is gyártásban maradna hosszabb távon (és összességében még több funkciót kapnának). Nem is tudom még, hogy ez az alacsony fogyasztású második processzor mire képes.
Szerintem (számomra) az egyik nagy előny és út a profibb megoldások felé, hogy egy ideje az ESP32 chipek az adott nagy memóriákkal és nyolcszoros SPI kapcsolattal (és cache-en át) alkalmasak elfogadható sebességgel (meglehetősen stabil) TLS kommunikációra egy csomó socketen, ami nem annyira gyakori - nincsenek előttem a pontos értékek, de nagy szám lenne ugyanezt még kisebb fogyasztásból megoldani. (Ezeket saját tapasztalatból tudom, írtam egy nagyobb kódot, egy ilyen távvezérelt I/O eszköz még S2-essel is szépen működik egy ismerősnél a falon magára hagyva, de S3-assal még jobb.) Ugyanakkor az eddig olvasottakból inkább úgy látszik, hogy nincs a második processzor automatikusan kihasználva, ahogy az Xtensával, negyede az órajele, vagyis két mag helyett egyen fut minden, ami elvileg sokat lassít az egészen, hiába gyorsabb az új fő mag egy Xtensa magnál. Tehát lehet, hogy a RISC-V vonal kicsit másra lesz alkalmas - vagy hamar kihoznak újabb változatokat, amik gyorsabbak... Persze a saját írásom helyett inkább másokat kellene olvasgatni a konkrét információkkal, csak léteznek már... : -) A hozzászólás módosítva: Hé, 14:18
|
Bejelentkezés
Hirdetés |












