- 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 <sargon...@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 <mrho...@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 >> <sargon...@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 <mrho...@hotmail.com>: >> > >> >> Ahoj, >> >> >> >> tak jsem konecne publikoval svuj protokol, >> >> >> >> https://github.com/mrholub/hcp >> >> >> >> http://www.instructables.com/id/Smart-Mouse-Trap/ >> >> >> >> http://www.instructables.com/id/Simple-6-wire-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
