Szerintem meg lehet, legalábbis ami az AVR oldalát érinti kommunikáció szempontjából.
Mivel több adatod is van, mindenképp muszáj több bájton küldeni, hogy a "keret" biteken
jelezd azt is hogy épp melyik adat érkezik. Egy sokváltozós környezetnél már más a szisztéma.
Sőt, nálad már van egy kész, gyári program aminek adataiba nem biztos hogy csak úgy belepiszkálhatsz,
ha meg a naplófájlokból akarsz küldözgetni, számíts arra hogy amikor ír a program,
nem biztos hogy az oprendszer meg engedi nyitni a fájlt.

Sokváltozós rendszer:
Munkahelyemen építek egy mérő automatát. Itt minden méréshez egy csomó dolgot meg kell adni,
mint pl. típus, osztók, bemenetválasztás, kapcsolómátrix, tápegységek, stb.
Tehát összetett kommunikáció zajlik, azaz egy mérés adatai és a mért értékek keretben érkeznek.
Egy keret hossza (nálam) fix, vannak benne "tokenek" amelyek csak adott helyen állhatnak,
a keretet egy CRC16-os ellenőrzőösszeg zárja(pár soros algoritmussal számolható).
Ráadásul a tesztgép minden parancsot nyugtáz, ha ez elmarad akkor a PC újraküldi a keretet.

Maga a játék "realtime" adatküldést lehetővé tesz, különböző pluginekkel.

Egyenlőre az a félelmem, hogy a megszakításokkal egymásba futok, tehát korábban jön újabb információ mint az előzőt feldolgoztam. A terveim között kb 10 hétszegmenses kijelő egy db 16 szegmenses is, 16 fordulat led, és még egypár led ami mondjuk sárgazászlót kékzászlót, üzemanyag fogyás, magas hőmérsékletre figyelmeztetés.

Lesz ezzel munka azt hiszem.

A kijelzéshez mindenképp használj interruptot(timer), az UART-hoz viszont nem kell.
Ha tényleg ennyire rugalmasan lehet konfigurálni az adatküldést akkor válassz olyan időközt
ami alatt az AVR biztosan fel tudja dolgozni. És olyan formátumot ami könnyen feldolgozható.
Ezzel elkerülheted a ráfutásokat.

Esetleg még egy buffert is berakhatsz. Így mikor van szabad időd akkor küldöd ki az adatot UART-on.

Azert egy 1206 meretu 100 nF es egy 1k ellenallas nem nagy helyet foglal el. Vagy vannak 0,1 W ellenallasok is. En is csinaltam ilyet, es fuggonykarnis alucsobe ontottem be szilikonnal.

Tipp:
A kijelzést nem tudod kiszervezni egy külön AVR chipbe? Így sok erőforrást leveszel a főkontrollerről....

Remélhetőleg csak vicceltél az előbb.
Gyanítom hogy Te már felfedezted a telekinetikus kommunikációt AVR-ek között,
de ha mégsem akkor ugyanott tartunk csak elpazarlunk +1 AVR-t a transzfer miatt.

Annyit találtam ki, ha esetleg gyorsabb lenne, a kommunikáció, mint a kijelzés kezelése, akkor az adat memóriába menteném, az adatokat amit kapok, és azt követve olvasnám ki, és adnám tovább feldolgozásra. Egyenlőre arra jutottam, hogy elkezdem leDebugolni a folyamatot, megnézem mennyi időt vesz igénybe a kijelzés, és ha lehet akkor gyorsabb órajelen futtani az AVR-t. 10-16Mhz között úgy gyanítom elég gyors lesz.

Arra ügyelj hogy az AVR ne végezzen (túl sok) szorzás-osztást, és akkor tuti belefér az időbe.
Az adatfeldolgozó részben(ami főciklusban futhat) a feldolgozott adatot tömbbe(adatmemóriába)
írod ki ahonnan a kijelző interrupt csak kiolvas és írja a portokat.

