Fórum témák
» Több friss téma |
Nem akarok folyamatosan adatot küldn433Mhz en mert le is merülne a távirányító eleme. Csak akkor fog sugározni amikor gombot nyomok.
ESP szerű wifi cuccot azért nem akartam mert pofon egyszerűt szeretnék nincs időm adatlapokat böngészgetni hogy ESP hogy smint megy. Ezeknél a 433Mhz es moduloknál meg elvileg ami a DATA bemenére megy jel az kijön a receiver oldaon 1:1 ben. A hozzászólás módosítva: Feb 5, 2023
Akkor használhatod, DE
1. egyik ismerősnél a hatótáv kritikán aluli volt, hasonló modullal, lehet hogy az antennátval játszami kell 2. Ezek nem rs232 jelre vannak kitalálva, hanem "ön órázó" bitfolyamra, vagyis minden bithez tartozik impulzus, és az impulzus szélessége mondja meg hogy 0 vagy 1. Az rs232-nél igen hosszú ideig lehet 1 v. 0 az adott jel, nem javasolt. Ezek ASK (mint az AM) modulációt használnak, vagyis ha 1 akkor ad, ha 0 akkor nem ad (viszont ilyenkor a szomszéd zavarát is veheti...) pl: https://www.electroschematics.com/holtek-ht12e-encoder-high-density...tions/ Muszály valami szoftveres protokollt köríteni, ami a vételnél meg tudja állapítani hogy korrekt, vagy hibás. hoppá most látom amit linkeltél, már a távirányító gombokhoz tartozó kimenetek aktívak... az adón 4 gomb bemenet van, nem adat...
AZ STM TTL jelet fog ad a kis transmotternek.RS232 szerintem most sehogy sem jön ide. TTL 9600baud soros jel amit saját módon kódolok 5 byte os csomagban nem csak szimplán alacsony vagy magas szóval külső zavartól mentes.Egyedül a hatótáv ami kérdéses és hogy el bír e 9600 baudot vagy esetleg csak kevesebbet mert van ahol 2400 at javasolnak.
Bocsi csak közben látom hogy egy olyan modult mutattam ami pont küder/dekóderes négy kapcsolóra. Végülis ez is jó lehet de itt tényleg fent áll a veszélye hogy bezavar más adó.
Végülis egyszerűbb lenne mert csak vevő oldalon kellene kezelnem már a 4 kapcsoló jelért. Akkor viszont lehet maradok az eredeti ötletemnél és én kódolok saját jelalakot és az megy ki egy direkt transmitter modullalt. Pl ez egy egycsatornás adó modul. Nem tudom milyen lenne
Igen, nézd meg a ht12 vagy a hcs chipek jelformátumát, jobban jársz. Akár kész libraryt is találhatsz hozzá...
Lehet, hogy már késő, de parancsolj: 433 UART stb.
Srácok, tudna esetleg segíteni valaki abban, hogy miképpen tudnám a lehető legminimálisabbra redukálni a következő függvényekből az SPI-s részt?
Idézet: „Ide jönne a kód, de nem engedi illeszteni” Lényegében a HAL_SPI_Transmit() és HAL_SPI_Receive() függvényeket szeretném minimalizálni és ezzel gyorsítani, amennyit csak lehet egy teszt erejéig. Lehetőleg úgy, hogy működőkepés is legyen a dolog. Ha esetleg más library van esetleg erre a célre az is érdekel. A szóvan forgó MCU egy STM32F103RF. Köszi előre is. A hozzászólás módosítva: Feb 13, 2023
De mi a bajod a HAL-os függvényekkel?
Gyorsítani szeretnék egy kicsit az SPI sebességén. Vagy is az utasitasokat akarom ninimálisra csökkenteni. Amire nincs feltétlen szükség az ne is legyen benne.
Hogy mi a baj? Normál esetben semmi, de extrém esetben túl sok sallang van benne. Sok utasítás emiatt pedig sok idő mire egy-egy kérés teljesül. A hozzászólás módosítva: Feb 13, 2023
Szerintem csak minimális gyorsítást tudnál elérni, mert az idő nagy részében amúgy is az SPI művelet befejezésére várakozik. Ha ki akarod váltani, akkor két lehetőséged van:
- a meglevő HAL forrásból kiszeded azokat a részeket amiket feleslegesnek tartasz - regiszter szinten megírod az SPI átvitelt De ha tényleg gyorsítani szeretnél, akkor bevonod a DMA-t is az átvitelbe, így amíg az SPI átvitel tart, csinálhatsz valami teljesen mást.
Használj LL-t HAL helyett.
Használj DMA-t. Ekkor az SPI függvények csak az inicializáláshoz kellenek. Írd meg ASM-ben. Nem tudom, mekkora gyorsulást tud hozni. Az STM32 HAL azért nem Arduino szintű erőforrás pocsékoló kód.
Köszi, sajnos DMA és buffer feltöltése kizárt. ASM-et nem ismerem sajnos.
Minden byte-ot futás közben kell olvasni, van amikor 1-et van amikor 2-őt és van olyan eset mikor 4-et egymást követően, ezek véletlenszerű elrendezésben ezért nem tudom kiszámolni, hogy mikor mekkora buffer kellene, hogy ne keljen feldolgozás közben figyelni, hogy buffer tartalma elegendő e az aktuális feldolgozás számára. Regiszterszinten kellene újra írni, de ha már valaki ezt megtette, akkor nem találnám fel újra a spanyolviaszt. A hozzászólás módosítva: Feb 13, 2023
LL kapcsán az jutott eszembe, hogy keverhető e a HALL-al? Mert nem szívesen inam át az egész projektem. Szerintetek ki lehetne operálni LL-ből és integrálni HAL-ba az SPI-t?
Az előttem szólók szerintem jól leírták. Nem igazán fogsz gyorsítani a HAL egyszerűsítésével. Itt egy példa a regiszterek birizgálásával:
Látható, hogy az idő egy részében várakozik, hogy a flag-ek jelezzék, hogy a byte kiküldésre került. Tehát hiába gyorsítanád az utasításokat, általában a hardverre fog várni. Helyette állítsd fel az SPI órajelét maximumra (30MHz-re?), akkor gyorsulhat az adatátvitel. A HAL-t nem ismerem jól, de tényleg művel felesleges dolgokat. Igazán csak egy logikai analizátor mutatná meg korrekt módon, hogy a HAL-ra vagy az SPI hardverre kell várni egy adott esetben. A hozzászólás módosítva: Feb 13, 2023
Köszönöm srácok, LL lett a nyerő. Brutális a különbség. Tökéletes lett, amit akartam. A 72MHz-nek azért meg vannak a korlátai, de ez sokat dobott a gyorsaságon. Csak az SPI-t tettem LL-be, a többi maradt minden a megszokott HAL-ban.
Sziasztok!
Tudna valaki segíteni STM32F405VGT6 mikrokontroller firmware kiolvasásban/égetésben? Hibás bekötés miatt valószínűleg 24V-ot kaphatott az egyik jel bemenetére. Azóta nem mozgatja a rákötött léptetőket.
Ha túlfeszt kapott simán meghalt. Mutat bármi életjelet?
Ha nem halt meg, és nem te írtad a programját, akkor valószínűleg védve van kiolvasás ellen.
Srácok, remélem nem lesz ördögtől való a kérdésem. STM32F103-as kapcsán felmerült egy másik itteni topikban, hogy túl lehet húzni a gyári 72MHz sebességét. HAL esetében, hogy tudom ezt úgy megtenni, hogy USB ne változzon, mert szükségem lenne rá.
Azt olvasom több helyen is, hogy akár 128MHz-re is fel lehet tekerni az MCU sebességét. Eredeti MCU-t használok saját panelon 8MHz-es kristállyal. Nincs véletlen valakinek itt egy működő példája HAL meglévő SystemClock_Config()-hoz? PLL-t módosítgatom, teszteltem, de szükséges lenne egy megfelelő teljes beállításra, hogy minden működjön rendesen. Köszi előre is.
Habár a legtöbb kontrollernél működik a dolog, sajnos pont ennél a típusnál nem fog menni. A 128MHz-el ugyan fog működni, de az USB osztó ennél a típusnál csak 1, vagy 1.5 lehet. Így sehogy sem jön ki a 48 MHz.
És véleményed szerint a program elindulása után van esély mondjuk egy gombnyomásra a rendszer sebesség újrakonfigurálására? Tehát, ha nem kell az USB, akkor mehetne magasabb órajelen, ha kell, akkor meg vissza állítani. Vagy ha vissza nem is menne az USB illesztése miatt az nem is lenne nagy baj, csak mondjuk újra konfigurálni egy gombnyomásra.
Melegszik. Túlságosan is. Vagyis a tápjából eljut valami a mikrokontrollerig. A rákötött léptető meg cincog, de nem mozdul. Alaposabban nem mertem tesztelni a melegedés miatt.
Ipari cucc, úgyhogy feltételezem védve van kiolvasás ellen, de hát a páncéltermeket is zárva tartják... Olyat keresnék, aki a feltételezhető védelem ellenére is ki tudná olvasni. Egy százast megérne nekem a javítás (ovasás-írás-csere). Egyébként erről van szó: Kloehn Cadent 6 syringe pump
Ha melegszik, akkor valószínűleg meghalt. Kérdés, mi maradt épen a flash tartalomból. Valószínűleg sérült az is.
Ha a gyártó bekapcsolta az RDP level 2 szintet, akkor az a debug áramkör kapcsolatát fizikailag megsemmisítette az IC-n belül. Onnan egyszerűen már nem lehet visszahozni. Korábban láttam orosz és kínai hirdetéseket. Elküldöd nekik, és párezer dollárért kiolvassák. Itthon ilyen hirdetéssel még nem találkoztam
Egy ukrán leírást találtam arról, hogyan kellene. De nem megtanulni akarom, csak visszapréselni a működtető füstöt. Keletre nem küldeném. Csak rossz tapasztalataim vannak. A gyártó meg azt mondta, vegyünk másikat.
Hol lehet olyan hardver hekkert találni, aki leköszörüli a tetejét, és hozzáfér a beléhez? Belföldön nincs meg ez a szaktudás? Idézet: „Egy ukrán leírást találtam arról, hogyan kellene.” Én még nem láttam ilyet. Idézet: „A gyártó meg azt mondta, vegyünk másikat.” Teljes készüléket? Nem adnak csak elektronikát? Csúnya dolog. Idézet: „visszapréselni a működtető füstöt” Na, az nem fog menni. És simán lehet, hogy a flash tartalom is sérült. Idézet: „Belföldön nincs meg ez a szaktudás?” Biztos van ilyen. De tudtommal nem legális. Leszedheti a tetejét, belenézhet, de a kiolvasott kódot nem adhatja oda másnak. Szóval legálisan csak a gyártó segíthet rajtad. Idézet: „leköszörüli a tetejét, és hozzáfér a beléhez” Meg egy pásztázó elektronmikroszkóppal is rendelkezzen... Reverse engineering Flash EEPROM memories using Scanning Electron M...oscopy A hozzászólás módosítva: Feb 14, 2023
A kontroller tudja. Kérdés a PC mit szól hozzá, azt nem tudom. Itt közben csomagok veszhetnek el.
A SEM nem gond. Van éppen kéznél. De aranyozás után nem hiszem, hogy áramot lehet rá adni.
Próbálkozok, egyelőre nem működik ahogy akarom. Normál 72MHz-es állapotban indítom, majd gombnyomásra akarnék váltani 128MHz-es módra. De nem váltja át, most keresem, hogy még milyen regisztereket ír át a CubeMX. Most a SystemClock_Config() függvényt futtatom le alap esetben, ekkor van USB, majd ha kell, akkor a SystemClock_Config_128MHz() névre kereszteltet. Váltania kellene, legalább is így gondolom. Valami még hiányzik.
HAL_RCC_DeInit() megoldotta a problémám..
Köszi srácok, kísérletezek vele kicsit. Most szedi a bakancsát rendesen.. |
Bejelentkezés
Hirdetés |