predstavme si ze je protokol nejaky jazyk ktory ked proste neovladas tak si moc nepokecas takisto ako C , C++ , python ... atd pokial ten nouma ktory sa ide hrabat v IoT si neporadi s SPI alebo I2C tak mu to asi nebude fungovat a to sme stale u toho T z IoT ... este ten nouma si musi poradit s tym I kde ho podla mna cakaju daleko daleko vacsie nastrahy ako komunikacny protokol.
nic proti tvojmu protokolu urcite ta to posunulo dalej a vela si sa naucil ale bitbang je nieco ako esperanto medzi jazykmi. a tvrdit ze bitbangovane pseudoSPI je bezpecnejsie je uplny nezmysel ... ba prave naopak buffery,interrupty,dma-cka,clocking, polarita atd atd robi protokol "bezpecnym"
ako proof of koncept dobry ale nevidim dovod to zacat pouzivat :)
happy hacking Sargon
Dne 18. prosince 2016 22:52 Robert Holub mrholub@hotmail.com napsal(a):
- Ja netvrdil ze je neco nezabezpeceneho na samotnem pouzitem protokolu,
ale moje vize je takova, ze v IOT bude delat jiz brzo kazdy nouma takze se vyroji spoustu zabugovanych zarizeni ktera budou mit velky potencial byt z toho duvodu spatne zabezpecena. Ne primo z duvodu protokolu ktery je pouzit.
Presne tak, je to bit - banging. Cilem je propojovat obskurdni zarizeni
a zkusit si vytvorit prenosovy protokol. U konkretniho vzorku ktery jsem predvadel to je 0-3.3v na strane RPI a 0-5V na strane Atmegy. Klidne si procti zdrojaky jsou jednoduche. IRQ jsme pouzit nezkousel, buffery take neresim. To by vsechno vec zeslozitilo a mym cile nebylo se chtit rovnat jinym protokolum ale stvorit neco jednodussiho.
Mr.Holub
On Sun, 18 Dec 2016 20:57:58 +0100, Tomislav Arnaudov sargonout@gmail.com wrote:
diky za odpovede ale :
- mozes uviest nejake priklady ? neviem co je spatneho zabezpeceneho na
i2c alebo spi , uart/usart atd ...
OK
v SPI sa pouziva vacsinou tam kde je potreba IRQ pin ktory prave hovori
nieco ako napr "uz mam plny/prazdny buffer" alebo "nove data su dostupne/zapsane vyber si je/zapis dalsie" atd...
s cim som mnohokrat narazil napriklad tak je polarita signalov u SPI a i2c ... ktora napriklad sa u tvojho protokolu asi vobec neriesi kedze sa jedna o cisto SW implementaciu v podobe "bit-bang" ... je to tak ?
Dne 18. prosince 2016 20:00 Robert Holub mrholub@hotmail.com
napsal(a):
- Nemel jsme na mysli nezabezpecene protokoly, ale spatne zabezpeceni
jako celek z duvonu uspechaneho vyvoje , snadnosti nastaveni (napr. defaultni hesla) a lace (napr. stare verze sw se znamymi problemy).
- To mne zmatl kamarad - spatne to pochopil, pak jsme se dohodli ze je
asynchronni.
- ACK je tam aby zarizeni mohla cekat jak dlouho chteji tj. i
nepravidelne, coz byl zamer. Cilem bylo udelat jednoduchy protokol, dokonce se lze bavit se zarizenim i rucne. Chip select tam je (CS), takze paralelne by zarizeni zapojit sla. Pravda, nezminoval jsem to a vlastne dosud ani nezkousel.
Mr.Holub
On Sun, 18 Dec 2016 12:58:34 +0100, Tomislav Arnaudov sargonout@gmail.com wrote:
Ahoj mr.Holub po skuknuti talku z Brmlabu mam par otazok
-prednaska zacina s tym ze IoT zariadenia pouzivaju nedokonale a ne-bezpecne protokoly , ako si k tomuto tvrdeniu dosiel ? -tvrdis ze tvoj protokol je synchronni - nacoz nasledne tvrdis ze zariadenie musi pockat na ack a komunikaci ridi master ... toto mi
nejak
nesedi v com je ta synchronnost ? -vychadzas z SPI protokolu ktory si degradoval pridanim uplne
zbytocneho
ACK signalu na 1:1 master slave protokol ... pricom si zabudol na
jednu z
najlepsich ficur tohoto protokolu a to je daisy chain
2016-12-18 11:35 GMT+01:00 Robert Holub mrholub@hotmail.com:
Ahoj,
tak jsem konecne publikoval svuj protokol,
https://github.com/mrholub/hcp
Communication-Protocol/
Mr.Holub _______________________________________________ Brmlab mailing list Brmlab@brmlab.cz https://brmlab.cz/cgi-bin/mailman/listinfo/brmlab
-- Using Opera's mail client: http://www.opera.com/mail/ _______________________________________________ Brmlab mailing list Brmlab@brmlab.cz https://brmlab.cz/cgi-bin/mailman/listinfo/brmlab
-- Using Opera's mail client: http://www.opera.com/mail/ _______________________________________________ Brmlab mailing list Brmlab@brmlab.cz https://brmlab.cz/cgi-bin/mailman/listinfo/brmlab