Most tegyük fel hogy 1000 órajel egy kijelzési ciklus(és ehhez nagyon pocsék kód kell),
és 50Hz-en "villogtatod", számold ki hogy egy 8MHz-en futó processzor idejéből mennyit vesz el.
Megsúgom: kevesebb mint 1%-ot. Ezért sem érdemes több procit betenni.

Ha 9600baud-nál nagyobb sebességre vágysz akkor érdemes (baud) kristályt betenni,
egy 7.3728MHz vagy 11.0592MHz megteszi. Arra is gondolj, hogy ha ezt a kijelzőt
emberek fogják leolvasni akkor legalább 150ms ideig ugyanazok a számok jelennek meg
a kijelzőkön. De inkább 300ms. Ez azt jelenti hogy a frissítést nagyon ritkán
kell elvégezni, amibe egy tömény lebegőpontos szorzás-osztássorozat is bőven belefér.
És talán nem is kell kristály mert 9600baud mellett az esetek 99.9%-ában tökéletes a vétel.

Én igazából arran gondolta, hogy a számítások nagy részét végezze a számítógép, ott vannak GHz-k. A kontorollerre ez után csak annyi érkezne meg, hogy melyik kijelző helyre milyen számot írjon ki.
kb így:



Ez talán nem fog felemészteni 1000 órajelet.

9600baud-nál ha jól számolom start és stop bittel együtt 960bytot tudok küldeni 1s alatt. Aminél lehet azért fogok nagyobbat választani, hogy az ezred másodperceket is megtudjam jeleníteni. (lehet az idő kijelzésnek csak egy "start" és egy "stop" jelet fogok küldeni.)

Nem. Ha 7szegmenses a kijelzésed, akkor az elég szépen elvisz az erőforrásokból az INT alap miatt (Timerx, frissítés). Csipogó, ésegyéb alfeladatok.
Ha nyomógomb kezelés van, ami a kijelzésre hat - azt miért a főprocesszor végzi?

A két IC I2C/SPI-n összeköthető. Így pillanatok alatt (SPI: 4MHz, I2C: 400 kHz) átvihető a kiirandó információ, ill visszaolvasható a nyomógombállapot.

Ennyit mára a telekinetikáról....

50 Hz frissítés - a teljes kijelzőre, 1000 utasítás/esemény alapon. 6 db szegmens esetén 6000*50 utasítás: 30.000. És a chip jár 8 MHz-n (8M). Így a kijelzés elvisz 30e/8M = <1%-ot.

Viszont nem beszéttünk arról, hogy más INT-ek milyen sebességűek, időigényűek. Így megakadhat időnként a kijelzés, és fényerőváltozást jelent. Nem beszéltünk arról, hogy a kijelzés lehet környezetfüggő, PWM alapú vagy vezérlésalapú.
Ha soros írás/olvasás van, az is INT alapon megy. A fordulatszámmérés szintén (sebesség? néhány 100 vagy 1000? Esetleg >>10.000?).

Opcióként akkor sem vetnél el az elosztott rendszert. 7S kijelzésre akár célIC is bevethető, így nem vinne erőforrást és nem is villódzana....

kb 10 7szegmenses kijelzőről van szó, és 3db 16szegmenses, és még ledek. Ami megint közben jutott eszembe(még neki se álltam kb már most ezer a probléma ), hogy mikor elkezdem a kijelzést a 7szegmensesen akkora minden adatnak meg kell lennie, vagy minenhol nullának kell lennie(ez mondjuk nem akkora tragédia).

Hogyan kéne ennyi 7s kiejlzőt bekötni? Az én elképzelésem az volt: 4bit-en küldök BCD kódot, egy kijelző meghajtónak amin sorban ülnek a kijelzők, másik 4bite-en pedig 4-16 dekóderrel lehetne kiválasztani a megfelelő kijeézőt.

A 16 szegmenses, csak azért kellene, hogy P,N,R,+,- feliratok is szépen megjeleníthetőek legyenek. ezt esetleg úgy hogy egy kimenettel ezeket külön kapcsolni.

