Üdv!
Beszereztem ezt a BT modult.
Egyetlen konkrét kérdésem lenne az AT parancsokkal kapcsolatban.

Ott van például a dokumentáció végén az első rublikában az "A" betű elküldésével kiváltott "reakció". Ha én UART-on küldök neki egy "A" betű értékű bájtot, akkor megtörténik, ami az első rublikában le van írva, vagy az "A" bájt mellett még mást is el kell küldenem?

Ha be volt allitva elozoleg a tavoli bluetooth eszkoz ID-ja, akkor "ATA" parancs kikuldese utan kell csatlakozzon az adott eszkozhoz.

Csak példaként mondtam az elsőt. A kérdés az, hogy bájtról-bájtra pontosan milyen karakterláncot kell neki kiküldenem, hogy megcsinálja. Az "ATA"-ból következtetve, ha pl "E"-t akarok csináltatni vele, akkor "ATE"-t kell küldenem neki?

Igen. "AT", amit a megfelelo karakter kovet es a leirasnak megfelelo utasitas. Pl. "ATL2" -megvaltoztatja a baudratat. Ha jol emlekszem, akkor vagy CR vagy NL karakterrel kell zarni a parancsot. Itt egy video egy hasonlo eszkozrol, amelynek a konfigralasa megegyezik a tieddel. Ha van lehetoseged nem art eloszor kiprobalni soros terminallal (USB-soros vagy soros-RS232 atalakitoval).

Vegyél egy breadboard-ot. Látni is rossz, hogy DIP IC-k lábaira forrasztgatsz mindent. Se nyák, se semmi.

http://www.hestore.hu/prod_10028527.html - breadboard
http://www.hestore.hu/prod_10028526.html - kábelek hozzá

Ezután megveszel egy próbanyákot:
http://www.hestore.hu/prod_10031793.html - próbanyák szaggatott forrsávval
http://www.hestore.hu/prod_10000912.html - szalagkábel csatlakozó
http://www.hestore.hu/prod_10026161.html - tüskesor

Szóval kivágsz a próbanyákból egy darabot a csatlakozónak. Ráforrasztod a csatlakozót, mellé a tüskesort. Bedugod a breadboard-ba az IC-t, a csatlakozódat, a vezetékekkel kialakítod az áramkört a LED és az ellenállás segítségével.

Ilyen lehetetlen körülmények között nem lehet rendesen dolgozni.

Azt mondod gond lehet hogy így kötöttem be? Már megvan tervezve a panel a programozóhoz csak még mielőtt megépítem ki akartam próbálni hogy elsőre jó legyen. Az a breadboard jó viszont, tesztelni fogok venni. Bekötve jól van szerinted?

Ha képes a bascom hozzá kapcsolódni, akkor nagy baj nincs, jól van összedugva.

Igazából azt szerettem volna megírni, hogy ha előre akarsz haladni, akkor ilyen körülmények között nem fogsz.

Én a fenti hozzászólásomba rakott csatlakozók millióit gyártom le. Potméterekből is van vagy 5. Bedugod a breadboard-ba, bekötöd, utána meg csavargatod. Ha nem jó a kapcsolás, átvariálod a vezetékeket. De nyomógombos NYÁK-om is van.

Olyan ez, mint a LEGO. Legyártod az egyes elemeket, bedugod a breadboard-ba és összekötöd a vezetékeket kész kábelek segítségével. Nem csupaszolsz, nem vágsz, kiszeded a neked tetsző színű kábelt a csomagból és azzal kötöd össze.

Sziasztok! Ha SPI-n kommunikálok egy eszközzel mindegy az AVR melyik portjával választom ki (CS) vagy kötelező az SS lábat használni?

Atmega328-nál pl. így működik: Adatlap, 167. oldal. De fel is töltöm neked, hogy keresned se kelljen.
Még egy segítség: Mit csinálsz, ha két SPI eszközöd van, amikkel külön-külön kell kommunikálni?

Szerintem az lehet a gond, hogy a reset láb csak lóg a levegőben (a fényképek alapján így tűnik nekem). Fel kellene húzni (pl.: 10k-val) vcc-re.

Amikor programozod, akkor a programozó folyamatosan reset-ben tartja, vagyis ekkor még nem okoz gondot. Amikor viszont kipróbálod, akkor két eset lehetséges:
a, továbbra is reset-ben marad, vagyis a programod el sem indul
b, elindul, de folyamatosan reset-elődik (valami összeszedett zajtól pl.) és ezért újra-újra indul a programod, ami úgy tűnik mintha nem működne.

Idézet:
„...végén az első rublikában az "A" betű...”

Ezt nagyon sokan rosszul tudják, helyesen: rubrika

Ha külön próbálod a ledet és az ellenállást az jó? És a hosszú időzítéssel mit mérsz a portD-n, működés alatt. Csatlakozom hogy ha beírja a programot akkor a chip jó, (bár nem tudom, miért okoz hibát a regfile, és a többi)

És mi van, ha 50 eszközöd lóg az SPI-n, de az Atmegának csak 20 portja van? Nálam sajnos ez a kérdés előjött, ezért döntöttem annó az I2C mellett.

