Kedves Fórumtársak!

Lehet-e bascom-ba valamilyen módon bevinni *.hex fájt úgy, hogy az avr tipusát át tudd írni?
Elolvastam TAVIR-os Cseh Robi összes Bascom ját, de ezt nem találtam.
Küldök két egyszerű hex-et.

Köszönöm szépen!

Nem tudom releváns-e, de Device manager alatt milyen driver van most amivel felismeri?
Microchip Tools / AVR Dragon vagy Jungo Connectivity / JTAG ICE mkII (v11 vagy v12)?

AS 6.0 és AS6.2-nek Jungo-ból a régi v11-es driver kell, 7.0-tól pedig van az új Jungó v12-es. Váltani a kettő Jungó között ÍGY lehet.

Nálam most Microchip Tools / AVR Dragon driver van, ezt talán az MPLAB-X rakta fel, ezzel is megy az AS7.

Egyébként mivel szeretnéd használni, AS6.x vagy AS7 vagy más?

Ezek a hex file-ok mivel lettek fordítva és milyen avr-re? És mit szeretnél helyette használni?
A hex a lefordított kód, ezt már visszaolvasni, újrafordítani semmivel nem tudod, de esetleg betölthető más típusba, ha az azonos családból való (16 -> 32 (bár itt van egy apró különbség), 8 -> 8A, stb), de más esetben nem.

Köszönöm a választ!
Megnézem majd a drivereket.
(Most megoldottam a programozást, mert a fiókban találtam egy klón avrispII programozót. Bár ott is probléma volt firmware verzióval, de az kikapcsolható a tools/option részben.)
AS7 volna a cél, mert már felraktam mindkét gépemre a legfrissebb verziót a próbálkozások közben.
...

Ha rádugom a dragon programozót a gépre, akkor Microchip/avr tools jelenik meg. Verió 43.2.0.0 / 2020.10.15 /

A Jungo / atmelwindrv verziója 12.0.0.0 /2015.10.09/
A jungo / windriver verziója 11.5.0.0 /2014.01.26/

Ok, nálam még kicsit régebbiek is a driver-ek.

Az atfw egyébként milyen hibaüzenetet ad?
Esetleg ha megadod neki a -v 10 paramétert akkor sokat szövegel.

Az "atfw.exe -t avrdragon -r" parancs ír ki valami értelmeset?
Nálam az alábbit adja:

Köszönöm kedves Majkimester!

A kérdéses hex atmega8-ra íródott, nekem viszont 328p-m van itthon.
Már az is nagy dolog lenne tőlem, ha a hex-et be tudnám tölteni a bascom-ba, illetve onnan a chip-be... Egy próbát talán megér...
Persze az sem különösebb akadály, ha be kell szereznem néhány chip-et, de ettől elvonatkoztatva mégis jól lenne tudnom, hogyan lehet a hex-el bármit is csinálni.

Előre is köszönöm szépen!

A hex az a kész, futtatható program. Arra való, hogy rátöltsd a mikrokontrollerre. Arra a típusra, amire készült. Nem szerkeszthető, és nem rakható másra.

Azért ne töltsd be bascomba, hogy feltöltsd a chipbe. Avrdude feltölti neked bascom nélkül.

A bascommal lehet csak hex-et égetni. A programozó fülön, file menü megnyitás, fájltípusnál kiválaszt hex, és onnantól sima égetés, de természetesen csak olyan chipre amire íródott, és azt sem árt tudni milyenek a fuse bitek....

Köszönöm szépen kedves Barátaim!
A megoldás tehát, ha szerzek Avrdude-t, és az majd elintézi nekem...
Köszönöm még egyszer.

Sziasztok,

ötleteket szeretnék kérni tőletek egy elég érdekes hibához, amit már lassan csak a szellemjárásra tudok fogni.

Alaphelyzet:
Fórumtárssal elkezdtünk okosotthonhoz áramkört készíteni. Furatszerelt Atmega328P az alapja, Arduino fejlesztőkörnyezettel készült a kód. ENC28J60-nal hálózatra van kötve. Van 5 gomb, ezek a PC0, PD4,PD3, PD1,PD0 pinekre vannak kötve. Első körben csak annyit próbálunk megvalósítani, hogy a gombnyomásokat udp-n jelentse magáról. Ezt először MQTT-vel próbáltam, most már csak UDP-vel.