Eleinte féltem, hogy ez meghaladja a képességeimet, de talán fel tudok magamra annyit szedni, hogy megbírkózok vele, de kezd egyre nehezebbnek tűnni a dolog.
Valami ehhez hasonlót készítenék

Itt az önálló AVR-t is elfelejteném már.
MAX7219 vagy MAX7221 célIC + AVR a kiíráshoz.
A MAX az 8 db 7szegmensest kezel le (számok,-, HELP). Éa aegyebeket rápakolnám egy AVRre. vagy mindet egy nagy lábszámú AVRre, olymódon hogy az AVR 1 portján max 4 szegmens lehet (illetve ekkor kell külső meghajtóIC). Így egy szép nagy lábszámú AVRed lesz

vagy a TPIC595 minden szegmenshez és shiftregiszterként kilépteted az egyes szegmenseket... A TPIC595 ~300 Ft, azaz nem lesz valami olcsó megoldás a holmid....
Viszont nem kell tranzisztoros erősítő/kapcsolófokozat.
A MAX chip is ~1500 ft, és 8 db 7szegmenst lekezel...


Viszont arra vigyázz:
- autóban alkatrésztemető: a meghibásodás gyakorisága nő!

Az 1000 órajelet természetesen multiplexelve értettem, elég gáz lenne ha minden multiplexes lépés ennyi processzoridőt felemésztene! Bár egy, az erőforrásokat elpazarló fordító esetében bármi előfordulhat!

A "második AVR" továbbra is felejtős, nem látom értelmét annak hogy a második,
kijelzőket kezelő AVR csak továbbküldi azt amit SPI-n vagy neadjisten I2C-n kapott.
A sok kijelző egyértelmű hogy további IC-ket igényel, de felesleges még egy "okos" eszköz.
Ide shift regiszterek kellenek(pl. 74hc595, de a MAX7219-21 se rossz ötlet), amelyeknek SPI-n kiküldhető
az adat minden multiplexeléskor. A kiküldendő adat tömbből való behelyettesítése meg nehogymár
feleméssze az 8MHz-en futó AVR maradék 99% processzoridejét, ezt Te is tudod hogy képtelenség!
Az I2C-t ebből a rendszerből szintén el kell felejteni, nehezen bővíthető, és érzékeny a sebességre!
Nyomógombok: egy SPI-s shift regiszter lefoglal 3 lábat az AVR-ből, 2-t az UART,
marad bőven a gomboknak! Ha nagyon sok gomb van, akkor lehet őket is multiplexelni...

Ennyi kijelzőhöz számtalan megoldás létezik, én mondok kettőt:
1: BCD dekóder minden 7s kijelzőre, ez 10 dekódert jelent. A dekódert shift regiszterek hajtják,
azaz egy 8 bites shift regiszter 2 BCD dekódert hajt. Tehát kell 5 shift regiszter.
A 3 darab 16s kijelzőhöz 3x2=6 shift regiszter kell vagy 3 darab TPIC, ahogy tetszik.
Ez a megoldás a lehető legnagyobb fényerőt hozza ki a kijelzőkből a statikus(nem multiplexált) hajtás miatt.
Programozás szempontjából ez a lehető legegyszerűbb megoldás, és kevesebb processzoridőt foglal.
2: multiplexálsz. Szintén shift regiszterek, csak sokkal kevesebb. A kijelzők közös pontjait tranzisztorokkal kell kapcsolni mert sem a shift regiszter, sem az AVR nem bír el 7-8 szegmenst. A tranzisztorokat szintén shift regiszterről hajthatod. Mivel nagyon sok kijelződ van, csoportosítanod kell(3-4 egy csoportban), egy csoporton belül a meghajtó tranzisztor közös lehet. 4-nél több csoport ne legyen mert annyival csökken az elérhető fényerő! A csoport kiválasztásához így elég lesz 1 darab shift regiszter, ezen kívül még annyi kell ahány kijelző van egy csoportban. A 16s kijelzőket itt tekintheted úgy, mintha egy páros kijelző lehet. A 7s kijelzőknél pedig multiplexálva is használhatsz BCD dekódert, ezzel felezheted a shift regisztereket. Gondolom érzed hogy áramkörileg, és programozás szempontjából ez valamivel bonyolultabb, cserébe kevesebb alkatrészt igényel.