Egyébként van daisy chain is SPI alatt. Láncra fűzöd a szolgákat, pont úgy mint a 74HC595-ös shift regiszer esetében.

MOSI AVR -> MISO SLAVE1 -> MOSI SLAVE1 -> MISO SLAVE2 -> MOSI SLAVE2 -> ... -> MISO AVR

Az SS láb ebben az esetben mindenkire egyszerre vonatkozik. Azt szoftverből kell eldönteni, hogy neki szól-e az üzenet, vagy a buszon a következőnek.

Csak a poén kedvéért írtam le, a kérdéssel tökéletesen igazad volt. Bármelyik port lehet az SS láb mester esetén. Viszont az SS-nek kimenetnek kell lennie.

Mindaddig, amíg a slave eszközök is pont annyit tudnak, mint egy 8 bites shift regiszter. Mert mondjuk egy SPI-s EEPROM, amikor megkapja a Rd parancsot, addig a MISO labon nem ad ki semmit, aztan meg az EEPROM-bol felolvasott adatot adja rajta ki. Egyetlen bit sem jön ki belőle a MOSI-n beadott adatból. Általánosságban elmondható, hogy az SPI eszközöket nem lehet láncba fűzni.

Ha te definiálod a protokollt (te programozod le), akkor meg tudod csinálni. Egyébként igazad van az SPI EEPROM tekintetében.

Mondjuk úgy, hogy az SPI buszt fel tudod használni úgy is, hogy a saját tervezésű eszközeid sorba vannak fűzve. De ez nem SPI. Én is használom az SPI -t shift regiszterek feltöltésére és visszaolvasására, de ezt nem lehet SPI-nek nevezni. Az SPI szabvány pont arról szól, hogy egy időben csak egy MASTER es egy SLAVE eszköz kommunikál rajta. Én még nem láttam olyan SPI eszközt, amivel meg lehetne csinlálni a láncba fűzést. Az EEPROM csak egy példa a sok közül.

Szia!

Nálam most 9db motorvezérlő van 5/4 arányban megosztva SPI láncban (tehát egyik SPIn 5db, másikon 4db külön 1-1 MOSI-MISO -val, többi közös) és van 3db 16-bites párhuzamos kimenetem sorba (ezek is parancsorientáltak). A motorvezérlőknél ráadásul változó a parancs + operandusszám írásnál/olvasásnál is, szóval észen kell lenni, de tökéletesen működik. Biztos van olyan eszköz, amit nem lehet sorosítani...

Nos, a szakirodalom szerint letezik dasy chain SPI-n, nem vitazom tovabb. Marmint a Wikipedia szerint van ilyen. Én kb. 20 éve dolgozom SPI eszkozokkel, de meg soha nem volt olyan, hogy sorba kellett volna kotni oket. Es nem is lattam ilyet soha. Meggyozodesem, hogy az eredeti elkepzeles szerint a Motorola sem akart dasy chain-t alkalmazni SPI-n.A legtobb SPI-s eszkoz, ami tobb, mint egy egyszeru shift regiszter, az egesz biztosan nem sorosithato, mert nem jon ki belole az az adat, ami bement a MOSI-n. Erre volt pelda az EEPROM, de vegyel akar csak egy radio modult, vagy touch-screen controllert, Ethernet controllert vagy akarmit. Parancs, cim, valami be, valasz ki. Nem az jon ki belole, ami bemegy, ezert a masodik eszkozbe mar nem tudsz adatot kuldeni.

Sok SPI eszköznél dekódert KELL használni, nem ugyanennyi portlábat /CS célra. Ott van pl. a 74HC138, ez kaszkádolható is, 64 eszközhöz lehet hogy kell belőle 9 darab de akkor az AVR-en erre a célra csak 6(+1) darab lábra lesz szükség...

Na remélem semmit se felejtek ki. Igen, a led és az ellenállás jó, polaritásra is. Csak úgy 500 ms várakozási időt adtam neki. A reset lábat próbáltam Vcc-re húzni én is meg utána még GND-re is de az is hiába volt, nem történt semmi sem.
Szerintem a bascom jól látja a kontrollert mert ha másikat állítok be akkor rögtön hibát jelez. Azt a képet a bascomról azért töltöttem fel hogy hátha valaki nálam tapasztaltabb ember hibát fedez fel benne. Én úgy értelmeztem hogy a program beletöltődött a kontrollerbe, viszont amikor ellenőriztetni akartam akkor már hibát jelzett. Mivel az eredeti tervhez nincs meg még minden ezért most megterveztem egy nyákot amivel csak ezt az egy fajta avr-t tudom programozni, aztán majd ehhez csinálok modulszerűen a többihez is. Sajnos legyártani ma már nem tudom mert délutános vagyok de talán holnap.

Akkor, valami a bascom beállításaiban van elkeveredve. Ezért kell a regfile, azt is bele kell fordíttatni. Próbáld lefordítani hozzá regfile 2313-al is meg 2313A-val is, aztán beíratás. Minden változtatás után újra fordíttatni, beírni. Működnie kell. Gondolom a fuse bitek nem lettek variálva... Használd az Add to code-t $hwstack=$swstack=$framesize= ezeket ki lehet törölni.

