No co by to dělalo? Zabírá to místo pro rozumnější články. A zas tomu chybí označení "komerční sdělení".
Nicméně pravdou je, že seriózní vývoj HW se na vidlích dělat prostě nedá a kdo by se drbal s widlema v dual bootu nebo na virtuálu kvůli proprietální a předražené technologii?
Co se simulací týká, tak starý dobrý Spice.
Desky dělám většinou v Eagle, ale je pravda, že Linux verzi se ještě nepovedlo instalovat kvůli vazbě na zastaralý knihovny. Ale widlácká verze ve Wine funguje bez problémů. Ještě jsem chtěl zkusit KiCAD, ale zatím na to nebyl moc čas.
Co se FPGA týká, tak Lattice Diamond na RHEL, například. Návrh čipů, no tak ten taky jaksi na widlích nerozjedeš. A když už máš nějakej větší procák s konektivitou apod. a potřebuješ začít dělat na firmware, tak nejlepší volba je ta, co se na widlích prakticky nedá realizovat - hodit tam tučňáka.
Eagle je fajn, při větších projektech se přechází na Alltium, OrCAD a další (Linuxí Eagle na Linuxu funguje, používám často)
KiCAD na doma proč ne, ale jak jsem psal, v profi sféře zatím nemá místo
Ať chcete nebo ne, Windows jsou stále důležité (protože není moc profi softu na Linuxu)
Moj kolega (Marek) este s dalsim kolegom si spravili na to nejake GUI v Qt na loadovanie tych iqrf prkotin, nejak reversovali komunikaciu aby to slapalo na linuxe. Potom ich zazracne skontaktovala aj ta ceska firma a dokonca sa dohodli na nejakej spoupraci, ze to spravia multiplatform Qt GUI aj s editorom sa mi zda ... No a nakoniec to nejak zakapalo ako vydim. (open-nandra.com/category/iqrf/)
Ta firma je uz od zaciatku dost nesympaticka. V dnesnej doen embedded aplikacii v linuxe maju len win gui?
Nejde jenom o GUI.
Jde o to, že pokud to se sběrem dat myslí vážně, tak se Linuxu nevyhnou. Minimum jsou open drivery pro Linux. Co když někdo bude chtít používat router s ARM a OpenWRT? Nebo na Turrisu 1 s PowerPC a OpenWRT? Nebo tam bude někdo mít desku s AMD Geode a Debianem? Nebo spolupráce s Rpi, Bpi, BeagleBoard apod.? S widlema jsou prostě v tomhle kšeftu out. A s binárním blobem samozřejmě taky, když by to zákazník chtěl na jiné architektuře, než panáčci ráčí dodávat...
A to GUI pro připojování zařízení by spíš našinec ocenil jako modul do LuCi a podobně, než jako widláckou klikací bestii. Prostě předražený a ještě v praxi nepoužitelný. Ale kdo chce kam,...
... neni out jako out, kdyz se najdou lidi, co cpu win10 na rpi
ale dobre jim tak (co je drahe, musi byt kvalitni)
:)
ale jinak: uz pri cteni prvniho dilu mi bylo jasne, ze je to cista PR (sice mne stve, ze redakce tyto clanky neoznacuji jako inzerci, ale to je jejich vec, jako je moje vec, ze mam alergii na jakoukoliv reklamu, nebo jinou formu vyplachu mozku)
musi se nechat, ze je to napsano citelne, profesionalne, presne ve stylu '15 lete praxe ve skolstvi' (postavim otazku ahned si pekne odpovim)
na druhou stranu mne to prestalo zajimat v momente, kdyz jsem videl, ze se jedna o uzavreny system ... co s tim ve srobarne?
Ano, Petře, máte 100 % pravdu, i já vidím budoucnost tam, kde Vy. Problém v nedorozumění je v tom, že právě pro zmíněná zařízení (Turris - i já si ho předobjednal a jeho podporu připravujeme) je určeno IQRF SDK, je to o Java, o C, připravují se další, ... pro zařízení však nemusíte dělat žádný divoký vývoj, moduly jsou řízeny daty, takže se o kompletní komunikaci například s UARTem někdě v síti, jako zákazník nemusíte řešit kde, kompletně se o to postará zcela otevřený DPA protokol. Není k tomu potřeba nutně přidávat nadřazený systém.
IQRF končí na "nějakém rychlém rozhraní směrem ze sítě" a největší úsilí věnujeme právě knihovnám, aby si kdokoliv, pro toto rozhraní na platformě, která jemu vyhovuje, rychle zrealizoval to, co potřebuje. Jedno, zda je to Domoticz, Linux, WIN - je potřeba umět poslat jenom paket po UARTu, SPI, PCIe, USB, ...
A ano, byť tlak na vývoj těch nejnižších vrstev není vzhledem k výše uvedenému veliký, a ano, i proto, že Linuxáři si poradí s mnoha problémy mnohem kreativněji, přesto podporu vývoje i těch nižších vrstev (zde se bavíme o IQRF IDE) máme již zařazenu do plánu připravit. Jen jsme malou frmou, takže to nebude hned.
Hraje si s tím někdo ? Dá se ten stack srovnat se ZigBee nebo alespoň SimpliciTi ? Má to nějaké zabezpečení přenosu ? Kolikabitovou architekturu má ten HW, jak je to rychlé a kolik to žere ? Kolik má ten HW volného místa pro programy ? Dá se do toho dostat alespoň enumerace OneWire ?
Omlouvám se, Ondřeji, pracovní týden můj i dalších kolegů z R&D je trochu delší, takže, byť na ROOT.cz chodím, není to každý den, do diskuze navíc vstupuji poprvé, proto ta pomalejší reakce:
BEZPEČNOST:
- teď: proprietární šifrování založené na 128 b XTEA
- hotové, uvolněné k testování: 128b AES, dynamická změna klíčů, síťová hesla 192 b, ochrana
konzistence paketů, automatické šifrování síťových paketů, ochrana bondování, vrstevnatá architektura,...
- naše brány snad ani SMS neobsluhují; pro IQRF jsme sice vytvořili i vlastní brány, hlavně však pro inspiraci, úsilé směřujeme k IQRF SDK, aby si kdokoliv mohl vytvořit svou vlastní bránu ke svému oblíbenému cloudu a pro své oblíbené prostředí, řekl bych, že IQRF končí před GW; moje představa je kompletní otevřenost, i proto je k dispozici zcela zdokumentovaný DPA protokol, který umožňuje kompletní datové řízení periférií někde v síti
- myslím si, že je za námi vidět těch 12 let, co jsme na platformě pracovali, přestože nám na začátku každý říkal, že jsme příliš malí, že není šance, že všude bude Zigbee, protom, že všude bude A a pak B ... no, a dnes říkám, že náš nejlepší zákazník je ten, co si zkusil ZIgbee, neexistuje ani A, ani B, jsme trochu větší, přesto stále malí, ale pokud nebudeme mít odvahu, nikdy nebude nic než to, co nám vnutí někdo, kdo má peníze na marketing a tvrdí, že je to nejlepší ...
- musím se zároveň zastat šéfredaktora: žádnou komerci jsme neplatili; nevím, jak to kolegyně dokázala, že to tu je, sám bych to zde nečekal, ale prostě připravila seriál článků s cílem popsat IQRF, napsala to, jak i zaznělo v diskuzi, kvalitně, a ... zřejmě nikdo jiný nenapsal nic jiného
- směřujeme k maximální podpoře datového řízení, bez nutnosti programování nižších vrstev modulů (skoro vše je uvnitř) proto IQRF IDE (zatím) nepodporuje nic jiného než WINs (zdůrazňuji to "zatím"). Podpora je především pro vyšší vrstvy, od rozhraní (ano, ty prolkínané brány) nahoru, zde je to pro C, Java, kolegy směřuji do podpory Pythonu, cílem je RESTful a kompletní svoboda výběru brány, poskytovatele služby, cloudu i aplikace ...
- jinak, příští týden v Praze na IQRF konferenci představíme základní koncept IQRF.zones, již zmíněné zabezpečení, otevíráme i základní specifikaci IQMESH paketů, a, jak jsem již zmínil, nikdo v naši firmě si nemyslí, že budoucnost je v uzavřených systémech, takže mnoho toho bude především o: platform, open, freedom to choose
- ano, Vaší optikou jde zřejmě o IoSt, protože je to určené aplikacím s málo daty, které IQRF umožní opravdu spolehlivě data přenést; strávil jsem posledních 10 let návrhem příslušných protokolů a rád si s Vámi na toto téma popovídám, ale spíše někde u kafe nebo ještě raději u čaje
Díky, to už zní lépe (pokud zamhouřím oko nad homebrew crypto), ale pak nechápu, proč to tak tajíte. Informace o zabezpečení kanálu by měla být v prvním článku popisujícím architekturu, ale hlavně zde, kde jsou ukázky, jak nastavit síť. A hlavně to má být integrální součást protokolu, a nikoli něco, co si uvědomělejší integrátor zapne někde hluboko v nastavení.
Zdravim,
Hraje si s tím někdo ?
ANO :-)
Dá se ten stack srovnat se ZigBee nebo alespoň SimpliciTi ?
ANO
- uživatel nepotřebuje stack, veškerá funkcionalita včetně podpory mesh sítí již integrována
Má to nějaké zabezpečení přenosu ?
ANO,
- teď: proprietární založené na 128 b XTEA, hotové uvolněné k testování: 128b AES, dynamická změna klíčů, ochrana konzistence paketů
Kolikabitovou architekturu má ten HW
- 8b
jak je to rychlé a kolik to žere ?
- je to pomalé odpovídající aplikacím pro které je to určené, ~20kb/s
- TX: 21 mA, RX: 13 mA, LPRX: 220 uA, XLP RX: 25 uA
Kolik má ten HW volného místa pro programy ?
- málo:
--- nad IQRF OS jsou k dispozici cca 4 k instrukcí je
--- pokud se použije DPA (modul je kompletně řízen daty) 3/4 k instrukcí + 1/4 k handler
Dá se do toho dostat alespoň enumerace OneWire ?
- je v příkladech
Zřejmě je to otázkou konkrétní aplikace a rychlosti jejich vývoje, nemyslím si, že by naši zákazníci (=výrobci nějakých zařízení) moduly využívali pro své výrobky právě proto, že by byly předražené :-)
Daty řízený modul (DCTR) umožní zákazníkovi získat spolehlivý přenos až ke konkrétní periférii někde v mesh síti, se spoustou zabudovaných nástrojů pro správu sítě, efektivní sběr dat (FRC) atd. ... prakticky OKAMŽITĚ, bez nutnosti řešit problematiku mesh sítí, doručování, potvrzování, bezpečnosti.
Možná je to špatná cesta, uvidíme,
Ano, máte pravdu :-)
- jenom k němu připojíte k němu ATMEGA
- pak se ponoříte do problematiky mesh sítí
- pak si napíšete aplikaci
No, souhlasit nemohu - srovnovávat hrušky a třeba borůvky sice jde, obojí je to ovoce, ale každé z těch dvou ovocí má svá specifika. Daty řízené moduly, ke kterým již jen připojíte to, co potřebujete, a nestaráte se již o síť (ano, trochu jsem to zjednodušil) srovnávat s čínskými moduly, kde si vše ostatní doděláte, je možná trochu nekorektní.
Na druhou stranu, pokud nepotřebujete řešit mesh, spotřebu, atd. ... existují i lepší a levnější alternativy než to vygooglené :-)
Luboši, myslel jsem pouze ten vygooglený modul, ne že byste zde fabuloval, omlouvám se, pokud to tak vyznělo :-)
"Udělat si sám" má spoustu podob, závisí, co zrovna ten který člověk potřebuje vyřešit, jaké má nároky, co potřebuje od výsledku, za jak dlouho má být výsledek odevzdaný, ... pokud budete mít někdy čas, jukněte na http://doitwireless.com/ ... jsou tam konstrukce postavené na IQRF přesně z tohoto pojetí "udělej si sám"
Bastlíři a vývojáři z celého světa měli 3 měsíce šanci získat nejnovější moduly se slevou 20%. Bohužel akce už skončila.
http://chiptron.petus.cz/viewpage.php?page_id=18