Ahoj pratele,
Tady je odpoved na dotazy:
Proc dalsi protokol:
1. Neodolatelna touha vytvorit si vlastni protokol. Lezel mi v hlave a jedina moznost jak zjistit zda by to fungovalo je... udelat to!
2. Snaha vytvorit protokol, kteremu bych rozumel na urovni bitu a napetovych urovni (vzpominam na hlasku jednoho sitare: "Tomu nerozumi nikdo. Ani ty co to vyvijej!").
3. Maximalni jednoduchost - takova krystalka mezi superhety. Mam pocit, ze takove veci v IT vseobecne chybi. Spise si doma clovek postavi krystalku ale "postavit superhet, to je quest" jak se vyjadril jeden problematiky znaly clovek.
4. Moznost komunikace sebedebilnejsich zarizeni, nehrozi problem synchronizace (viz. popis).
5. Kdyz se cokoliv pokazi, mam k dispozici ihned autora abych mu vynadal 24/7.
6. Je to podobne, jak kdyz nekdo leze na skalu. I kdyz nepokori rekord nebo po nem nenazvou nove obevene uzemi, dela mu to dobre.
Jaky problem jsem vyresil:
zatim uprimne jen pretlak v hlave - porad mi vrtalo hlavou zda by to tak mohlo fungovat. Planuji vymyslet rozlicna zarineni, kde by byl pouzit a tajne doufam ze to chytne dalsi. Napadlo mne, ze by bylo mozne propojovat ruzne plattformy s dostatecnym poctem I/O;
Porovnani s existujicimi protokoly:
Castecne to pripomina SPI, ale s oboustrannym potvrzovanim. Kamarad tvrdi, ze to pripomina PCI Express. Za porovnani s jinymi protokoly budu moc vdecny!
Jake plattformy jsem pouzil:
Pro Master - Raspberry PI
Pro Slave - Atmega8
Melo by fungovat vsechno co ma dost I/O pinu.
Nyni nasleduje dokumentace. Psal jsme ji jen pro sebe a tak neni prilis typograficky upravena. Pokud nekomu nebude neco jasne, ptejte se.
MISO ----------------------------- MOSI ----------------------------- SCK ----------------------------- ACK -------------- CHIPSELECT -----------------------------
Set up of IO on M and S:
M S
INPUT MISO OUTPUT OUTPUT MOSI INPUT OUTPUT SCK INPUT INPUT ACK OUTPUT
Initial State before communication 's start on both M and S:
SCK and MOSI gets HIGH, causing slave to put MISO and ACK high.
HIGH = 1 LOW = 0
MISO = HIGH MOSI = HIGH SCK= HIGH ACK= HIGH CS=HIGH
Slave waits for CS to be HIGH Slave waiting for SCK to be HIGH if necessary. Slave sets MISO and ACK HIGH when SCK is set HIGH.
End of byte transmission:
MISO = LOW MOSI = LOW SCK= LOW ACK= LOW
Slave sets ACK HI (if not already).
SLAVE sets MISO HI (if not already).
Master sets SCK LOW.
Slave sets ACK LOW
Master sets MOSI LOW (if not already).
SLAVE sets MISO LOW (if not already).
Communication:
==== sending of byte MASTER -> SLAVE ====
Master Slave
1] MOSI - set first bit (high = 1, low = 0)
2] SCK toggled (inverted)
3] BIT received from MOSI
4] ACK toggled that bit has been received
5] Repeat above for remaining bits
6]SCK is set to LOW after 8th bit to be able to leave the cycle without starting again
7]ACK is set to 0 8] waiting until ACK is 1 9]MISO is set to 0 10] waiting util MISO is 1
SCK is set to HIGH to send another byte
When CS is set LO then slave aborst communication -check for CS must be implemented in all of waiting loops.
==== sending of byte SLAVE -> MASTER ====
Slave waits for CS to be HIGH Slave waiting for SCK to be HIGH if necessary. Slave sets MISO and ACK HIGH when SCK is set HIGH.
necessary bits are sent from slave to master then:
Master Slave
1 ] MISO - set first bit (high = 1, low = 0)
2]ACK is toggled
3] BIT received from MISO
4] SCK toggled
5] Repeat above for remaining bits
6]SCK is set to LOW after 8th bit to be able to leave the cycle without starting again
7]ACK is set to 0 8] waiting until ACK is 1 9]MISO is set to 0 10] waiting util MISO is 1
To je vse. Pokud z prace odejdu zitra vecer rozume, tak to prinesu do brm ukazat. V soucasne dobe mam zarizeni schopne prijmout prikaz pro echo - prijmout talsi byte a poslat jej zpet.
Zatim ahoj and happy hacking,
Mr.Holub
On Wed, 23 Sep 2015 23:21:17 +0200, George Blackhead blackhead@blackhead.cz wrote:
Cau
Posli popis, me to zajima! Diky!
BH
-----Original Message----- From: Brmlab [mailto:brmlab-bounces@brmlab.cz] On Behalf Of Mr.Holub Sent: Wednesday, September 23, 2015 9:54 PM To: brmlab@brmlab.cz Subject: [Brmlab] Vymyslel jsme si vlastni prenosovy protokol - byl by zajem o prednasku?
Ahoj,
prave jsem zprovoznil na univrzalni desce prenos pomoci protokolu HCP (Holub's Communication Protocol). Mym cilem bylo vytvorit jednoduchy seriovy protokol, kde nema casovani vliv (obe strany cekaji jak je treba. Libilo by se Vam, kdybych to napr. tento patek prinesl vecer to Brmlabu a predvedl/popsal?
Zatim ma jedno testovaci zarizeni s prikazem prijmout 1B dat a poslat zpet. Pokud chcete, predem poslu jeho popis.
Mr.Holub
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Brmlab mailing list Brmlab@brmlab.cz https://brmlab.cz/cgi-bin/mailman/listinfo/brmlab
Brmlab mailing list Brmlab@brmlab.cz https://brmlab.cz/cgi-bin/mailman/listinfo/brmlab