Most rendeltem az Ebay-en TLC5940-es LED PWM drivert. Az eszköz úgy van megtervezve, hogy daisy chainelni lehet. Tulajdonképpen egy bonyolult shift regiszter, ami 16 csatornás PWM-re képes 12 biten.

Az IC azért így lett tervezve, mert ugye ha 500 LED-et akarsz vezérelni, macerás egyesével küldeni a chip enable jeleket.

Rengeteg SPI daisy chain eszköz van az iparban, de mind valamilyen shift regiszter. Ez az eszköz érzékeli, hogy van-e csatlakoztatva LED a lábára, sőt, a LED-ek fényerejét egyesével igazítani lehet (64 fokozatban), azért, hogy a különféle LED-ek egyforma fényűnek látszódjanak. Emellett, ha túlmelegítenéd az IC-t arról is kaphatsz üzenetet.

Az, hogy shift regiszter az alapja, még nem jelenti azt, hogy nem tudsz vele bonyolult funkciókat megvalósítani.

Ez mind nagyon szép és jó, csak az vele a baj, hogy semmi köze az SPI-hez. A chip-nek nincs SS lába, azon felül, ami a nagyobb baj, a data kimenet lába (SOUT) nem tri-state, hanem totem-pole. Évek óta használok MBI5040 chipeket (kb. pont azt tudja, mint ez a TLC). Van, amikor én is SPI hardware-rel hajtom meg, de attól az még nem SPI. Szinkron sorosvonal van 1000 féle, az SPI csak egy.

Udv!

Egy atmega1284p-be szeretnek egy bootloadert feltolteni. Addig jutottam, hogy a Makefile-ba a kovetkezoket adtam hozza:

#Where to start bootloader at
#Mega88 is 0x1E00
#Mega168 is 0x3E00
#Mega128 is 0xF000
#BOOTLOAD = 0x1E00
BOOTLOAD = 0xF000
#BOOTLOAD = 0xF000

#---------------- Linker Options ----------------
LDFLAGS = -Wl,--section-start=.text=$(BOOTLOAD)

Ezzel a modositassal a generalt hex file a jonak tunik, 0xF000 cimen kezdodik.
A gond, hogy az adott AVR ugyebar 128kbyteos igy hasznalni kell az extendend cimzest is.

Ha jol ertem a hex-file felepiteset akkor ezzel a sorral "aktivalhatom" a 64kbyte-on tuli cimeket:
:020000040001F9
amit a file elso soraba illesztettem.

A problemam, hogy igy is ket helyre is feltolti a kodot. A rossz 0x0000F0000 es a jo 0x0001F000 cimre is.

Tudna valaki segiteni a bootsectorba valo feltoltessel?
(WinAVR/AVRDUDE + USBtiny, ATmega1284P)

A hex file-ban byte cimek vannak. A 0xf000 az igencsak a 64k-n innen van még. Nem 0x1e000 cimre akarod tenni a bootloadert? Az AVR dokumentacioban a flash-hel kapcsolatban word cimek szerepelnek, amiket kettovel kell szorozni, hogy rendes byte cimeket kapj.

Igazad van. Oda akartam rakni, csak osszekuszaltam. A gondom sajnos igy is megmaradt. A modositott cimmel is ketto helyre tortenik a feltoltes.
A jo 0x0001E000 cimre es a rossz 0x0000E000 cimre.

Egy masik kerdes, hogy az ilyenkor normalis, hogy az ~1kbyetos kod helyett 58412byetot tolt fel?

Talan sikerult, csak nem tudom visszaolvasni.
A -U flash:r:bootloader.hex:i parancsra csak 1 sort kapok vissza --> :00000001FF end of file

Es ezt kapom a verify-ra:

Ez a hex file azert még mindig eleg gyanus. 123948 byte hosszu, ez kb. 60 kbyte kod. Ez lenne a ~1k kod? Nem hiszem.

En naivan arra gondoltam, hogy az avrdude-ban van a hiba. A torles utan, ami az egesz flasht 0xff-ra irja, ami rendben is van. A gond szerintem, hogy valamiert a 0x0000 cimtol ujra elkezdi az egeszet felulirni 0xff-re page by page.
Ha normalisan menne, akkor egybol a 0x1e000 cimre kene ugrania az elso page irasakor, nemde?

Annyi valtozas meg tortent, hogy a hex elso sora a Make file soran erre modosult:

A fenti hex file sor csak annyit tesz, hogy 0x10000-re allitja a báziscimet. Ehhez adodik hozza a hex file tobbi soraban levo 16 bites cim. Elvileg 0xe000 cimmel kellene kezdodjon a kodod a hex file-ban. De meg mindig nem ertem, hogy mitol 60 kilobyte a cucc. Itt lesz a kutya elasva. Kell legyen valahol a build directory-ban egy .map file, ha minden igaz. Abbol kiderulnek a reszletek. Ha a hex file nem titok, akkor esetleg meg tudom nezni, hogy abban milyen cimek vannak.