Pont az a lényege, hogy védi a programot az illetéktelen kiolvasástól.

Akkor nem piszkálom, pont az lett volna a lényeg hogy legyen egy mentésem.

Köszönöm mindenkinek a segítséget!

Na hali! Még mindig ugyanaz a robot. Elvileg már mindent tudok hogy beprogramozzam de a szervo motor szemét velem. A vezérlő egy attiny2313, ha csak simán beletöltöm azt a programot hogy fordítsa balra a szemét a szervo akkor megcsinálja, 800us impulzus kell neki. Amint beleírok mást is a programba már csak középre néz 1600us és jobbra 3200us impulzusra. A 800-ra nem reagál semmit. Pedig már tud menni, lát, reagál is a kezemre csak épp balra nem fordul. Már rendeltem másik ict is, hátha a kínai rossz de az eredeti se jobb. Csak 100us eltérést kell írni a programba. Próbáltam már növelni az órajelet kristállyal de az nem változott úgy vettem észre. Engedélyezni kell a fuse bitekkel a külső kristályt? Azokhoz még sohasem nyúltam. Mi lehet a baj? Miért nem néz balra?

Igen. Nézd meg az adatlapon. A saját hsz-edben ott az automatikus link a hirdetésre és azon belül a pdf-ben a "fuse"-ra rákeresve az első találat pont erről szól "CKSEL"-re is rákereshetsz. Az alapértelmezett a belső 8Mhz amit tovább osztanak 8-al, és így kb. 1MHz-n ketyeg gyári beállításokkal.
Arra az esetre, ha baleset történne, bővebben: Link

Köszönöm szépen, megnézem napközben. Ha 8MHz van leosztva akkor szerintem nem is kell nekem kristály, csak engedélyezem 4 MHz-re gondolom remélem hogy úgy már jobban fog működni. Csak rájövök hogy bascomban hogy kell beállítani.

Nem töltötte le véletlenül valaki a http://www.qsl.net/pa3ckr oldalt mintaprogramokkal együtt.
Addig halogattam annak idején, hogy a gazdája törölte a tartalmát.

Web.archive.org-on nézted?
Bővebben: Link
Szerk: Az itt linkelt tartalom 2018.09.02-i mentés, van több időpontban is.

Köszönöm szépen. Ez nagyon jó lesz!

Sikerült elsőre megbabrálni a fuse bitet, 8 MHz lett a belső oszcillátor frekvencia de ugyanaz a helyzet minden más működik de balra nem fordul ki a szervo motor. Most már azt is kitapasztaltam hogy az is elég ha egy változónak lekötök Word hosszúságú memóriát. Már akkor sem fordul ki. Valamit a memória területén ronthattam el? A flash tárhelye csak 55%-ig van kihasználva.

Konkrétat nem tudok mondani, valahogy tesztelned kellene, hogy milyen jel jön ki belőle amikor 800us-t próbálsz kiadni. Pl. szkóppal, vagy valamilyen ismert órajellel futó számláló IC-t engedélyezed a szervó vezérlő kimenettel, és megnézed meddig jutott a számlálással. Egy másik AVR-t is felprogramozhatsz mérésre. Valószínű, hogy programhiba, debug lehetőséged nincsen? Assemblyben programozod? Ha nem, akkor a fordító optimalizálója is csinálhat hülyeségeket, mert esetleg nem veszi figyelembe, hogy te valamit időzíteni akarsz és levág egy-két "kanyart" a programodban.

Megmérted szkoppal a jeleket?
A közepállás 1,5 ms, ettöl kevesebb balra, ettöl több jobbra fordit. A modern szervok már nem érzékenyek a jelek frekvenciájára ( eredetileg 50 Hz azaz 20 ms volt). A mai szervoknak mindegy, ha a frekvencia 40-200 Hz között van, azaz az orajellel kár kisérletezni. Csakis az impulzusszélesség számit.

