Szia!

Ez vettem másik vezérlőt és a WD 128kHz-es-t kiforrasztottam, az újat pedig be.
Le tudnád írni, pontosan hogy kell használni ezt a parancsot ha legközelebb is elnyomnék valamit? "-U lfuse:w:0xc3:m”
Letöltöttem az AVRDude-t, mikor elindítom fölugrik egy ablak, de azonnal el is tűnik.

És ha átállítom ezt, akkor mi fog történni? Nem zárom ki magam a chip-ből?
Divide clock by 8, ON

A Clock output on PORTB4; [CKOUT=0] beállításnak mi a funkciója?
A High fusebit-ek rendben vannak?

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

A BP4 lábon kiadja az órajelet.

Köszi!
A többiben is tudnál segíteni?

Üdv!

Nyissad meg a parancssort és lépj be a könyvtárba ahol az AVRDude van (mellékelt kép).

A mellékelt képen az usbtiny helyett usbasp-t kell beirni.
A teljes parancs így néz ki:


A -B azért legyen elsőre 1000, hogy a lassú órajel mellett is fel lehessen programozni.
Most ugrik be, hogy az usbasp-n lehet egy jumper "slow" névvel, amit ha összekötsz, akkor alapból lassú módban próbálja majd a tiny45-öt felprogramozni.

A High Fuse Bitekhez nem tudok mit mondani, amíg nem tudni, hogy a programnak/hardware-nek mi is a feladata. (Kell e egyáltalán módosítani valamit.)

Szia!

Sajnos akár milyen értéket állítok, nem állnak vissza a biztosíték bitek.
A programozón a "slow" beállítással is próbáltam és Bascom-ba is kipróbáltam a "slow" állítással, de így sem jó.
A program bele van töltve, ezért annyi történik, hogy amikor a programozót csatlakoztatom, akkor a vezérlő egyik kimenetének a jelszintje pár másodpercre magasra vált.

Egy nagy feszültségű programozó, vagy egy fuse bit doctor szerintem segíthetne rajtad.

Azt óvatosan megemlíteném, hogy ami nekem van fusebit doktor(5 éves), az nem birkózott meg a attiny45-el. Próbáltam egy jól működő 45-el is de azt sem ismerte fel jól. A nagyobbakkal elboldogul, nélkülözhetetlen eszköz baleset után.

A csatolt logokat megnézve egyértelműen mondja, hogy nem tudta az SCK órajelet állítani, mert a programozó firmware-je nem képes rá. Szóval egy másik programozóval nem esélytelen, hogy működne. Vagy ha ezt a programozó kapna egy firmware frissítést - ezt sugallja a warning üzenet.

Azt tudom, de ha anélkül is meg lehet oldani a dolgot, nem ruháznék be.

Köszönöm az észrevételed. Van még egy STK-200-as párhuzamos portos, azzal menne?
A legutolsó firmware frissítés az usbasp-re 2011-es. A tiny45 úgy tudom utána jött ki sanszos, hogy az sem oldaná meg.

Ez két különböző dolog: az SCK órajelet az égető hardver kezeli, ahhoz kell a firmware frissítés. Ha nem kezeli az SCK beállítása parancsot, akkor az nem fog menni.

A csip felismerés pedig úgy megy, hogy van egy csip típusazonosító kiolvasás parancs, aminek az eredményét az égető csak visszaadja az avrdude-nak, és az avrdude kezeli. Ő is csak annyit csinál vele, hogy ellenőrzi, hogy megfelelő-e. Tehát működnie kell függetlenül a csip kiadási dátumától.

Biztosat nem lehet mondani, hogy a másikkal menne-e, de egy próbát megérhet. Én mondjuk már rég kukáztam volna a csipet a helyedben, de ha már ennyit beletettél, akkor vidd végig a projektet!

Kínai firmware van a programozón, nem az eredeti német. Elvileg ezen automatikus az sck, ezért nem fogadja a B-t. A Fischl-t kellene rátenni, de az még egy programozó.

Nekem is hasonló korú és nekem is csinált érdekes dolgokat. Ugyan azt az uC-t (valamelyik tiny) egyszer felismerte, aztán nem, aztán megint igen. Ki sem vettem közben a foglalatból. Magam építettem, talán valamit én rontottam el.

Ok. A fusebit filléres tétel ha mégis megépítenéd.