Annyit tud, hogy adott gomb elengedésekor udp-n 1 szem bájtot küld egy megadott portra attól függően, hogy a gomb el lett engedve, lenyomták, vagy hosszan nyomva tartják. És kizárólag állapotváltáskor küld 1-1 csomagot, szóval nyomva tartás esetén nem bombáz folyamatosan, csak az állapotváltás tényét jelenti.
Ez a PD0 pin kivételével jól is működik, viszont ha ezen a pinen nyomkodjuk a gombot, teljesen random fogja magát, és lefagy az egész AVR. Van, hogy azonnal, van, hogy csak 10-15 gombnyomás után. Ami érdekesség, hogy ha sok percig békén hagyjuk a panelt, akkor utána megint kibírja a nyomkodást.
Ez a pin egyébként az UART RX, de setup() elején azzal kezdem, hogy letiltom a serialt minden lehetséges módon, a gombok pergésmentesítve vannak és minden jelentés után van 250ms non-blocking szünet, amikor direkt nincs gombolvasás, hogy ha valami van pufferben, az tudjon ürülni.
Bónusz infó, hogy 3.3V-on megy az egész panel, így a 16MHz-es kvarc az bukó, 8MHz-en megy az egész.
Erre valakinek van ötlete, hogy ez tényleg szellemjárás, vagy én nézek be nagyon valamit?

> teljesen random fogja magát, és lefagy az egész AVR.
csiphőmérő szerint, vagy az ujjaddal érzed, hogy 0 fok alatt van?

A viccet félretéve, a program és a pontosabb jelenség leírás nélkül nagyon nehéz egy ilyet távgyógyítani. Oszd meg a programot velünk, és írd le pontosabban, hogy mit csinál a rendszer amikor "le van fagyva".

Gondolom ha saját NYÁK, akkor fixen nincsen rajta USB-uart illesztő, hanem csak a felprogramozáshoz dugod rá, igaz? Ha rajta van, akkor esetleg elektronikai problémát okozhat, hogy a gomb gondolom 0-ba húzza az RX bemenetet, az USB UART pedig magasba, tehát effektív rövidzárlat van. Vagy esetleg a PIN rosszul van konfigurálva? Megmérném, hogy a benyomott gomb mekkora árammal működik, és mennyire húzza le a PIN-t. (A gombot egy ellenállással bezárva mérnék feszültségeket és áramot.)

Vagy rendes SPI programozóval programozod fel a csipet, nem az Arduino bootloaderrel? Erre tippelnék, mert a CPU óra átállítása után nem triviális a Serialon keresztüli programozás.

A belső 8MHz órával nem szokott gond lenni, erre nem gyanakodnék.

A programban ha hiba van, azt úgy szoktam debuggolni, hogy vagy létesítek serial kapcsolatot a PC-vel, és arra debug üzeneteket küldök (emiatt a HW serial pinjeit nem szoktam semmi funkcióra se használni), vagy legalább egy PIN-t pöcögtetek a kódból stratégiai pontokon. Ezzel megfigyelhetővé válik, hogy mit csinál a program. Például láthatóvá válik, hogy hol térül el a kód. Persze elvben debuggolni is lehet, de még sosem debuggoltam ezeket a csipeket debuggerrel.

"Fagyást" C-ben írt program végtelen ciklussal, végtelen önrekurzióval, vagy rosszul felkonfigurált interrupttal szokott csinálni.

Olyan, mintha a PD0 vagy fel lenne cserélve a kristály bemenettel, vagy köze lenne azokhoz a pinekhez, esetleg valamit lesöntöl. Meg van tisztítva a nyák?

Köszi a választ



Van egy 8 másodperces watchdog, ami újravágja. Induláskor 2 pulzálást csinálok az egyik PWM porton, amikor megtörténik a baj, akkor ezt mindig lejátssza, mint a program elejét. Watchdog nélkül pedig simán egyszer csak se előre, se hátra, nem csinál semmit.