Először egy atmega8-al próbáltam megcsinálni de azzal nem volt jó az ultrahangos távolságmérő sehogy sem. Ugyanaz a program az attiny2313-ban azonnal működött. Ha a szervot csak külön balra fordítom akkor tökéletesen működik de amint valami mást is beleírok a programba már nem jó. Emiatt szerintem felesleges most a szkóppal mérni mert biztos hogy nem kap impulzust. Bascom avr-t használok. Most hogy említetted a fordítási hibát lehet hogy azért nem jó valóban. Lehet hogy az atmega8 is azért nem működött. Megpróbálok letölteni egy másik verziót, hátha jó lesz végre.

A kalóz verziók hibásat fordítanak. A DEMO-val próbáld meg, az 4k kódig free.

Azzal próbálom de a legújabb verzió is ugyanazt csinálja . Most próbáltam ki. Itt vannak a teszt programok, amiben csak simán a 700 us időt használom abban kifordul balra, de a másikban azt kihagyja és csak középre illetve jobbra nézeget folyamatosan. Más módszert én még nem ismerek impulzus kiadásra csak ezt, ha van más megoldás is azt szívesen kipróbálom.

Ha jól látom, a programod a következőt csinálja:

20x 1: 700us -> 0: 50us
Várakozik 1s
20x 1: 1500us -> 0: 50us
Várakozik 1s
20x 1: 3000us -> 0: 50us
Várakozik 1s
Ezután kezdi az egészet elölről

Vagyis egy teljes periódus ideje változik 750us - 1550us - 3050us
Csak egy tipp:
Próbáld meg a 700us-os ciklusban az 50us helyett 1300us-ot (a 700us maradjon).
Esetleg érdemes lehet kipróbálni ugyanitt az 50us helyett 2350us-ot, és az 1500us résznél az 50us helyett 1550us-ot.

Igen azt csinálja. Próbálkoztam már én is tartani a frekvenciát mert gondolom hogy arra ment ki az ötleted. Sajnos így sem jó kipróbáltam most és most is csak egyenesen meg jobbra nézeget felváltva. Amikor balra nézne azt az időt mozdulatlanul tölti balra fordulva.

Maradtál 1MHz-s órajelen, vagy csak régi a kép?

Most már működik a robot végre 8 MHz-en működik. Valóban fordítási gond volt, annyit változtattam rajta hogy pin helyett port-ra változtattam a lábak hivatkozását amik kimenetek és a freki is fontos volt mert úgy meg jobbra nem akart nézni. De átírtam azokat is hogy mind 3050 us legyen összesen és most jól működik. Érdekes mert régen mindig pint írtam és sohasem volt baj vele pedig elég komoly programok is voltak pl automata mosógép vezérlő. Évekig mostam egy atmega8-al Köszi a segítséget mindenkinek!

Ügyes vagy!

Üdv!

A következőre nem találom a helyes megoldást:

Van egy általános foo(), TWI_General_WRD(unsigned char *sreg, unsigned char cmd, my_32b addr, unsigned char addr_size, unsigned int data_size, unsigned char data[]), amit #define segítségével "hívnám meg" a különböző slave IC-k estében. Valahogy így:

#define MCP23017_WR(cmd, addr, data) TWI_General_WRD(..., cmd, (my_32b){.b = addr}, 1, 1, (u8p)data)

Ezzel a a fordító nem ír ki hibát, viszont nem működik megfelelően. Random értékeket kapok az MCP23017 kimenetein. A tippem az, hogy a data változóhoz néhol fix értéket rendelek:
MCP23017_WR(cmd, addr, 0x00) vagy MCP23017_WR(cmd, addr, 0xAA) és ez okozza a gubancot, mivel ezeket pointerként kezeli(?)

Ha egy &-t beillesztek a data elé, akkor
#define MCP23017_WR(cmd, addr, data) TWI_General_WRD(..., cmd, (my_32b){.b = addr}, 1, 1, (u8p)&data) hibát kapok: , de csak a fix értékekkel rendelkező foo()-k nál.

