Vlákno názorů k článku Inteligentní internetový termostat se sítí digitálních teplotních čidel od pasta - hlavně vzhledem k ceně. Sám používám PIC řady...

hlavně vzhledem k ceně. Sám používám PIC řady 16, pro které jsem rozchodil i TCP-IP stack, o kterém Microchip tvrdí, že s 16 kovou řadou nefunguje :) Komunikace s MCU pak probíhá přes ICMP pakety, vzhledem k jednoduchosti (není potřeba TCP, resp. UDP vrstva).

Skvela blbost. Takze mate nejaky radoby-TCP/IP, komunikujete zamerne skrz pakety, ktere k tomu nejsou urceny, a usetril jste rozdil v cene MCU, kterej bude patrne na zlomku ceny RJ45 konektoru. Pokud to TCP/IP provozujete na necem jinem, nez Ethernetu, pak se podelte o zkusenost, to by mozna byla jedina zajimava slozka projektu ;-)

Microchip TCP-IP stack je volně stažitelná a hlavně řádně zdokumentovaná knihovna. Viz http://ww1.microchip.com/downloads/en/AppNotes/00833b.pdf
Její hlavní účel je PIC řady 18 připojit na ethernet (např. pomocí ENC28J60). Je na Vás jak "vysoko" s komunikační vrstvou půjdete. Já zůstal u ICMP, protože každý krok výše (např. UDP) znamená více zabrané paměti dat a programu v MCU. Čili nemám žádný TCP/IP jak píšete, ale pouze IP, které je nezbytné pro ICMP :).

Jinak TCP/IP provozujeme ještě v zaměstnání na infinibanu, ale to je jiná story, která sem nepatří :)

Složitost a náročnost UDP (bez podpory skládání datagramu z více paketů), je úplně stejně náročná jako ICMP. UDP paket umí poslat a naroutovat každý blbec, ICMP ne.

nerozumím,

tyto dva zdroje vám umožní s ICMP jednoduše téměř libovolně posílat krátké zprávy. Hmm no asi nejsem blbec :)

http://en.wikipedia.org/wiki/Internet_Control_Message_Protocol
http://cboard.cprogramming.com/networking-device-communication/41635-ping-program.html

Chtel jsem predevsim rict, ze v dobe ARMu za 25Kc/ks v maloobchode (no ok, pro konkretni typ jsem si zkusenosti s IP nezjistoval) je ponekud podivne machrit, ze na mensim PICu neco sotva funguje,... ze vam to dela radost, to z nejakych obskurnich duvodu i chapu -- jak rika guru, nektere HW/SW pociny jsou jako stavba lodicky v lahvi (tolik casu a pritom takova blbost).

Infiniband je urcite zajimavej, ale veru zrejme mimo tema.

Ze je API pro ICMP mene samozrejmy napric prostredim klientu, to je zrejme (treba nevim, jak bych z MATLABu vyslal ICMP paket, prvni blbej priklad, kterej me napad).

ICMP hoďte ze skály. Složitost UDP (bez podpory pro datagramy složené z více paketů) je naprosto stejná jako ICMP, rozdíl je v tom že UDP paket umí vyslat kde kdo, ICMP ani náhodou ne.

pokud vyšlu ICMP nebo UDP, resp SNMP packet je čistě softwarová věc. Chápu, že někteří admini (a opravdu nejste sám) s tím mají problém. Jenomže tady jde o čas SW vývojáře. Nemám nejmenší problém přejít na SNMP, který je nad UDP, pokud mi to někdo naimplementuje. Sám řeším mnoho dalších problémů a nahrazovat plně funkční věc jinou funkční věcí jenom proto že se to někomu nelíbí....

Pro to se v praxi pouziva jedno rceni ktere se myslim sem hodi: "To zas vymyslel nejakej inzenyr..." Tak dlouho premyslel jak to udelat jednoduse az vymyslel paskvil jez neprosel diskusi s nekym s praxe.

Ad absurdum by se daly posilat jen etherneti framy a u prechodu na ciste ip by sedela nejaka gateway. Koneckoncu SNMP over Ethernet ma specku jeste z doby kamenne.
Eliminuje se tak nutnost IP stacku a vsech problemu s tim souvisejicich. Vsak ethernet neni dnes uplne vyjimecny ani ve svete WAN a koneckoncu se daji ethernet framy protunelit

No nevím, asi žiju v jiným světě. Operovat s teplotama v rozlišení min. 10b (aby to za něco stálo) vyžaduje min. 16b sběrnici, pro násobení 32b. Nebo to honit s pomocí SW, což zse sebere FLASH a zpomaluje. U nějaké potvory s pár kB do 20MHz to můžou být pěkný procenta výkonu...

Od doby, co mám nakoupenou zásobu 50MHz ARM7TDMI s 64kB RAM, 256kB FLASH, USB HOST, MAC, 2xSPI, 1x I2C, 64GPIO, 3x UART, DMA, RTC a osmi 32b čítačama na pár let za 70Kč kus, touhle vaší nemocí netrpím... :) Jenom dodat PHY pro LAN a je to.