- 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
>> >>
>> >> 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