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
<blackh...@blackhead.cz> wrote:
Cau
Posli popis, me to zajima!
Diky!
BH
-----Original Message-----
From: Brmlab [mailto:brmlab-boun...@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
--
Using Opera's mail client: http://www.opera.com/mail/
---
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
