Re: [Brmlab] Vymyslel jsme si vlastni prenosovy protokol - byl by zajem o prednasku?

Ano, jeden z cilu bylo vypustit potrebu presneho casovani. Kolize se neresi, protoze komunikace probiha vzdy jen jedna. Dokonce se lze se zarizenim bavit rucne - pomoci tlacitek a ledek ;-). Pokud mi to zitra vyjde, pritahnu to do brm.

Mr.Holub

On Thu, 24 Sep 2015 19:25:39 +0200, Jan Hrach jenda@hrach.eu wrote:

Mně se líbí že to nemá deadlines, nepotřebuje to přesné hodiny a tak.

Myslím, že neřešíš kolize, když master bude chtít poslat bajt a současně slave bude chtít poslat bajt.

On 24.9.2015 18:47, Mr.Holub wrote:

...

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