Üdv.
Meg tudtnátok erősíteni hogy ez az elképzelésem helyes -e. Pointerekkel ismerkedem, cast-olni szeretnék egy char tömb pointerjét (signed) byte -ra ami ugye unsigned Arduino alatt. A fordító elfogadja. Ide írom kérdésem mivel gondolom pointerekkel kapcsolatos kérdések nem pont Arduino téma.
Köszönöm

Teljesen jó a cast-olás.

Egy kis elméleti hozzáfűznivaló, ami 99%-ban érdektelen annak aki csak egy platformra programozik:

A C nyelv (sajnos) nem definiálja egyértelműen a típusokat, mindegyiknek csak a minimális méretét szögezi le, de hogy egy adott platformon melyik hány bájt maximum, azt nem. Hasonlóan a char-ról sem mondja meg, hogy hány biten legyen ábrázolva! Mégis mindenhol 8 bit szokott lenni.

Ezért amit leírtál, az nem lesz teljesen hordozható elvileg. A char típus lehetne például 16 vagy 32 bites is, és akkor az uint8_t-ként beírt értékek nem lesznek hibátlanul visszaolvashatók char-ként. De én még olyan fordítót nem láttam, ahol a char ne 8 bites lett volna. Pedig elvben lehetséges.

Ellenben az uint8_t, uint16_t, uint32_t típusoknak kötelező olyan szélesnek lenni, ami a neve! Ezeket később adták hozzá a standard könyvtárakhoz, az stdint.h-ban vannak definiálva (az Arduino automatikusan inklúdolja) és hogy hogyan valósítja meg ezeket, az platformfüggő. Hacsak lehetséges ezeket a típusokat érdemes használni, mert ezekkel teljesen egyértelműen megmondjuk, hogy mit várunk a géptől. Plusz érdekesség, hogy ezeken a kis procikon az __uint24_t típust is megvalósítják egy ideje, mert sokszor nem elég a 16 bit, viszont lényegit lehet spórolni a 32-höz képest.

Ok, köszönöm a megerősítést, char -t is csak az Arduino végett használtam egyébként egy ideje teljesen áttértem uint -es típusokra, sokkal egyértelmübbek. Lehetne még egy kérdés? Több infót is találtam a neten de egyenlöre még nem esett le nekem hogy mikor és miért használják néha a size_t -t? Mivel pl. a sizeof fgvény ezt adja vissza akkor ez egy szimpla uint_8 vagy 16? Gondolom hogy ha csak az elöbbi lenne akkor nem hoztak volna létre feleslegesen egy új típust, akkor egy valamilyen amorf típus lehet, pl. ha belefér 8 bit -be akkor uint_8, ha nem fér bele akkor nagyobb? De az meg miért lenne jó? Bocsika

Igen, a size_t az akkora, hogy minden tömb méretét ki tudd vele fejezni az adott platformon. Bevallom nem tudom, hogy az avr-gcc mekkorának veszi, illetve hogy kisebb ATTiny-k esetén 1 bájtra szűkíti-e, vagy nem? Eleve nem szoktam AVR-eken dinamikus foglalást használni, és szinte sohase kell sizeof operátor sem. Úgyhogy nem találkozom size_t-vel.

PC-n ha 32 bitre fordítasz, akkor talán 32 bites, de 64 bites program esetén már 64 bites a size_t. Szóval itt valóban van platformfüggő eltérés, és ennek még értelme is van.

Ha tudod, hogy mekkorák a puffereid, akkor fix méretekbe biztonságosan bele lehet kasztolni. Legalábbis én így szoktam, tudtommal ebben nincs csapda de a C nyelv tartogat meglepetéseket a sokat próbált öreg rókák számára is.

Köszi, a mai nap megint okosodtam kicsit . Akkor átírom a függvényeim változó típusait ahol a tömb méreteit várja.

Másodszori olvasásra esett le hogy nem kedveled AVR -eken, a kevés SRAM mérett végett?

Nem mondtam, hogy valamit nem kedvelnék, hanem hogy malloc-os dinamikus foglalást nem szoktam csinálni a kevés SRAM végett. Meg ugye nincs is szükség rá, hiszen előre mindent tud az ember, hogy mit fog használni, és azoknak előre le van osztva a helye statikus változókban, vagy esetleg stacken. A tömbök méretét pedig tudom, és általában uint8_t-ben számolom, mert az is elég. Ezért size_t-s zsonglőrködésre sem szokott szükség lenni.

Üdv!