Hali
Anno elég sokat zargattalak titeket a kérdéseimmel és most megint hozzátok fordulnék
Ez így persze nagyon primitíven hangzik, de a végeredmény amit el szeretnék érni az, hogy a kontrollerrel (persze külső modullal) küldjek SMS-t egy telóra, valamint az, hogy egy bejövő SMS-t olvashassak ki kontrollerrel egy kijelzőre. A körítés nem érdekel, mármint az LCD meg maga a kontroller működése és stb, mert sztem van már elég jártasságom bennük. Ami igazán érdekel az csak a céláramkör, ami mindezt megoldja és annak vezérlése, működése.
Tudom, hogy GSM modul kell hozzá, de konkrétabban még nem tudom miből is áll ez. A legfontosabb pedig: a lehetőségekhez mérten jó lenne valami olcsó darabot beszerezni. Tehát
- tudtok javasolni valami modul panelt amely jó ilyen célra?
- mit érdemes szemmel tartani egy ilyen modul vásárlásakor?
- tudtok adni esetleg valami linket/linkeket amin el bírok indulni a vezérlés, működés és megértés terén? Vagy valakinek esetleg személyes tapasztalata van erről?

Van itt egy panel, ami sztem irreálisan drágának tűnik a 27.000-es árával. Bővebben: LinkOlyan 10.000Ft körül lehet esetleg kapni hasonlót? Mert a linken említettben pl van Voice module, ami engem abszolut nem érdekel. A Chipcad-en is találtam ilyeneket, de azokról meg szinte semmi nincs írva (vagy csak én nem tom kezelni az oldalt) de ott elég szerencsétlen az online katalógus.

Ardino lapka + GSM modul.
Komplett mintaSW-k vannak hozzá... Árban 15-20 eFt körül már begyűjthető.
Sima sorosporti kommunikáció +- AT parancsok (kulcsszó: openAT)


Ami a kulcsszó a komplett holmira:
SIM900 + SMS + Arduino

Tipp: SMS + GSM

I2C esetén a bővíthetőség egyszerű. Simán fel kell fűzni... Járulákos AVRből is lehet alvezérlőt összehozni .
SPI esetén a ChipSelect a kiválasztójel.
Shiftregiszterek esetén a kiléptetés érdekes.

Mondjuk lassan költségvetést kell csinálni, mert sokféle megoldás hangzott már el...

Kezd lövésem sem lenni az egészről túlságosan bonyolult kezd ez lenni. Még álmodok róla, vagy redukálom a kijelzők számát.

Csak komplexnek _tunik_. Rajzolj blokkdiagrammot, hogy milyen feladatok vannak. Utána tedd át:
- megszakítás alpon mi megy?
- főprogramban (megszakíthatóan vagy minimálkéséséssel) mi mehet?
- egyes alfeladatok kiszervezhetőekl alrendszerbe?
- ezt hogyan oldhatod meg ill. kapcsolata a főrendszerrel (pl. adatfogadás)

Veszel egy regi siemens telefont, azzal lehet rs232-n kommunikalni. Egy ilyen mobil tenyleg filleres lehet ebayen, vateran.

Ahogy kolléga említette, egy régebbi Siemens teló is megteszi, ha gyári megoldás érdekel
akkor én a Quectel M10-es GSM modult ajánlom. Ez kb. 8k csomagban, 3k külön a modul.
SOS-nél keresd, máshol tudtommal nem is kapsz.
Illetve, kb. 3 hónapja az apróhirdetések közt is láttam hogy valaki GSM modulokat árul elég jutányos áron.

Az Arduino az kilőve. Nincs vele semmi különösebb bajom, de ha egyszer tudom kezelni az AVR-t önmagában is, akkor nem látom értelmét áttérni egy egyszerűbb környezetre. Ráadásul még azt sem erőltetem, hogy feltétlen AVR-t használok majd, majd ami épp kezembe akad. Viszont a leírás amit linkeltél iszonyú jónak tűnik. Már-már túl egyszerűnek is gondolom, hogy "mezei" soros porti utasítással minden megoldható, de ha valóban akkor annak csak örülök