Átmenetei megoldásom: A fix értékeket egy változóba raktam és úgy hívtam meg:


Így működik, de arra szeretnék választ kapni, hogy van-e ennél jobb megoldás, hogy ne kelljen minden alkalommal a FIX értékeket egy változóba beillesztenem?

Remélem érthetően írtam le a dilemmámat.

SB

Szia!

Nem minden világos, de van pár észrevételem. Az említett foo() függvény mit is csinál? (És hol van?)
Igen, szerintem is az a gond, hogy pointerként kezeli.
A cím átadásával (&) azért nem fordul le, mert a #define feldolgozásakor a preprocesszor nem tud semmit a változók leendő címéről.
Ezt nem értem.

Meglep, hogy az átmeneti megoldásnak írt módon működik, mert nem látom, mi változott a korábbihoz képest, vagyis szerintem még mindig pointerként kezeli. A my_data más értékével is működik, vagy csak nullával próbáltad? Mert ha a 0 címen éppen a 0 érték van, akkor tűnhet úgy, hogy jól működik, de csak véletlenül. Próbáld ki így (és ne csak 0-val, hanem más értékekkel is):

Üdv!

Gondoltam lesz amit rosszul fogok megfogalmazni.
-
általános foo() ==> TWI_General_WRD()

1. Ha így hívom meg: (a lényeg az utolsó paraméter -> (u8p)data )
#define MCP23017_WR(cmd, addr, data) TWI_General_WRD(..., cmd, (my_32b){.b = addr}, 1, 1, (u8p)data)



A kód hiba nélkül lefordul, de nem működik megfelelően.

2. (u8p)data cseréje (u8p)&data -ra
#define MCP23017_WR(cmd, addr, data) TWI_General_WRD(..., cmd, (my_32b){.b = addr}, 1, 1, (u8p)&data)






Átmeneti megoldás:



Az MCP23017 kimenetén LEDek vannak és értéknek a másodpercek jelennek meg, helyesen. Ebből tudom, hogy így megy.

Szóval csak arra keresnék megoldást, hogy ne kelljen mindenhol egy változóba beillesztenem a fix/konstans értékeket.

Itt egy tombot varsz (illetve a cimet)

Igy probald ha egy erteket akarsz atadni.

..mar amennyiben tudo modositani a TWI_General_WRD() fuggvenyt. Ellenkezo esetben a vart parametert kell atadnod

Ha te írtad a TWI könyvtárat, neked kellene tudni milyen paramétereket vár a függvény. A hibaüzenet érthető, lvalue-t vár az operátor, amire memória címmel hivatkozni lehet. Ez nem lehet a hívás után: &0xAA. Az átmeneti megoldásban ezt kipróbálhatod: {0xAA}, így írod be a konstanst, bár szerintem csak alap típusokra működik. Nem értem, hogy erre a makrózásra miért van egyáltalán szükség?

A foo()-t nem az "általános függvény" kifejezés szinonímájaként szokták használni, hanem egy konkrét, de irreleváns nevű függvény neveként.

1. Azért nem megy, mert nem adatként kezeli az értékeket, hanem pointerként. Amúgy ebben az esetben a második és a negyedik sor értelme ugyanaz.

2. Rájöttem, hogy amit előzőleg írtam erről, az nem jó, a preprocesszoros magyarázatom rossz. rolandgw írta jól, ott az a baj, hogy konstans érték címét kellene képezni változóé helyett (most értettem meg, hogy a "de csak a fix értékekkel rendelkező foo()-k nál." erre vonatkozott).

Én a makró helyett inkább rendes függvényt írnék, valahogy így:

Persze fontos megjegyezni, hogy így a TWI_General_WRD függvény az MCP23017_WR függvény lokális data változójának a címét kapja meg, tehát ebben a formában csak akkor jó, ha a TWI_General_WRD nem menti el ezt a címet valahova későbbi használatra (a visszatérése utánra).