Picit összezavarodtam. Az előző hozzászólásod szerint ez már egy másik tiny45-ös. Ezt te programoztad fel vagy már fel volt programozva? Még az áramkörbe való behelyezése előtt vagy után? Ha nem AVRDude-al ment a felprogramozás, akkor mivel?
Ezeket a felprogramozás után olvastad ki az AVR-ből?

Használd most inkább ezt a parancsot, hogy részletesebb hibajelzést kaphassunk:

-B 1000-rel és anélkül is küld el az eredményét.

Ha te programoztad fel a ezt a második tiny45-öst, akkor már a rossz összekötést bőven kizárhatjuk.

Sziasztok, lenne egy kérdésem, megpróbálom körbeírni hogy mit is szeretnék megvalósítani C++ ban. Pl. egy osztálynak 2 konstruktora van, attól függően hogy melyik konstruktorral példanyosítom az objektumom, szeretném függővé tenni hogy mely funkciókat fogom használni. Ugy müködik hogy egy globális változónak értéket adok, attól függöen hogy melyik kostruktort hívom meg majd if feltétellel figyelem programfutás közben, de ez szerintem felesleges változó figyelés ha eldönthetö lenne már fordításkor. Köszönöm

Kicsit zavaros lett a kérdés. Mit akarsz megvalósítani? Kétféle implementációja van egy funkciónak, és ezek között akarsz választani? Fordításkor dől el, hogy mit választasz? Vagy futás közben?

Ha fordításkor dől el, akkor akár fordítási makro elágazásokkal is meg lehet csinálni.

Vagy kétféle implementációt csinálsz az osztálynak két külön forrásfájlba, és vagy az egyiket, vagy a másikat fordítod bele. Így tuti nem kerül semmi felesleges a csipre, és egész átlátható is. Én így szoktam ezeket megoldani.

Pontosan ezt szeretném. Fordításkor dől el, de próbáltam define preprocesszor direktívákkal megoldani csak nem jött össze mivel gondolom helytelenül csináltam, #define direktiva gondolom funkción belül nem müködik. A 2 külön forrásfájl lenne a szimpatikus (pl. funkciok1.cpp funkciok2.cpp) és #ifdef el kiválasztani a megfelelöt. Csak hogyan döntöm el hogy melyik konstruktorral példányosítok? Kód elég nagy, nem csatolnám, de ha még nem világos hogy mit is szeretnék akkor leírhatom pszeudó kódban késöbb vagy holnap. Köszi

Preprocesszor: a "rendes" fordítás előtt fut le, tehát nincs olyan, amire nem hatna. Ha nem működött, akkor valamit elrontottál.

Ha két különböző forrásfájl van, akkor a Makefile-t meg lehet úgy írni, hogy két külön targeted (bináris) készül, amik más forrásokból készülnek. És így nem kell #ifdef-ekkel telerakni a kódot. Az ifdef-ek általában nagyon gyorsan átláthatatlanná teszik a forráskódot.

Igen, elrontottam, nekem is ez a véleményem, ezért is tettem fel ide a kérdésem Lenne esetleg róla egy kis olvasmány vagy példa hogy hogyan is kellene megoldani helyesen? Makefile-t megíni hogyan tudnám helyesen, ez Arduino alatt lenne egy arduinós könyvtár. Köszi

Arduino library esetén mire az INO programodat fordítja, addigra a könyvtár már régen lefordult, tehát nem tudsz már változtatni rajta define-okkal, vagy ilyesmivel.

Fogalmam sincs, hogy hogy tudsz Arduino könyvtárat fordításkor paraméterezni.

Egy megoldás lehet, ha két könyvtárat csinálsz a két eltérő funkcióval, és kicsit eltérő include névvel, amivel behivatkozod. Így tudsz könnyen váltogatni. Jobb ötletem nincs.

Üdv!

Ilyesmiről van itt szó??:


asch: Jól értem, hogy ez lenne a Preprocesszor megközelítése a problémának?

Ezt a módszert nem túl rég kezdtem el használni, többnyire debug kódokhoz.


Szerk.:
Most olvasom, hogy Arduinoról van szól. Ott nem tudom, hogy mennek a dolgok.
Talán, ha egy külön header-be van elmentve a #define változó a hozzá tartozó foo_1() és foo_2()-vel.

Ezt szeretném elkerülni de meglehet hogy nincs rá más lehetöség. Azért köszönöm