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
Jeden protokol s Holubami uz tu predsa bol :-)
https://www.ietf.org/rfc/rfc1149.txt
On Wed, 23 Sep 2015 22:59:59 +0200, Pavol Rusnak stick@gk2.sk wrote:
Jeden protokol s Holubami uz tu predsa bol :-)
Pobavilo, to jsem neznal... ;-)
-----Original Message----- From: Brmlab [mailto:brmlab-bounces@brmlab.cz] On Behalf Of Pavol Rusnak Sent: Wednesday, September 23, 2015 11:00 PM To: brmlab@brmlab.cz Subject: Re: [Brmlab] Vymyslel jsme si vlastni prenosovy protokol - byl by zajem o prednasku?
Jeden protokol s Holubami uz tu predsa bol :-)
https://www.ietf.org/rfc/rfc1149.txt
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
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
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:
Neodolatelna touha vytvorit si vlastni protokol. Lezel mi v hlave a jedina moznost jak zjistit zda by to fungovalo je... udelat to!
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!").
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.
Moznost komunikace sebedebilnejsich zarizeni, nehrozi problem synchronizace (viz. popis).
Kdyz se cokoliv pokazi, mam k dispozici ihned autora abych mu vynadal 24/7.
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 LOWMaster 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 received5] 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 08] 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 toggled3] 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 08] 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
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:
- Neodolatelna touha vytvorit si vlastni protokol. Lezel mi v hlave a
jedina moznost jak zjistit zda by to fungovalo je... udelat to!
- 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!").
- 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.
- Moznost komunikace sebedebilnejsich zarizeni, nehrozi problem
synchronizace (viz. popis).
- Kdyz se cokoliv pokazi, mam k dispozici ihned autora abych mu
vynadal 24/7.
- 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 LOWMaster 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 received5] 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 08] 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 toggled3] 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 08] 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
A clovek by rekl, ze tech protokolu uz existuje dost :)
Ne, ted vazne. Jaky problem jsi tim vyresil? Jaky je k tomu potreba HW? Bohuzel nemam prilezitost chodit do brmlabu, takze se ptam aspon takhle...
eddy
On 09/23/2015 09:54 PM, Mr.Holub wrote:
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
A dělal jsi resersi ohledně novosti? Když tak mi pošli popis a já ho porovnam s existujícími (LINET, jablotron atd.) 3b Dne 24. 9. 2015 8:05 napsal uživatel "Dominik Taborsky" bremby@seznam.cz:
A clovek by rekl, ze tech protokolu uz existuje dost :)
Ne, ted vazne. Jaky problem jsi tim vyresil? Jaky je k tomu potreba HW? Bohuzel nemam prilezitost chodit do brmlabu, takze se ptam aspon takhle...
eddy
On 09/23/2015 09:54 PM, Mr.Holub wrote:
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
-
Dominik Taborsky -
George Blackhead -
Jan Hrach -
Jan Vojíř -
Mr.Holub -
Pavol Rusnak