Sziasztok!

Valaki elmondaná mi a különbség - vagy inkább melyik a jobb nekem - a két modul között? NEMA17 steppermotorhoz szeretném, fordulatszám szabályozással.

L298N-MOD
Bővebben: Link

L298N-HEXMOD
Bővebben: Link

Én egyiket sem használnám, az L298 öreg tranyós meghajtó, sokkal korszerűbbek vannak

Az L298N-HEXMOD típusban ki lehet kapcsolni az 5 V-os tápegység IC-t, a jumperek helyén lehet hídáramokat mérni illetve a felhúzóellenállásokat lehet kikapcsolni.

Más különbség nincs.

A fordulatszámszabályzás egyénként is a kontroller feladata, ezt csak egy dupla H-híd meghajtó.

Azért még keress rá, mert fél éve volt egy újított bootloader. Valószínűleg ez sem tud eeprom írást feltöltés alatt, de nem vagyok benne 100% biztos...

asm-nel nincs mas megoldas
Resze a Makefile-nak, a lehetosegekhez kepest elegans, resze a kodnak, semmi tennivalom vele kezzel (ez avra assembler amugy).
Amikor c-vel hasznaltam egyszerubb volt de nem emlekszem fejbol hogyan ment.

Hulyeseget irtam feljebb ez avr-gcc nem avra. ("-x assembler-with-cpp" kapcsoloval)

Köszönöm a válaszokat!

Rendeltem egy ilyen Arduino Mega 2560-at. Bővebben: Link

Hiába állítom be a board típusát és a PORT-ot, a következő hibaüzenetet kapom:
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_getsync(): timeout communicating with programmer
Van valakinek valami ötlete, hogy hogyan tudnám orvosolni?

1. Nem jó a port.
2. Nem jó a baud.
3. Nincs bootloader az MCUn.
4. Rosszul van bekötve az USB illesztő.

5. Az usb kábel csak töltésre használható.

6. mire állítottad a portot? A CH340 drivere fenn van? (lásd a lap tetején)

Igen fent van a driver, mivel UNO és NANO már ment erről a gépről. (lsd mellékelt kép)

(#) vargham
1, A PORT beállítás jó.
2, A baudnak mennyin kell lennie? Nem csak sorosmonitornál van jelentősége? Hol állítom?
3, ezt nem tudom, hogyan lehet megtudni?
4, Ha felismeri a PC akkor is lehet ilyen? Ez gyári, nem nyúltam hozzá.

2. Baud annyi, amennyit az adott bootolader vár.
3. Nem válaszol UARTon a feltöltő szoftvernek.
4. Igen. Találkoztam olyan kínai hardverrel, ahol a CH340 rosszul volt összekötve az ATMegaval. Hiába látta a gép az USB ICt, az már nem tudott beszélgetni a mikrokontrollerel.

Ha van bootloader az MCU-n, akkor villog a LED, gyári állapotban. A LED villogása, vagy nem villogása ezt a pontot eldönti.

A Power LED mellett található 'L' jelölésű LED gyorsan villog. Akkor van rajta bootloader.

Akkor mit nézzek meg rajta?

Néhánnyal előbbi hozzászólásban, a 4-es pontot, a hardver hibát átnézhetnéd. Már én is találkoztam olyannal, amin forrasztási hiba volt. Konkrétan egy Nano-n, a CH340-es egyik lába nem volt leforrasztva, ezért nem működött. Egy erős nagyítóval nézzed át, illetve csipogtassad ki a kapcsolási rajz alapján a CH340 és az MCU közötti részeket.

Ahogy megméregettem jó lett, nem értem. Tényleg valami forrazstási hibája lehet a CH340-et átfogom forrasztani. Köszönöm a segítséget!

Sziasztok. Létezik olyan,kiegészítő arduinohoz ami a folyadék nyomását tudja mérni ?
Google nem volt a barátom. Max 100 bar mérés kellene.

Nyomásérzékelő 4-20mA, 0-10V, 0-5V
pl: Bővebben: Link

Szia.Remek,köszönöm.

Aki használ LGT8F328P kontrolleres panelt, tapasztalt már olyat, hogy a 12bites ADC max értéke 4096 helyett csak 4064 ??!

A tápfeszültségnél alacsonyabb referenciafeszültség és a tápfeszültséggel megegyező bemenet mellett sem fel az érték 4095-ig?

Természetesen ilyen körülmények között figyeltem erre fel! Bármelyik belső referenciát választva, 5V-ot adva a bemenetre, ki kellene bőven jönnie a 4095-nak. Ehelyett 4064-et kapok maxnak mindig...
De közben utánakeresgélve a neten úgy tűnik meg van az oka. Arról van szó, hogy a gyári analogRead függvény nem pusztán mér egyet az ADC-vel, hanem valamiféle kalibrációt is végez és azzal korrigálja az ADC-ből kapott értéket. Így a kalibráció függvényében bárhová beállhat a max érték gyakorlatilag. Állítólag magából az ADC-ből nyersen kijön az a 4095...

Igen, tapasztaltam. Nem tudom, hogy hardveres, vagy szoftveres gond, mert ha az IREF lábra tolom a referenciát, hát folynak a milliamperek bele. Elképzelhető az is, hogy a csipp belsejében esik feszültség? De a lényeg, hogy lehet korrigálni. A wiring_analog.c fájlban csináltam, ha jól emlékszem. 170. sor körül.
Részlet:

Sajnos banálisabbnak tűnik a dolog! Igen, jó helyen kerested, ez a kódrészlet okozza a bajt! Innen ered a csökkenés. Csak az okát nem értem, miért is van erre a korrekcióra szükség?!
Ha ezt kivesszük, akkor jól működik!

Találkoztam már olyan példánnyal, aminek kissé beteg volt az ADC-je. Talán, aki írta a kódot, ő is találkozott ilyennel.

Talán ő is beteg volt?!
Viccet félretéve..., az adatlapban semmilyen utalást nem láttam ilyen jellegű korrekció szükségességére, és értelmét sem látom ennek! Gyakorlatilag egy mesterséges meredekség csökkentés ez... Egy általánosra megírt könyvtárnak nem kellene tartalmaznia ilyen gyanús eredetű elképzeléseket! Én még az ofszet korrekciót is kikapcsolhatóvá tettem volna, pedig az gyári algoritmus....

Csak úgy megjegyzem, én nem használok C++-t, Bascom alá megírtam hozzá pár ASM rutint... de az ADC tökéletes működött (ettől féltem a legjobban). Nekem normál, szép értékeket ad vissza, viszont lebeg... de ez egy más téma. Tehát lehet, hogy ha a referenciafesz +AVcc, akkor nem megy ki, máskor mindig. Legalább is én ezt tapasztaltam. Különben tényleg van 1-2 furcsasága az LGTnek, de csak olvasni kell a pdf-et. (órajel tényleg hulladék, mértem)

Ha egy makró, rutin, könyvtár, nevezzük bárminek, átírja az ADC mérés eredményét valami alapján, akkor az nem a kontroller hibája.

Igen! én az alap GETADC()-t ráengedtem. Erre minden ment. Én csodálkoztam a legjobban. Bár előtte széttúrtam a leírást. No, hidd el, vannak még sötét foltok, de az alapok mennek.