GSM/GPRS modul
- nobody_hun
- Bitfaragó
- Hozzászólások: 425
- Csatlakozott: 2005. november 14. hétfő, 7:00
GSM/GPRS modul
Érdeklődnék valaki készített-e már alkalmazást ilyen modullal?
A feladat az lenne, hogy bizonyos események bekövetkezésekor küldjön egy SMS-t. Találtam 5110/6110 segítségével megvalósított megoldást, viszont nekem mindenképpen modult kellene használni.
A feladat az lenne, hogy bizonyos események bekövetkezésekor küldjön egy SMS-t. Találtam 5110/6110 segítségével megvalósított megoldást, viszont nekem mindenképpen modult kellene használni.
- nobody_hun
- Bitfaragó
- Hozzászólások: 425
- Csatlakozott: 2005. november 14. hétfő, 7:00
Nos sikerrel átrágtam magamat ezen a témán, íme az eredmény:
A lényeg:
Két féle üzemmódban lehet SMS-t küldeni, a kódban a bonyolultabb van, a PDU üzemmód. A neten sok helyen fennt van ez a megoldás, viszont BASCOM alatt nem akart egyik sem menni stabilan. Hol a telefon indult újra, hol pedig nem csinált semmit. Sokat zsibbadtam rajta, ezért közzéteszem, remélem mások örömére.
A text üzemmóddal nem foglalkozom, a GSM modulok egy része tudja, másik nem. Telefonok közül a text-et tudja a Siemens C35, Nokia 2110, meg még pár régi darab.
Ilyet nem tudtam szerezni, maradt a 3000Ft-os Ericsson T10 (jó a T18, T28, A1018).
Két drót kell hozzá (három ha visszaolvasni is szeretnél). Minden extra nélkül, 100 ohmon keresztül rá az AVR lábára, 5V táppal simán OK.
Kiosztás:
12 11 - 10 9 8 7 6 5 4 3 2 - 1
nn nn - nn n n n n n T G R- n
(2-re az AVR Tx lába, 3-ra a föld, 4-re a Rx)
A szoftver oldalról:
Az <AT+CPMS="ME","ME","ME"> utasítás a teló saját memóriáját jelöli ki a SIM helyett (ide fogjuk az SMS-t írni)
Az <AT+CPMS=nn> az SMS küldése, nn-ek helyén az átvitelre kerülő hexa darabszámát kell megadni. Ezután várakozni kell, a teló visszaad egy > karaktert.
A következő sorban kiírjuk a PDU üzenetet, majd CTRL-Z zárja.
Szöveg konvertálásához itt az oldal, onlány lehet kódolni, dekódolni. Az SMSC számát ha nem adjuk meg, akkor a SIM-en levő üzenetközpont számát fogja a telefon használni.
home.student.utwente.nl/s.p.ekkebus/portfolio/resource/sms_pdu.html
Rem:
Ne tévesszen meg senkit a szoftveres soros port, működik hw-s UART-tal is, csak én az alkalmazásban ellőttem másra a hw-s UART-ot.
Kód: Egész kijelölése
Sub Smssend
Open "comc.7:9600,8,n,1" For Output As #1
Open "comc.6:9600,8,n,1" For Input As #2
Print #1 , "AT+CPMS={034}ME{034},{034}ME{034},{034}ME{034}{013}{010}"
Waitms 500
Print #1 , "AT+CMGS=51{013}"
Waitms 200
Print #1 , "0011000B92XXXXXXXXXXF00000AA2A453D1D14D683E6ED391D14B44AE56536685D6793E9E536C85D5E97C92E50B3BE7E93D36B17{026}{013}{010}"
Wait 5
Close #1
Close #2
End Sub
Két féle üzemmódban lehet SMS-t küldeni, a kódban a bonyolultabb van, a PDU üzemmód. A neten sok helyen fennt van ez a megoldás, viszont BASCOM alatt nem akart egyik sem menni stabilan. Hol a telefon indult újra, hol pedig nem csinált semmit. Sokat zsibbadtam rajta, ezért közzéteszem, remélem mások örömére.
A text üzemmóddal nem foglalkozom, a GSM modulok egy része tudja, másik nem. Telefonok közül a text-et tudja a Siemens C35, Nokia 2110, meg még pár régi darab.
Ilyet nem tudtam szerezni, maradt a 3000Ft-os Ericsson T10 (jó a T18, T28, A1018).
Két drót kell hozzá (három ha visszaolvasni is szeretnél). Minden extra nélkül, 100 ohmon keresztül rá az AVR lábára, 5V táppal simán OK.
Kiosztás:
12 11 - 10 9 8 7 6 5 4 3 2 - 1
nn nn - nn n n n n n T G R- n
(2-re az AVR Tx lába, 3-ra a föld, 4-re a Rx)
A szoftver oldalról:
Az <AT+CPMS="ME","ME","ME"> utasítás a teló saját memóriáját jelöli ki a SIM helyett (ide fogjuk az SMS-t írni)
Az <AT+CPMS=nn> az SMS küldése, nn-ek helyén az átvitelre kerülő hexa darabszámát kell megadni. Ezután várakozni kell, a teló visszaad egy > karaktert.
A következő sorban kiírjuk a PDU üzenetet, majd CTRL-Z zárja.
Szöveg konvertálásához itt az oldal, onlány lehet kódolni, dekódolni. Az SMSC számát ha nem adjuk meg, akkor a SIM-en levő üzenetközpont számát fogja a telefon használni.
home.student.utwente.nl/s.p.ekkebus/portfolio/resource/sms_pdu.html
Rem:
Ne tévesszen meg senkit a szoftveres soros port, működik hw-s UART-tal is, csak én az alkalmazásban ellőttem másra a hw-s UART-ot.
- nobody_hun
- Bitfaragó
- Hozzászólások: 425
- Csatlakozott: 2005. november 14. hétfő, 7:00
Persze, ez egy valós alkalmazásból kiszedett kódrészlet.
Amire figyelni kell:
Ezt a részt cseréld le, a saját üzenetedre. Az X-ek helyén a saját telefonszámom volt, azért X-eltem ki.
A web teli van on-line PDU konverterrel, ott áttudod kódolni az üzenetedet PDU formátumra, a kapott sorozatot kell kicserélni, plusz a végére biggyeszteni a {026}{013}{010}-et.
Amire figyelni kell:
Kód: Egész kijelölése
Print #1 , "0011000B92XXXXXXXXXXF00000AA2A453D1D14D683E6ED391D14B44AE56536685D6793E9E536C85D5E97C92E50B3BE7E93D36B17{026}{013}{010}"
A web teli van on-line PDU konverterrel, ott áttudod kódolni az üzenetedet PDU formátumra, a kapott sorozatot kell kicserélni, plusz a végére biggyeszteni a {026}{013}{010}-et.
sms küldés fogadás
Szia !
Sajnos itt elveszett pont az a legfontosabb infó amit múltkor már elküldtél, egy sms küldés és egy sms fogadásra megirt programrészecske. Ha lehetséges hogy mégegyszer leírd ide és akkor végre el is mentem. Reménykedtem pedig hogy megmarad ...
Sajnos itt elveszett pont az a legfontosabb infó amit múltkor már elküldtél, egy sms küldés és egy sms fogadásra megirt programrészecske. Ha lehetséges hogy mégegyszer leírd ide és akkor végre el is mentem. Reménykedtem pedig hogy megmarad ...
- nobody_hun
- Bitfaragó
- Hozzászólások: 425
- Csatlakozott: 2005. november 14. hétfő, 7:00
Nos:
Mielőtt hozzálátnánk, ajánlott a baud=9600 és az ennek egész számú többszörösének megfelelő kvarc (7,3728MHz v. 14,7456MHz) használata.
Én úgy kezdtem, hogy a telefon RX lábát visszavezettem a PC-re és úgy monitoroztam, hogy az AVR-ből kimenő cuccra mit válaszol a telefon.
SMS küldés:
1., Megnyitjuk a soros kommunikációra a portokat. Értelemszerűen, ha nálad nem a portc.7 és portc.6 van használatban, akkor módosítani kell.
Itt a c.7 megy a teló TX lábára, c.6 pedig az RX lábra.
2., Belépünk a PDU üzemmódba:
3., Kiírjuk a PDU-ba kerülendő adatokat. Ide azt kell betenni, amit a PDU konverter visszaad, de figyelem, ebben a fogadó telefonszám is benne kell hogy legyen! (SMS központ nem érdekes, azt majd a teló kiolvassa a SIM kártyáról). Még 1 fontos dolog, nem szabad elfelejteni a végéről a CR+LF-t (026,013,010):
4., Lezárjuk a soros kommunikációt:
A sok wait azért van benne, hogy a telónak legyen ideje a parancsot feldolgozni, mert nem túl nagy a soros buffere. Ezért van 5 sec késleltetés az SMS szöveg után...
A fogadás kicsit bonyolultabb, erre most nem vállalkoznék (nem találom a forrást...), de lépésenként:
Belépés PDU üzemmódba, Rámutatás az SMS sorszámára, SMS beolvasása, PDU formátumból visszakonvertálás, SMS törlése.
Azért nehéz, mert meg kell írni a komplett PDU konvertert, ami nem egy egyszerű folyamat.
A görög srác ezt úgy oldotta meg, hogy a kapott SMS (pl: 1011001) binárisan meghatározza a port lábainak állapotát. A példánál maradva a a.7=1, a.6=0, a.5=1, a.4=1, stb.
Ha nem akarsz PDU konverterrel szórakozni, akkor a legegyszerűbb megoldás, ha a várt SMS PDU formátumú tartalmát hasonlítod össze azzal, amit a telefon fogadott.
Továbbá lehet fokozni, hogy ellenőrzöd a küldő telefonszámát, nehogy a szomszéd gyerek arra költse a zsebpénzét, hogy távirányítja a világításodat, stb.
Amit javaslok átnézni, az a T28 (~T10) AT parancskészlete, amelyet itt találsz meg:
http://www.vegeneering.com/environment_ ... 28-r1a.pdf
Ebben részletesen ki van vesézve minden parancs, amit az AVR-ről is tudsz vezérelni a
szintaktikával.
Mielőtt hozzálátnánk, ajánlott a baud=9600 és az ennek egész számú többszörösének megfelelő kvarc (7,3728MHz v. 14,7456MHz) használata.
Én úgy kezdtem, hogy a telefon RX lábát visszavezettem a PC-re és úgy monitoroztam, hogy az AVR-ből kimenő cuccra mit válaszol a telefon.
SMS küldés:
1., Megnyitjuk a soros kommunikációra a portokat. Értelemszerűen, ha nálad nem a portc.7 és portc.6 van használatban, akkor módosítani kell.
Itt a c.7 megy a teló TX lábára, c.6 pedig az RX lábra.
Kód: Egész kijelölése
Open "comc.7:9600,8,n,1" For Output As #1
Open "comc.6:9600,8,n,1" For Input As #2
Kód: Egész kijelölése
Print #1 , "AT+CPMS={034}ME{034},{034}ME{034},{034}ME{034}{013}{010}"
Waitms 500
Print #1 , "AT+CMGS=51{013}"
Waitms 200
Kód: Egész kijelölése
Print #1 , "0011000B92XXXXXXXXXXF00000AA2A453D1D14D683E6ED391D14B44AE56536685D6793E9E536C85D5E97C92E50B3BE7E93D36B17{026}{013}{010}"
Wait 5
Kód: Egész kijelölése
Close #1
Close #2
A fogadás kicsit bonyolultabb, erre most nem vállalkoznék (nem találom a forrást...), de lépésenként:
Belépés PDU üzemmódba, Rámutatás az SMS sorszámára, SMS beolvasása, PDU formátumból visszakonvertálás, SMS törlése.
Azért nehéz, mert meg kell írni a komplett PDU konvertert, ami nem egy egyszerű folyamat.
A görög srác ezt úgy oldotta meg, hogy a kapott SMS (pl: 1011001) binárisan meghatározza a port lábainak állapotát. A példánál maradva a a.7=1, a.6=0, a.5=1, a.4=1, stb.
Ha nem akarsz PDU konverterrel szórakozni, akkor a legegyszerűbb megoldás, ha a várt SMS PDU formátumú tartalmát hasonlítod össze azzal, amit a telefon fogadott.
Továbbá lehet fokozni, hogy ellenőrzöd a küldő telefonszámát, nehogy a szomszéd gyerek arra költse a zsebpénzét, hogy távirányítja a világításodat, stb.
Amit javaslok átnézni, az a T28 (~T10) AT parancskészlete, amelyet itt találsz meg:
http://www.vegeneering.com/environment_ ... 28-r1a.pdf
Ebben részletesen ki van vesézve minden parancs, amit az AVR-ről is tudsz vezérelni a
Kód: Egész kijelölése
Print #1,"AT{utasítás}{paraméter}
Üdv!
Ezeken már túl lennék, mármint a 2313-assal frankón küldök és fogadok sms-t.
Tovább szeretnék lépni a dologgal:
Hozzávalók az eddigi rendszer + Globalsat BR-355 soros (kábeles) GPS vevő
Mivel a vevőt csak úgy nem veszem meg, hasraütésre(18ezer pénz nettó).
GPS-es pda-val logoltam a soros portról lejövő adatokat.
Írtam egy progit ami PC-ről küldi AVR felé soros portra a log tartalmát.
példa:
$GPRMC,080749.380,A,4640.5383,N,01738.7455,E,0.74,96.78,160407,,*38
2313ben nem tudok akkora buffert megadni a mem-ben soros portnak hogy elférjen egy-egy teljes sora a gps adatoknak.
Próbáltam menet közben a bejövő karaktereket bufferből mindjárt a flash ram-ba írni, ez műkszik is de csak úgy ha a PC-s emulátorom karakterenként küldi a gps logot, ha sorvégét kapok akkor vége a parancsnak a ram adott részéről máris olvasható és sms-ben küldhető a koordináta.
Kérdés: ki hallott infót erről: a GPS egység milyen módon küldi az adatokat? Egyben kivág 70-80 karaktert, vagy egyesével sorban küldi.
(nem röhögni, nekem mindkét mód logikus )
Ha az első verzió van akkor hogy tudom én ezt beolvasni sorban egy 10 byteos bufferből ?
ha a második eset az általános akkor elvileg menteni tudom menet közben és utána feldolgozni...(még stringeket sem kell hozzá vagdalnom.)
A másik lehetőség félreteszem a 2313-at és átállok egy nagyobb procira, ajánlás kellene hogy mégis melyik milyen (tavir webshop-ban van adatlap tudom)
De konkrétan erre a célra milyen proci lenne jó, két hardveres uart, nagy buffer memória, gyors és nagy flash ram.
Nem szériában akarom majd gyártani hanem csak hobbi szinten kellene saját autóba...
Ezeken már túl lennék, mármint a 2313-assal frankón küldök és fogadok sms-t.
Tovább szeretnék lépni a dologgal:
Hozzávalók az eddigi rendszer + Globalsat BR-355 soros (kábeles) GPS vevő
Mivel a vevőt csak úgy nem veszem meg, hasraütésre(18ezer pénz nettó).
GPS-es pda-val logoltam a soros portról lejövő adatokat.
Írtam egy progit ami PC-ről küldi AVR felé soros portra a log tartalmát.
példa:
$GPRMC,080749.380,A,4640.5383,N,01738.7455,E,0.74,96.78,160407,,*38
2313ben nem tudok akkora buffert megadni a mem-ben soros portnak hogy elférjen egy-egy teljes sora a gps adatoknak.
Próbáltam menet közben a bejövő karaktereket bufferből mindjárt a flash ram-ba írni, ez műkszik is de csak úgy ha a PC-s emulátorom karakterenként küldi a gps logot, ha sorvégét kapok akkor vége a parancsnak a ram adott részéről máris olvasható és sms-ben küldhető a koordináta.
Kérdés: ki hallott infót erről: a GPS egység milyen módon küldi az adatokat? Egyben kivág 70-80 karaktert, vagy egyesével sorban küldi.
(nem röhögni, nekem mindkét mód logikus )
Ha az első verzió van akkor hogy tudom én ezt beolvasni sorban egy 10 byteos bufferből ?
ha a második eset az általános akkor elvileg menteni tudom menet közben és utána feldolgozni...(még stringeket sem kell hozzá vagdalnom.)
A másik lehetőség félreteszem a 2313-at és átállok egy nagyobb procira, ajánlás kellene hogy mégis melyik milyen (tavir webshop-ban van adatlap tudom)
De konkrétan erre a célra milyen proci lenne jó, két hardveres uart, nagy buffer memória, gyors és nagy flash ram.
Nem szériában akarom majd gyártani hanem csak hobbi szinten kellene saját autóba...
Soros buffer a config com1 segítségével adható meg. (méret: max. 254 byte)
Ha nem elég, akkor a URCX_INT-re lehet biggyeszteni megszakítást. ez minden bejövő karakter után megszakítást generál, így ki lehet kapdosni a bufferből a jött adatot.
2313 helyett a következő a Mega8 család lehet (M4888/168/8 illetve a M16/32 páros. Ezek DIP tokosak (praktikusan kezelhetőek). Az e feletti M64/128... SMD, sűrűlábúak (~64...100 láb).
Két uart (1 HW és SWből sok lehet), illetve a M64/128 esetén beépítve van 2 HW UART...
A Buffermemória mindben 16 byte (illetve az INT-re ráállva csinálsz egy nagyméretű string-tömböt, és abba kapdosod be a karaktereket).
Gyors és nagy Flash, az kötött. A flash sebesség kötött (proci órajel), a méret a chiptől függ.
Chipek túlhúzása nem javasolt (stabilan ~15-30% húzható)
A tradícionális chipek 16MHz (max 20-22), az újabbak 20 MHz (max. 22-25) órajellel bírnak. A programot tessék optimalizálni:)! Nem PC ez, hogy berakunk majd 300 MHz-s chipet:). Illetve ARM7/9-et...
Ha nem elég, akkor a URCX_INT-re lehet biggyeszteni megszakítást. ez minden bejövő karakter után megszakítást generál, így ki lehet kapdosni a bufferből a jött adatot.
2313 helyett a következő a Mega8 család lehet (M4888/168/8 illetve a M16/32 páros. Ezek DIP tokosak (praktikusan kezelhetőek). Az e feletti M64/128... SMD, sűrűlábúak (~64...100 láb).
Két uart (1 HW és SWből sok lehet), illetve a M64/128 esetén beépítve van 2 HW UART...
A Buffermemória mindben 16 byte (illetve az INT-re ráállva csinálsz egy nagyméretű string-tömböt, és abba kapdosod be a karaktereket).
Gyors és nagy Flash, az kötött. A flash sebesség kötött (proci órajel), a méret a chiptől függ.
Chipek túlhúzása nem javasolt (stabilan ~15-30% húzható)
A tradícionális chipek 16MHz (max 20-22), az újabbak 20 MHz (max. 22-25) órajellel bírnak. A programot tessék optimalizálni:)! Nem PC ez, hogy berakunk majd 300 MHz-s chipet:). Illetve ARM7/9-et...
Ne értsd félre a gyors flasht úgy értem, hogy elég az írási idő arra ahogy a bufferből kapdosom ki a karaktereket?
Nem fog torlódni és ezért elveszni stb...
Akkor "a soros buffer a config com1 segítségével adható meg. (méret: max. 254 byte)" szisztémával kezdem a próbálkozást ha hazaérek.
Az így látatlanba is elég világosnak tűnik. csak azt nem értem erre miért nem jöttem rá a doksikat bolhászva? tiny2313-ban is 254 byte a max méret?
Azt hiszem a MegaBoard ATMega32-vel lesz a következő fejlesztésem.
Optimalizálás: igyekszem...
Gépésztechnikus végzettségemmel, (semmi elektro suli) egy-két hét alatt eljutottam egy működő infra vevő (windóz Media playert irányítom vele) és az sms- küldés/fogadás rejtelmeibe.
De írok még olyat amiben sehol sem tartok: a mobil-ban van ugye akku, azt az autó rendszeréről tudom tölteni, de a mobilok 99% úgy van megcsinálva ha befejezi a töltést addig nem tölt újra (még ha totál kimerül akkor sem) míg a töltőáramot nem szakítom meg és kapcsolom vissza.
Ezt is még meg kell oldanom persze szoftveresen...
A gps-ről elég nekem a több másodperces szünetekkel olvasni, mert nem a realtime pozíció a lényeg, hanem ha lekérdezem sms-ben akkor ránéz mit mutat, összeállítom az sms-t PDU módban és elküldöm.
No mivel nincs elég memória az egész pdu karaktersor realtime kiszámolására (ehhe, sosem nincs memóra elég..) ezért az sms pdu karaktereinek az állandó része (címzett telefonszáma, egyéb fix karakterek) be van fodítva a szoftverbe, és csak a koordináták különbözőségéből adódó rész előállítása megy realtime, igy egy csomó helyet megspóroltam, de így a programot minden telszám változáskor újra be kell írni, és a kész panelra azé nem akarok spi csatit is tenni
még egy ötlet: két tiny 2313 egyik az smst írja-olvassa, a másik csak a gps-el foglakozik, igy lenne annyi hely hogy az sms-es prociba lehetne sms-ben küldeni konfigot amivel átállíthatnám a telszámokat stb...
És igy önálló egységként is megállná a helyét, ha meg van hozzá kötve egy gps-t olvasgató másik akkor kibővülne a funkció ezzel is.
Bár mindekttőnek külön táp, kvarc (de a memóriám is dupőla lenne ) minden az dupla költség de mint mondtam prototípusnak készül hobbiból szal nem számottevő a megtérülése
i2c buszon a két proci kommunikációja ugye megoldható lenne?
bocsi a hosszú rizsáért...
Nem fog torlódni és ezért elveszni stb...
Akkor "a soros buffer a config com1 segítségével adható meg. (méret: max. 254 byte)" szisztémával kezdem a próbálkozást ha hazaérek.
Az így látatlanba is elég világosnak tűnik. csak azt nem értem erre miért nem jöttem rá a doksikat bolhászva? tiny2313-ban is 254 byte a max méret?
Azt hiszem a MegaBoard ATMega32-vel lesz a következő fejlesztésem.
Optimalizálás: igyekszem...
Gépésztechnikus végzettségemmel, (semmi elektro suli) egy-két hét alatt eljutottam egy működő infra vevő (windóz Media playert irányítom vele) és az sms- küldés/fogadás rejtelmeibe.
De írok még olyat amiben sehol sem tartok: a mobil-ban van ugye akku, azt az autó rendszeréről tudom tölteni, de a mobilok 99% úgy van megcsinálva ha befejezi a töltést addig nem tölt újra (még ha totál kimerül akkor sem) míg a töltőáramot nem szakítom meg és kapcsolom vissza.
Ezt is még meg kell oldanom persze szoftveresen...
A gps-ről elég nekem a több másodperces szünetekkel olvasni, mert nem a realtime pozíció a lényeg, hanem ha lekérdezem sms-ben akkor ránéz mit mutat, összeállítom az sms-t PDU módban és elküldöm.
No mivel nincs elég memória az egész pdu karaktersor realtime kiszámolására (ehhe, sosem nincs memóra elég..) ezért az sms pdu karaktereinek az állandó része (címzett telefonszáma, egyéb fix karakterek) be van fodítva a szoftverbe, és csak a koordináták különbözőségéből adódó rész előállítása megy realtime, igy egy csomó helyet megspóroltam, de így a programot minden telszám változáskor újra be kell írni, és a kész panelra azé nem akarok spi csatit is tenni
még egy ötlet: két tiny 2313 egyik az smst írja-olvassa, a másik csak a gps-el foglakozik, igy lenne annyi hely hogy az sms-es prociba lehetne sms-ben küldeni konfigot amivel átállíthatnám a telszámokat stb...
És igy önálló egységként is megállná a helyét, ha meg van hozzá kötve egy gps-t olvasgató másik akkor kibővülne a funkció ezzel is.
Bár mindekttőnek külön táp, kvarc (de a memóriám is dupőla lenne ) minden az dupla költség de mint mondtam prototípusnak készül hobbiból szal nem számottevő a megtérülése
i2c buszon a két proci kommunikációja ugye megoldható lenne?
bocsi a hosszú rizsáért...
A kiolvasás az SRAM és nem flash:) területről megy. Igen, elég gyors...
A tinyben 256 az _összes_ sram, így a program, változók, bufferek (HW,SWStack) is foglal. Csak a maradékot oszthatod ki buffernak!
2 tiny felesleges. Árban már lassan a tiny2313 egy M8-as proci. Én nem vacakolnék vele. Nem is beszélve a forrasztási pontokról, és a SW optimalizáláshoz 2 chip közt...
I2C kommunikáció nehézkes. master-slave mód van, és a Tinyben nincs HW I2C. Így csak interrupt alapon megy, az meg zabálja az erőforrást....
Akkor már SPI módú...
De maradj az 1 chipnál. Könnyebb kezelni...
A tinyben 256 az _összes_ sram, így a program, változók, bufferek (HW,SWStack) is foglal. Csak a maradékot oszthatod ki buffernak!
2 tiny felesleges. Árban már lassan a tiny2313 egy M8-as proci. Én nem vacakolnék vele. Nem is beszélve a forrasztási pontokról, és a SW optimalizáláshoz 2 chip közt...
I2C kommunikáció nehézkes. master-slave mód van, és a Tinyben nincs HW I2C. Így csak interrupt alapon megy, az meg zabálja az erőforrást....
Akkor már SPI módú...
De maradj az 1 chipnál. Könnyebb kezelni...
No letesztelgettem a dolgot, sajnos ha van pl egy 50 byteos bufferem, ha ennél hosszabb adatot kap akkor felülíródik az eleje mielőtt kiolvashatnám.
van rá elvileg megoldás: CONFIG SERIALIN tud CTS-RTS kezelést, az adó megáll míg a bufferből ki nem olvasok egy egy adott mennyiséget és utána küldi tovább az adatokat.
Ha találok ilyen GPS vevőt ami kezeli a hardveres kézfogást, és nem csak 3 drótos (GND, RX, TX) akkor problem kipipálva, csinálhatok akár 3 byteos buffert is, és ki is tudom biztonsággal olvasni.
Köszi a segítséget holnap neten bolhászás lesz ilyen GPS cucc után, ami lehetőleg nem 200 ezerbe kerül és nem japánból kell megrendelni
van rá elvileg megoldás: CONFIG SERIALIN tud CTS-RTS kezelést, az adó megáll míg a bufferből ki nem olvasok egy egy adott mennyiséget és utána küldi tovább az adatokat.
Ha találok ilyen GPS vevőt ami kezeli a hardveres kézfogást, és nem csak 3 drótos (GND, RX, TX) akkor problem kipipálva, csinálhatok akár 3 byteos buffert is, és ki is tudom biztonsággal olvasni.
Köszi a segítséget holnap neten bolhászás lesz ilyen GPS cucc után, ami lehetőleg nem 200 ezerbe kerül és nem japánból kell megrendelni
Találtam egy jót:
Siemens XT55 GSM+GPRS+GPS modul
http://www.advocotechnologies.com/pdf/x ... v0206b.pdf
Robert légyszíves ha lesz egy kis időd nézd át (ehhe 160 oldal) csak annyira felületesen hogy érdemes-e ezt egyáltalán AVR-el kezelni mondjuk ATmega32 vel.
Amit én hamarjában kihámoztam, minden funkciónak van soros port kimenete (kettő is) , telefon részt szabvány AT parancsokkal lehet kezelni tud rts-cts-t minden finomságot.
Nincs szenvedés az akku töltés megoldásával, mert fel van rá készítve stb..
A GPRS rész:
"TCP/IP stack access via AT commands
Internet Services: TCP, UDP, HTTP, FTP, SMTP, POP3
Szal netre is nyitva minden formában."
Ellennék vele egy darabig...
Persze Megaboard is befigyelne mellé.
Ára chipcad kft-nél: nettó 24 570 Ft
Siemens XT55 GSM+GPRS+GPS modul
http://www.advocotechnologies.com/pdf/x ... v0206b.pdf
Robert légyszíves ha lesz egy kis időd nézd át (ehhe 160 oldal) csak annyira felületesen hogy érdemes-e ezt egyáltalán AVR-el kezelni mondjuk ATmega32 vel.
Amit én hamarjában kihámoztam, minden funkciónak van soros port kimenete (kettő is) , telefon részt szabvány AT parancsokkal lehet kezelni tud rts-cts-t minden finomságot.
Nincs szenvedés az akku töltés megoldásával, mert fel van rá készítve stb..
A GPRS rész:
"TCP/IP stack access via AT commands
Internet Services: TCP, UDP, HTTP, FTP, SMTP, POP3
Szal netre is nyitva minden formában."
Ellennék vele egy darabig...
Persze Megaboard is befigyelne mellé.
Ára chipcad kft-nél: nettó 24 570 Ft