Mondjuk van is kéznél régi Siemens telóm :S És soros porton mindenbe bele lehet babrálni, ami az SMS küldés/fogadásért felel?

Utánanézek a dolognak! Köszi

Ebben egészen biztos vagyok. Persze lehet siemens modelle válogatja. De egy kolléga tudom, hogy megcsinálta. Neki ráadásul én adtam kölcsön egy eredeti siemens soros port csatit. Igazából volt benne egy szintillesztő és kész.
Sőt, most jut eszembe, korábban azt mondtam, hogy RS232-n kommunikálnak, akkor szerintem ebben tévedtem, inkább 5V-os, vagy 3.3V-os jelszint lesz a helyes. AVR nyelven ez annyit takar, hogy UART.

Konkrétan, az én cuccom, amit korábban megépítettem, SMS-t írt,
és csak az UART-ot használta meg az AVR "kapcsolta be" a GSM modult,
meg még 2-3 státusz vezetéken kapcsolódott hozzá.
Pl. bejövő SMS esetében is aktiválódott a RI vonal...

Sziasztok! Segítséget szeretnék kérni tőletek! Van egy vfd óra kapcsolás, atmega8 ic-vel megvalósítva. Kompletten minden megvan hozzá, viszont közelmúltban szert tettem két atmega88 ic-re.(T-home beltéri előlapján vannak) Kérdésem a következő: miben tér el a két ic? Azt tudom, hogy a frekvenciában eltérnek, és elvileg ha jól bogarásztam ki a két ic adatlapjából, akkor a lábkiosztás egyezik. Az lenne a kérdésem, hogy mennyire ,,kompatibilis" egymással az atmega8 és az atmega88? Kell-e módosítani a programban valamit, és ha igen, mit? Előre is köszönöm a válaszotokat! U.i.: ha lehet kérni, akkor ,,konyhanyelven" írjátok le a dolgokat, mivel mikrovezérlőkhöz nem igazán értek... :hide: És még valami: TQFP tokos ic-im vannak, annak a lábkiosztását néztem(és a kapcsolás is ehhez a fajta tokozáshoz készült)

100% lábkompatíbilisek, nagyjából ugyanaz a felépítésük, ugyanazok az eszközök találhatóak meg benne. Mindkettőben 3 timer van, de a mega8-as esetében a 8 biteseknél egyetlen komparátor regiszter van,így csak 1-1 PWM-et tudnak kezelni. Az 1-es timer(16 bit) teljesen ugyanaz. A mega88-nál az USART regisztereiben és bitneveiben benne van egy "0" is(UDR0, UCSR0A, UBRR0[L/H], USBS01, TXEN0, stb...). Az STK500 programozómba mindkettő jó, egyedül ez utóbbira kellett egy pár soros makrót írni...
A mega88-ban 8MHz-es és 128kHz-es RC oszcillátor van, és ezt variálhatod a CKDIV8 nevű FUSE bittel(8-al leosztja). Kristály esetében nincs "CKOPT" nevű FUSE bit, helyette "Ext. Full-Swing Crystal..."-t kell választani, ugyanazt jelenti. A kódot mindenképp újra kell fordítani, ha hibát talál az csak abból eredhet hogy pár dolognak nem ugyanaz a neve.
És egy apróság: az IPTV box a T-Home tulajdona, és - hacsak nem bolhán vetted mint én - ne szedd szét!
A vinyó és a táp miatt vettem, 2 ezer egy 320gigás SATA vinyóért és egy 12V/3A tápért megérte.
Az előlapban én is megtaláltam a mega88 IC-t de nem bontom ki, inkább órát építek belőle.
Ja és ATMega88-hoz akciósan hozzájuthatsz az Urbán Elektronikánál, csak 400Ft/db.
Ha ATMega8 kell, abban Novak nevű kolléga tud segíteni, szintén jutányos árat fog mondani.