Ciklusos fagyás részemről elvileg nem lehet, maximum azt tudom elképzelni, hogy az enc28 könyvtárában van valami, ami összeveszik az uart rx lábbal bizonyos esetekben, viszont nem jövök rá, hogy mi.

A kódot csatoltam, ez már megbolondul sajnos.
Egyéb paneleket én is úgy debugolok, hogy serialon jelzek vissza, ennek a panelnek ilyesmi debuggere viszont nincs.
Programozás az külsőleg történik, uart egyátalán nincs használva.

Teljesen tiszta, gyári JLCPCB-s. Én is tippeltem ilyesmire, de ki lett mérve, normális feszültségszintek vannak, az áram nem rohan el. És az az érdekes, hogy ha pihentetve van a panel, akkor utána megint bírja azt az x lenyomást fagyásig. Mintha valami puffer feltelne, ami csak nagyon lassan tud ürülni.

Ilyen hibákat egy tömb túlírása szokott okozni, és/vagy pointer problémák.

Az enc könyvtár használhatja a soros portot debugra, ha a ENC28J60DEBUG be van állítva.

Egyébként az ENC driver nem tudom mennyire megbízható. Én 2012-ben játszottam az ENC28-cal. A netről vettem egy kódot, meg néztem az akkori arduinós lib kódját is, és abból gyúrtam saját drivert AVR studio alatt. A lényeg, hogy nem volt megbízható. Fognom kellet az ENC errata doksiját és pontról pontra implementálni az összes workaroundot. Ezt meg is tettem. Most belenézve a fent linkelt driverben még mindig nincs benne minden. Például fogadásnál pattern match filtert használ, de arra is van errata:
ENC28J60 Rev. B7 Silicon Errata point 18: Pattern Match receive filter not reliable

A lényeg a lényeg, minden workaround után nekem stabilan ment hetekig. Bejövő UDP packet-re válaszolt az eszköz. de hetek múlva egyszer csak már nem. Akkor arra jutottam, hogy a hiba az ENC fogadásában van, és feladtam.

Köszönöm a válaszokat.
Sajnos eddig sem volt debugra állítva a lib semennyire. Viszont ez már az UIPEthernet helyett az EthernetENC lib, ebben ahogy látom már több fix bekerült. Nálunk érdekes, nem a fogadással van baj, hanem a küldéssel. Ami azért is furcsa, mert ha a panel küld 5 másodpercenként életjelet, azt korlátlan ideig tudja udp-vel. Viszont ha gombnyomogatással egybe van fűzve, akkor csattan el. AVR-re akárhogy szórjuk az adatot, azt bírja.

Szia!

Kicsit sok dolog halmozódott fel így az év végén, elmaradt a korábbi probléma kezelése. DE , nem is oldódott meg magától.

Az általad javasolt parancsra ez volt a rendszer válasza:
Found avrdragon:00A20001058A
GenericError thrown during firmware upgrade
Failed to read from tool. Bad signon response: premature packet end (size=0).

A "atfw -a dragon_fw.zip -t avrdragon" parancs ezzel a hibával állt meg:
Found avrdragon:00A20001058A
Upgrading avrdragon:00A20001058A
GenericError thrown during firmware upgrade
Bad message start in received packet: 0x16.


A -v 10 opció esetén a következő jelenik meg:
D:\atmel\studio\7.0\atbackend>atfw -a dragon_fw.zip -t avrdragon -10
Found avrdragon:00A20001058A
Upgrading avrdragon:00A20001058A
GenericError thrown during firmware upgrade
Bad message start in received packet: 0x00.

D:\atmel\studio\7.0\atbackend>atfw -a dragon_fw.zip -t avrdragon -v 10
←[39m20:32:39: [init] Initializing logging subsystem ←[0m
←[39m20:32:39: [init] Logging to file: C:\Users\vacer\AppData\Local\Temp\atfw.48fb-db1e-f467-775a.log ←[0m
←[39m20:32:39: [init] Finished initializing logging subsystem ←[0m
←[37m20:32:39: [cli] Starting execute stage ←[0m
←[37m20:32:39: [cli] Enumerating connected tools and serial numbers: ←[0m
←[37m20:32:39: [mplabcomm::library] Starting library controll: session=0, list=0 ←[0m
←[37m20:32:39: [mplabcomm::library] Unloading access link: list=0, session=0 ←[0m
←[37m20:32:39: [cli] 00A20001058A ←[0m
←[37m20:32:41: [cli] No serial number given ←[0m
←[37m20:32:41: [cli] Choosing first serial ←[0m
←[39m20:32:41: [cli] Found ←[0m
←[39m20:32:41: [cli] avrdragon ←[0m
←[39m20:32:41: [cli] : ←[0m
←[39m20:32:41: [cli] 00A20001058A ←[0m
←[37m20:32:41: [cli] Creating upgrader for avrdragon(00A20001058A) ←[0m
←[37m20:32:41: [mplabcomm::library] Starting library controll: session=0, list=1 ←[0m
←[37m20:32:41: [cli] Have upgrader, continue ←[0m
←[37m20:32:41: [cli] Start reading firmware from archive dragon_fw.zip ←[0m
←[37m20:32:41: [fw] Temporary firmware directory: 'C:\Users\vacer\AppData\Local\Temp\521b-0d7a-ada3-2f83' ←[0m
←[37m20:32:41: [fw] Parsing firmware manifest ←[0m
←[37m20:32:41: [cli] Finished reading firmware from archive ←[0m
←[39m20:32:41: [cli] Upgrading avrdragon:00A20001058A ←[0m
←[37m20:32:41: [cli] Connect; Application ←[0m
←[37m20:32:41: [mplabcomm] Find count (1) => 1 ←[0m
←[37m20:32:41: [mplabcomm] Find [0] => 1:=03EB:=2107:=0100:=ATMEL:=AVRBLDR:=00A20001058A:=x:=b:=0:=0:=end ←[0m
←[37m20:32:41: [mplabcomm] Open device (1,0) => MPLABCOMM_NO_ERROR ←[0m
←[37m20:32:41: [cli] Connect; Switch to upgrade mode ←[0m
←[37m20:32:41: [dbg] Starting JTAGICE MKII response and event reader thread. ←[0m
←[37m20:32:41: [dbg] Started JTAGICE response and event reader thread. ←[0m
←[37m20:32:41: [pro] JtagIceMkiiProtocol::signOn() ←[0m
←[37m20:32:41: [usb] USB write at endpoint=2 count = 11 b: [1B 00 00 01 00 00 00 0E 01 F3 97] ←[0m
←[37m20:32:41: [pro] JtagIceMkii <<< 01 ←[0m
←[1m←[33m20:32:41: [] The USB device has been disconnected ←[0m
←[1m←[31m20:32:46: [] jtagice mkii: timed out waiting for response to command 0x1. ←[0m
←[1m←[31m20:32:46: [pro] Failed to execute command with ID 0x01
←[0m
←[37m20:32:46: [usb] USB write at endpoint=2 count = 11 b: [1B 01 00 01 00 00 00 0E 01 4C 16] ←[0m
←[1m←[31m20:32:46: [pro] Failed to execute command with ID 0x01
. The USB device has been disconnected ←[0m
←[37m20:32:46: [usb] USB write at endpoint=2 count = 11 b: [1B 01 00 01 00 00 00 0E 01 4C 16] ←[0m
←[1m←[31m20:32:46: [pro] Failed to execute command with ID 0x01
. The USB device has been disconnected ←[0m
←[37m20:32:46: [dbg] Trying to end JTAGICE mkII response and event reader thread... ←[0m
←[37m20:32:51: [mplabcomm] Disconnect (1,0) => MPLABCOMM_NO_ERROR ←[0m
←[37m20:32:51: [cli] Connect; Upgrade Mode ←[0m
←[37m20:32:51: [mplabcomm] Find count (1) => 1 ←[0m
←[37m20:32:51: [mplabcomm] Find [0] => 1:=03EB:=2107:=0100:=ATMEL:=AVRBLDR:=00A20001058A:=x:=b:=0:=0:=end ←[0m
←[37m20:32:51: [mplabcomm] Open device (1,0) => MPLABCOMM_NO_ERROR ←[0m
←[37m20:32:51: [cli] Sleep ←[0m
←[37m20:32:52: [pro] BootProtocol::signOn() ←[0m
←[37m20:32:52: [pro] Bootloader <<< 31 ←[0m
←[37m20:32:52: [usb] USB write at endpoint=2 count = 2 b: [31 20] ←[0m
←[1m←[31m20:32:52: [usb] Error code -10433 from MPLABCOMM when reading packet: [Nem lÚtez§ eszk÷zt adtak meg.
] ←[0m
←[39m20:32:52: [cli] CoreException thrown during firmware upgrade ←[0m
←[39m20:32:52: [cli] Error code -10433 from MPLABCOMM when reading packet: [Nem lÚtez§ eszk÷zt adtak meg.
] ←[0m
←[37m20:32:52: [mplabcomm] Disconnect (1,0) => MPLABCOMM_NO_ERROR ←[0m
←[37m20:32:52: [mplabcomm::library] Unloading access link: list=1, session=0 ←[0m
←[37m20:32:52: [fw] Deleting directory: 'C:\Users\vacer\AppData\Local\Temp\521b-0d7a-ada3-2f83' ←[0m

Hát nem tudom, hogy ebből Te mit látsz. Én azt, hogy szívó ágon vagyok....

Üdv!
Z.

Na igen, a neten csak annyit írnak erről hogy a dragon bootloader módban ragadt, és az atwf segít.
Amit még nézz meg szerintem, hogy meg van-e ténylegesen az 5V az USB porton. Nekem régen még ezzel voltak problémám, már nem emlékszem dragon vagy a Jtag ICE clone volt akkor, de kevés volt az USB feszültség. (A dragon erre tönkre is mehet)

Próbáld ki másik USB porton, lehetőleg desktop gépnél hátsó alaplapival meg esetleg másik kábellel. Ha van lehetőség akkor másik gépen, ahol frissen telepítesz AS7-et.

A helyzet az, hogy már 3 gépen is kipróbáltam, s 3 különböző kábellel is.
Azt még ugyan nem néztem meg, hogy +5V van-e az USB csatlakozón, de szerintem azzal nem lehet gond 3 gépen is.

Egyre inkább az az érzésem, hogy gyengéd búcsút kell vennem ettől a sárkánytól...

Köszönöm fáradozásod!

ATMega 328-P-re kötnék egy ZS-042 óramodult és egy 4 db, 8 bites láncba kötött TPIC6C596N-ből készült shift regisztert.
Szerintetek az TWI-vel (SCL, SDA) fel tudnám tölteni a 4 byte-nyi adatot úgy, hogy (nem egyidőben) tudjam kiolvasni vagy írni az RTC-t?

Miért pont az SCL és SDA használata a célod, nem maradt több szabad láb? Vagy lehet nem értem, hogy mi lenne a cél. SCL és SDA lábakra kötnéd az RTC-t is, meg a shift regisztereket is és külön szeretnéd őket piszkálni?

Gondoltam, hogy van olyan üzemmódja a TWI-nek ami kitolja a 32 bitet órajellel szinkronizálva.
De lehet nem jó ötlet.
Akkor megírok egy rutint ami 1 byte-ot kitol órajelezve másik két porton.

Szerintem kevered a TWI-t és az SPI-t:

Az SPI az ami lényegében egy shift regiszter meghajtás egyszerre ki és beshifteléssel.

A TWI pedig az I2C-nek egy kompatibilisnek ígért változata (úgy hallottam, hogy az I2C név használatáért licensz díjat kellett volna fizetni, ezért nevezték el I2C-nek, meg talán valami funkció nincs is megvalósítva, ami nélkül lehet élni, de az I2C-nek kötelező része).

A shift regiszterben és az SPI-ben az a jó, hogy teljesen a master határozza meg az órajelet, ezért nagyon egyszerű szoftveresen is megvalósítani, illetve érzéketlen rá, ha akár a kommunikáció közepén is jön egy interrupt. Kábé egyszerűbb implementálni pinpiszkálással, mint az SPI dokumentációját megérteni az adatlapon. Cserébe a slave oldalon azonnal reagálni kell az órajelre, de legalábbis egy specifikált időn belül, amennyit a master kivár. A hardveres shift regisztereket akár órajelenként változó jellel is hajthatjuk ha nem túl hosszú a drót amivel be vannak kötve, így még várakozás sem kell a programba.

Mindenkinek kösz. Akkor az RTC-t hajtom a TWI-vel a shift regiszterekre meg írok egy kis szubrutint ami 4 byte-ot kiküld.

Sziasztok!

Pár hete építettem egy GPS alapú nyomkövető kütyüt egy cégnek.
A lényege hogy ha igény van rá, akkor rá tudnak nézni az adott eszközre, és látják hogy hol van, merre halad. Ez nem állandóan üzemelő eszköz, ha kérés érkezik akkor egy ESP32 végzi az Arduino Mega felélesztését, ami átadja az adatokat az ESP-nek, az pedig megjeleníti a kért adatokat és folyamatosan ébren marad amíg nézik. De ez a része lényegtelen. A fő probléma az Arduino Mega és a GPS modul között lehet.

Vannak ezek az RC-ben nagyon elterjedt iránytűs+gps -es modulok:
https://www.ubuy.hu/en/product/20LH1GQW-gps-module-gps-neo-m8n-bds-...precis

Nem pont ezt a típust tettem be, de ezek nagyjából egyformák. Bár a nyáklapon nem látszódik, de 5V toleráns, van rajta 3,3V regulátor, nyilván a GPS és a HMC5883 iránytű chip is erről a feszültségről üzemel.

Az iránytű SDA, SCL lábára ugye kell egy pull-up ellenállás hogy jól működjön. A gond az, hogy én az 5V-ra húztam fel ellenállással, nem a 3,3V-ra. Illetve a GPS modul TX-RX lába közvetlenül megy az Arduino Serial portjára.

1. Az i2C eszközök alapból 3,3V-os logikai jeleket használnak. Nagyon nagy hülyeséget csináltam hogy 5V-ra tettem a pull-up ellenállások végét? 2 hete használják, teljesen jól működik. Ettől függetlenül hamarosan várható hogy bekrepál? Általában óránként kapcsolják be 5-10 perce max.
2. A GPS modul TX-RX lábaira kellett volna tennem valamit, vagy az UART elbírja az 5V-ot? Illetve az is lehet hogy a GPS modul nyákján van ellenállás...

Azt elfelejtettem írni, hogy 4,7K-s ellenállásokat használok pull-up-nak.

illetve olyat is olvastam, hogy az i2C Open Drain rendszer (bármit is jelentsen) így nem igazán okoz kárt benne ha 5V-ra van felhúzva

Miért kellett az Arduino Mega? Mi olyat csinál, amit az ESP32 egyedül nem tudna? Ha semmit, akkor sokkal egyszerűbb lenne csak azt használni. Nem lenne jelszint illesztés, és kevesebbet is fogasztana. Ha mégis kell az AVR, akkor az is mehetne 3.3 voltról, nem kötelező 5 voltról járatni.

Természetesen mindennek megvan az oka. Tisztában vagyok vele hogy az ESP32 alapból 3,3-on megy. De nekem mégis kellett a Mega.

Csak az érdekelt volna hogy mennyire törvényszerű hogy kinyírom az 5V-ra pull-upolt i2C lábakat, illetve ha ez be is következik akkor mennyire korán. Mert ha 1-2 évnyi használat után durran el akkor nincs para mert ezek évente rotálva vannak.

Tegnap kicsit méregettem. Egy próbarendszeren lemértem, hogy a 3,3V-ra pull-upolt SDA, SCL vonalakon 3,4V van jelen. Ha 5V-ra húztam fel akkor pedig 3,8 V. Nyilván tudom hogy ez nem egészséges, de legalább nem az 5V megy rajta telibe. Kérdés hogy mennyire tolerálja ezt a HMC5883.

Ahogy már említettem ezt viszonylag ritkán kapcsolják be, akkor is rövid ideig megy.