Tag Archives: dev

Záchrana neřiditelného RC modelu skrzevá Arduino

Dítko během posledních dvou let v modelářském klubu postavilo maketu říčního remorkéru ČSPLO „Bečva„. Bezmála metrový model pro soutěže v kategorii F2B (Naviga) vypadá moc hezky….

Jpeg Celý příspěvek

Reklamy

komentáře 3

Filed under Mikrokontroléry - Arduino, ESP8266, Picaxe, ..., Počítače, vývoj HW a SW

Hodiny z pekla

Tchýně přijela na návštěvu a vypadá to, že neplánuje odjet? Zlobivý mladší sourozenec? Zbytečně dobré pracovní prostředí? Problém dokážeme snadno vyřešit s Arduinem!

Spousta lidí si stěžuje, že nemůže spát, když v místnosti tikají hodiny. Ale časem si stejně zvyknou. Co takhle to trochu vylepšit a udělat hodiny, které tikají nestandardně? Deset minut jdou běžným způsobem, pak se na půl minuty zastaví a následně zpoždění doženou… a pak zase čtvrt hodiny běží normálně. Tohle je daleko více obtěžující, než běžné tikání! A přitom ty hodiny jdou přesně – v každou chvíli je odchylka od aktuálního času menší než dvě minuty.

Tedy postavte si takovéhle super hodiny, nainstalujte je do místnosti, kde spí nechtěná návštěva, a pak už se jen kochejte výsledkem.

Celý příspěvek

Napsat komentář

Filed under Mikrokontroléry - Arduino, ESP8266, Picaxe, ..., Počítače, vývoj HW a SW

blynk.cc – rapid prototyping pro IoT (ESP8266, NodeMCU) s podporou mobilek

Blynk.cc je zajímavá platforma pro rychlé prototypování IoT řešení s vizualizací v mobilním telefonu. Pokud potřebujete vyzkoušet senzor a nechce se vám k němu psát serverovou stranu a mobilní front-end, Blynk může být správné řešení.

Podporuje Arduino (s ethernet/wifi shieldy), Particle … a napřímo podporuje i ESP-8266 (NodeMCU). A ta poslední varianta mne zaujala.

První aplikace je hotová za pět minut.

Nainstalujte si mobilkovou aplikaci a podle popisu zde založte první projekt. Získáte autorizační token.

Stáhněte si Arduino knihovnu z http://www.blynk.cc/getting-started/ . Je to ZIP soubor se čtyřmi podadresáři, které nakopírujete do adresáře libraries/ v adresáři s Arduino skeči. Restartujte Arduino IDE.

Udělejte jednoduchý skeč:

#define BLYNK_PRINT Serial // Comment this out to disable prints and save space
#include <ESP8266WiFi.h>
#include <BlynkSimpleEsp8266.h>
// You should get Auth Token in the Blynk App.
// Go to the Project Settings (nut icon).
char auth[] = "autentizační token";
void setup()
{
 Serial.begin(115200);
 Blynk.begin(auth, "ssid wifi sítě", "heslo wifi sítě");
}

void loop()
{
  Blynk.run();
}

No a teď už je možné do projektu v mobilce přidat načítání a zobrazení hodnoty libovolného digitálního či analogového pinu. To se udělá prostým vložením objektu Value display (prosté zobrazení), Gauge („budík“) či Graph (graf – hodinový, denní, měsíční). Jen vložíte na stránku v mobilce ovládací prvek a řeknete mu, jaký pin mikrokontroléru (Dxx, Axx) má obsluhovat. Stejně snadno je možno nastavovat hodnoty výstupních pinů. Na straně kontroléru nic neprogramujete. Neřešíte spojení, ukládání dat na server, vizualizaci – nic.

  

Ale co když chci připojit ke kontroléru něco, co se musí ovládat složitěji než prostým načtením hodnoty z pinu?

Za tímto účelem má Blynk virtuální piny V1 až Vxx. jejich hodnota není vázána přímo na pin kontroléru, ale je obsluhována v aplikaci.

Třeba si takhle připojíme k NodeMCU teploměr DS18B20. Nejjednodušší možné zapojení – napájení na 3.3 V, zem na zem, datový pin teploměru na pin D4 kontroléru a přes odpor 4k7 na napájení.

DSC_4226

Podporu pro OneWire sběrnici má NodeMCU v sobě, knihovna DallasTemperature pro čtení teploty se instaluje v manažerovi knihoven Arduino IDE automaticky.

Sketch vypadá takto:

Hlavička:

#define BLYNK_PRINT Serial // Comment this out to disable prints and save space
#include <ESP8266WiFi.h>
#include <BlynkSimpleEsp8266.h>
#include <SimpleTimer.h>
#include <OneWire.h> 
#include <DallasTemperature.h>

#define ONE_WIRE_BUS D4
#define TEMPERATURE_PRECISION 10 

OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire);
DeviceAddress thermometer;

SimpleTimer timer;

// You should get Auth Token in the Blynk App.
// Go to the Project Settings (nut icon).
char auth[] = "16a...........305032d";

Setup – enumerace zařízení na OneWire sběrnici, nalezení adresy teploměru a konfigurace Blynku:

void setup()
{
 Serial.begin(115200);

 sensors.begin();
 Serial.println("***************************************************");
 Serial.print("Pocet teplomeru: ");
 Serial.println(sensors.getDeviceCount(), DEC);
 //zjisti adresy
 oneWire.reset_search();
 if (!oneWire.search(thermometer)) Serial.println("teplomer nenalezen!");

 Blynk.begin(auth, "jméno wifi", "heslo k wifi");
  // jednou za tři sekundy chceme poslat teplotu
 timer.setInterval(3000L, sendUptime);   
 
}

A vlastní výkonná smyčka:

void loop()
{
 Blynk.run();
 timer.run();
}

Aha. Tady vlastně nic neděláme s tím teploměrem, že? Teploměr se načítá jednou za 3 sekundy – ve funkci sendUptime, která je volaná z timeru:

void sendUptime()
{
 //nastav rozlišení
 sensors.setResolution(thermometer, TEMPERATURE_PRECISION);
//načti všechny teploměry
 sensors.requestTemperatures();
 float tempC = sensors.getTempC(thermometer);
 
 Blynk.virtualWrite(10, tempC); // virtual pin 
 Blynk.virtualWrite(11, tempC); // virtual pin
if( tempC>26 )
 {
 Blynk.notify("Teplota moc velka!");
 }
  
}

Je tady vidět, že načtu teplotu z teploměru a pošlu jí do dvou virtuálních pinů – V10 a V11. Proč? Protože každý virtuální pin může na mobilce končit jen v jednom zobrazovači. Takže V10 bude zobrazovat aktuální hodnotu a V11 pošlu do grafu.

Jo a ještě pozor na červený text. Pokud na mobilce do projektu vložíte objekt „Push Notifications“, tak pomocí Blynk.notify můžete poslat push notifikaci. A fakt to funguje. Tj. nejen vlastní zobrazení stavu zařízení, ale i upozornění kdykoli.

Na mobilce jsem si udělal jednoduchý projekt: jednou display value z pinu V10, jednou graf z pinu V11. A tlačítko pro ovládání pinu D0 (tam má moje NodeMCU ledku). A prvek pro push notification. No a pak stačí kliknout na „spustit“ (trojúhelníček) a žije to. Na mobilce je vidět graf teplot i aktuální teplota; po kliknutí na tlačítko „led“ se rozsvítí nebo zhasne ledka:

Screenshot_2016-03-17-18-41-36

No a pokud teplota stoupne nad 26 stupňů (zub na grafu) … na mobilce vyskočí push notifikace. I když je mobilka suspendnutá a aplikace neběží.

Screenshot_2016-03-17-14-25-56

Výhody: Skvělé pro jednoduché testování. Nemusíte programovat front-end. Podpora push-notifikací.

Nevýhody: Není webový front-end, jen mobilkový. Nepřekvapilo by mne, kdyby to časem zpoplatnili.

Na okraj: Není nutné využívat jejich cloud. Blynk server si můžete nainstalovat i lokálně u sebe.

 

Napsat komentář

Filed under Mikrokontroléry - Arduino, ESP8266, Picaxe, ..., Počítače, vývoj HW a SW

Zkuste to bez drátů, pane Marconi!

(Prvotně publikováno 7.3.2014 na raspi.cz.)

Kterak k Raspberry Pi připojit bezdrátový senzor něčeho, třeba teploty.

Pro plánované zařízení jsem potřeboval, aby dva mikrokontroléry byly schopny si mezi sebou na vzdálenost pár metrů vyměňovat data bezdrátově. Po chvíli hledání jsem našel zajímavý komunikační čip od Nordic Semiconductors – nFR24L01+.

nFR24L01+ není jen tak obyčejné ASK-OOK pípátko, přes které se dá prodloužit sériový port. Tenhle čip funguje až na vrstvě 4 modelu ISO/OSI, tedy udělá za vás spoustu práce.  Vysílá na frekvenci 2.4 GHz (volné pásmo ISM – industrial, science, magic). Umí zpracovávat pakety o délce až 32 byte, které chrání pomocí šestnáctibitového CRC. Každý čip má nastavenou svou adresu (pětibajtovou) a je schopen přijímat data až od dalších pěti čipů. A automaticky obsluhuje potvrzení příjmu od protistrany. Tedy funguje to tak, že dáte čipu data a řeknete „odešli na stanici s adresou 1-2-3-4-5“. Čip autonomně odešle data a počká na potvrzení od protistrany. Když potvrzení nedojde, opakuje vysílání ještě několikrát. A na závěr vám řekne, zda se podařilo či nepodařilo data dodat na druhou stranu. Komunikace je přes SPI. No a to nejlepší na závěr: [tady] ho mají zabalený v hezkém hotovém modulu za 1.72 USD včetně dopravy do ČR! Tedy za tuhle cenu je jeden, potřebujete dva. Ale necelé 4 USD = 80 Kč za bezdrátový spolehlivý link mi přijde jako dobrá cena.

DSC_4913

Aby se mi neznámé zařízení lépe ladilo, rozhodl jsem se, že odesílat budu z mikrokontroléru, ale přijímat budu do Raspberry Pi, protože by se to mohlo časem taky hodit. Jako mikrokontrolér pro podobné hračky používám čipy Picaxe. Konkrétně v tomhle případě Picaxe 20M2. Stejně jako u populárních Atmelů (Arduino) je to kompletní mikrokontrolér, který má na čipu vše potřebné – analogové i digitální vstupy i výstupy, podporu I2C, sériového portu a spousty dalších věcí. Programuje se to v „basicu“ – syntaxí je to basic, ale sémantikou spíše assembler (pracujete přímo s registry/pamětí). Vývojové prostředí je zdarma. Největší rozdíly proti Atmelu/Arduinu jsou tyto:

  1. Pro programování nepotřebujete programátor ani jiné specifické USB hračky. K obvodu stačí dát dva rezistory a je možné ho připojit k běžnému sériovému portu, přes který se programuje a přes který umí posílat debugovací hlášení. Podpora pro sériový port může být i v hotovém zařízení. Je možné ho tedy přeprogramovávat kdykoli.
  2. Podporuje napájení 5 V i 3.3 V.
  3. Přímo na úrovni jazyka obsahuje spoustu knihoven, které pokrývají většinu úkolů. Potřebujete změřit délku impulzu? Načíst teplotu z 1-wire teploměru? Poslat data přes I2C? Na všechno jsou tam jednořádkové příkazy, které to umí samy.

Zapojení – vysílač – Picaxe

Na straně vysílače je to jednoduché. Všechny datové nohy bezdrátového modulu připojíme napřímo na nohy mikrokontroléru.

  • C.0  -> Nordic CE
  • C.1  -> Nordic CSN
  • C.2  -> Nordic SCK
  • C.3  -> Nordic MOSI
  • C.4  -> Nordic MISO
  • C.5  -> Nordic IRQ

Na další piny připojíme 1-wire teploměr DS18B20 (do standardního zapojení popsaného na webu Picaxe) a dvě LED diody pro signalizaci (komunikace OK, chyba). Zbývá už jen napojit napájení bezdrátového modulu. A tady pozor! I když jsou datové nohy modulu tolerantní k 5 V, napájení musí být 3.3 V! A ještě jedno upozornění: k napájení modulu je nutné připojit kondenzátor 10 uF. Dokud tam nebyl, chovalo se to divně.

DSC_4919

Schema zapojení:

DSC_4920

Zapojení – přijímač – Raspberry Pi

Tady P.T. čtenáře přesměruji [na tento článek]. Tam je to všechno step-by-step popsáno, včetně zapnutí SPI na straně Raspberry Pi.

DSC_4915

Zapojení je extrémně jednoduché – jen se propojí odpovídající piny RPi s odpovídajícími piny modulu.

RPi GPIO9 /MISO    (Pin 21)    – modul  pin 7 ( MISO )
RPi GPIO10/MOSI   (Pin 19)   – modul  pin 6 ( MOSI )
RPi GPIO11/CLK   (Pin 23)    – modul  pin 5 ( SCK )
RPi GPIO8/CE0     (Pin 24)    – modul pin 4 ( CSN )
RPi GPIO25  (Pin 22)    – modul pin 3  ( CE ) – tohle je jediná věc mimo standardní SPI zapojení, tímhle pinem se ovládá, kdy je modul rádiově aktivní
RPI 3.3V        (Pin 1)    – modul  pin 2 ( VCC/3.3V )
RPi Gnd         (Pin 6)    – modul  pin 1 (GND)

Software

Vhodný startovní kód pro Picaxe jsem [našel zde].

Kód pro Raspberry Pi je na již dříve [zmíněném odkazu].

Samozřejmě, že si spolu navzájem nerozuměly. Musel jsem postupně procházet datasheet obvodu a pochopit, co je potřeba změnit:

  • Obě strany samozřejmě musí mít stejně nastavenu linkovou vrstvu – frekvenci, rychlost, režim potvrzování.
  • Na straně přijímače musí být nastavená stejná délka paketu, jakou vysílač opravdu pošle.
  • Vysílající strana si nastaví odesílací i přijímací adresu na stejnou adresu, jakou má přijímač (!!!).
  • Odesilatel by si neměl vymaskovat stavové informace o odeslání paketu, přijímač by neměl nechat maskovat stavové informace o příjmu paketu.
  • No a pak nastane magie a začne to fungovat.

Finální kód pro obě strany najdete [zde].

Raspberry Pi tedy dostává každou chvíli paket o délce 1 byte, který obsahuje teplotu naměřenou na straně vysílače, přímo ve stupních celsia.

Finální řešení bude mít i na straně přijímače také mikrokontrolér Picaxe. Ale až někdy budete potřebovat něco měřit bezdrátově, vzpomeňte si na moduly nFR24L01+, možná budou váš problém řešit.

Jo a ještě zbývá doplnit dosah: na volném prostranství jsem měl data cca 25 metrů od vysílače. Přes dvě tlusté zdi to funguje na cca 8 metrů bez problémů.

Napsat komentář

Filed under Mikrokontroléry - Arduino, ESP8266, Picaxe, ..., Počítače, vývoj HW a SW

I/O v Javě, rychlé I/O, PWM modulace a tak dále

Prvotně publikováno na raspi.cz 29.3.2013.

V nedávném článku „Propojujeme Raspberry Pi a Arduino“ si Buben postěžoval, že

  • RPi postrádá PWM
  • Nelze rozumně spolehlivě reagovat na změny na vstupních pinech, protože synchronní polling by bral moc času procesoru a byl by z důvodu multiprocesingu v linuxu nespolehlivý

… a že tedy je lepší předat obsluhu I/O Arduinu.

S výsledkem této úvahy souhlasím. Složitější I/O nemá obtěžovat CPU, mají ho dělat kanálové procesory – tak nás IBM učí už více než 50 let. A volba Arduina není špatná. Nicméně předpoklady, na základě kterých Buben toto tvrzení postavil, jsou nepravdivé.

Pro spoustu aplikací stačí počet I/O portů, které má RPi – a pro spoustu aplikací stačí ihardwarová podpora, kterou má RPi pro řešení obou výše uvedených problémů.

Hardwarové PWM výstupy

Přímo na expanzním portu snadno najdete pin GPIO1 (18), což je zároveň výstup hardwarového PWM, které má RPi v sobě. Ale uznávám, že jedno PWM je nanic. Každý smysluplný kus železa potřebuje alespoň tři serva = tři PWM kanály. Co s tím?

Samozřejmě je blbost aplikačně simulovat PWM tím, že budeme na GPIO pin sypat jedničky a nuly. To by skutečně stálo všechen procesorový výkon a navíc by to nebylo spolehlivé  – přepínání tasků v linuxu by způsobilo nahodilé a nepříjemné výpadky v modulaci.

Ale co kdyby ty jedničky a nuly na výstup za nás sypal někdo jiný? Někdo, kdo to umí bez zátěže procesoru?

Ano, to je správná cesta. V paměti připravíme „obraz“ jednoho PWM pulzu (tj. třeba 500 nul a pak 500 jedniček = máme pulz s plněním 50%) a pak stačí říct řadiči DMA, ať tento kus paměti fixním tempem neustále dokola posílá na daný pin. A ejhle, funguje to.

Hotovou implementaci pro základní PWM najdete zde: https://github.com/sarfata/pi-blaster/

Detailnější popis je na stránce autora.

Aplikaci stačí nainstalovat a spustit (nebo nechat spouštět automaticky při bootu). Ovládání je pak jednoduché: Příkazem

echo "1=0.3" > /dev/pi-blaster

nastavíme pin 1 na PWM plnění 30%,

echo "1=1" > /dev/pi-blaster

dá plnění 100% atd. Zatížení procesoru je nulové a signál je hezky pravidelný, bez výpadků. Takto může být obsluhováno více GPIO pinů, defaultně jich pi-blaster řídí 8.

Pokud nechcete pomocí PWM řídit úroveň jasu LEDky, ale chcete ovládat serva, nepotřebujete „standardní“ PWM, ale trochu jiné. U serv je to tak, že frekvence pulzů by měla být 100 Hz; impulz o délce 1 msec je 0% výkonu, impulz o délce 2 msec je 100% výkonu. Kratší pulzy jsou chyba, delší taky.  Chce se vám s tím ladit? Jistě ne. Takže potřebujeme hotové řešení.

Najdeme ho tady: https://github.com/richardghirst/PiBits/tree/master/ServoBlaster

Výše popsaný projekt pi-blaster vznikl jako rozšíření myšlenky ServoBlasteru. Pi-blaster má hezčí implementaci (ovládání přes soubor).

Hardwarová detekce změny stavu GPIO pinu – jak nepollovat I/O procesorem

Procesor, na kterém je RPi postaveno, samozřejmě umí na změnu stavu vstupního GPIO pinu navázat přerušení.

Tedy zbývá jen zjistit, zda je tato služba podporována v linuxu a dá se používat?

Ano, je tam a funguje.

Tedy ve své aplikaci můžete snadno říct „až se změní stav GPIO0, zavolej mojí funkci X()“.

Test jsem provedl v Javě, což je pro real-time programování výrazně nevhodný jazyk. Nicméně Javu mám jako svůj denní nástroj a přemýšlím v ní; navíc jsem už líný používat pointery a podobné věci, ze kterých se v céčku dá postavit operační systém, a rád se od nich nechám odstínit.

Pro integraci Javy s GPIO na RPi existuje hezká knihovna pi4j. Více o ní napíšu za chvíli, ale ten důležitý výsledek testu je: interrupt-driven obsluha GPIO na RPi funguje. Za klidového stavu (tj. když se nic neděje, na GPIO nejsou žádné změny) to nežere žádný strojový čas. A v té ošklivé pomalé Javě to zvládá obsloužit až zhruba 2000 změn stavu za sekundu. A když přijde osamocený milisekundový impulz, neztratí se, Java ho dostane.

Podpora pro RPi GPIO v Javě – pi4j

Knihovna pi4j je přesně to, co potřebujete, pokud si chcete hrát s I/O na RPi ve vyšším jazyce.

Co umí?

  • Pro začátek samozřejmě obsluhu jednotlivých GPIO pinů. Nastavení směru, nastavení hodnoty.  A eventy o změnách stavu.
  • Taky je tam podpora pro I2C. Snadno můžete mluvit s I2C zařízeními.
  • Nezapomnělo se ani na sériové porty (UART).
  • SPI? No jasně.

Už tohle vše by bylo dobrým důvodem knihovnu používat, ale zde funkce teprve začínají. Autoři si totiž uvědomili, že když už mají dobře navržené abstraktní rozhraní pro GPIO, tak by s ním šlo obsluhovat víc věcí.

  • Máte na I2C připojený I/O expandér MCP23008 / MCP23009, o kterém jsem dříve psal? Tak si prostě místo standardního objektu „pin“ vyžádáte tento objekt od providera MCP23008GpioProvider. Toť vše. Veškerá další obsluha tohoto „drátu“ je stejná – je jedno, jestli pracujete s pinem přímo na expanzním portu, nebo s pinem za expandérem MCP23009. Wow!
  • Totéž samozřejmě platí i pro I2C I/O expandéry MCP23017 a PCF8574. A taky pro expandér MCP23S017 připojený přes SPI.
  • Koupili jste si expanzní desku PiFace? Kód je připraven.
  • Přímá podpora pro řízení krokových motorků. Stačí namapovat řídící vodiče a pak už jen můžete říkat „100 kroků plnou rychlostí doprava“.
  • Komunikace se senzorem Wii Motion Plus (modul s gyroskopem rozšiřující standardní ovladač pro Nintendo Wii, připojuje se přes I2C).
  • Obsluha LCD displejů.

Knihovna je hezky navržená a pro jednotlivé funkční bloky jsou tam hotové samply.

Jak rychle vlastně Java na RPi s I/O pracuje?

Udělal jsem takový jednoduchý test. Na jeden GPIO pin (výstupní) jsem připojil LED diodu, a zároveň jsem ho spojil na druhý pin – vstupní.

O změnách na vstupu jsem si nechal posílat eventy.

A pak jsem v jednoduché smyčce posílal na výstup jedničky a nuly.

Co jsem zjistil?

Maximální frekvence na výstupním drátu dosažitelná z mé aplikace byla zhruba 2 kHz. Nicméně kdybych si dal práci s nastavení JVM, mělo by to být výrazně lepší.

Pro délku jedničky/nuly 1 msec se už začaly některé eventy o změnách ztrácet. V průměru jsem dostal 986 eventů na 1000 změn. Vytížení CPU bylo tvrdých 100%. První eventy přišly až po cca 100 msec od zahájení vysílání – ale to je dáno přepínáním threadů v Javě; smyčka posílající 1/0 prostě nepustila procesor. Ale eventy se frontují, takže se povětšinou neztrácejí.  (U osamoceného milisekundového pulzu se eventa neztratila nikdy; ztrácení je skutečně funkcí objemu změn.)

Pro impulzy o délce 5 msec už vytížení procesoru spadlo na 50% a eventů dorazilo 998 z tisíce.

10 msec pulzy už vytěžovaly procesor jen na 30% a eventy se neztratily žádné.

Pro delší pulzy vytížení procesoru klesalo k neměřitelnosti.

A samozřejmě: když jsem takhle posílal na výstup třeba 100 Hz signál, na svitu LED byly jasně vidět nepravidelnosti . Linux prostě není real-time systém a občas vám procesor sebere na tak dlouhou dobu, že je to vidět jako zřetelné mrknutí LEDky.

Napsat komentář

Filed under Počítače, vývoj HW a SW

Ztracený den kvůli chybám v Javě

Příhoda je stará asi tři týdny, ale teprve teď mám čas jí napsat.

Vždy jsem za základní vlastnost Javy považoval její spolehlivost a stabilitu. Runtime bylo dobře odladěné, knihovny měly minimum chyb a případů, kdy aplikace spadla kvůli chybě Javy a ne našeho programátora, bylo minimum.

Vždy jsem se smál kolegům vyvíjejícím v .Net, kde každý deployment do složitějšího prostředí byl zdrojem adrenalinu již několik dní předem. Kolize verzí DLL x86 a x64, sdílené DLL přes celý systém atd… Java je přeci lepší, ne? 

Instaloval jsem u zákazníka nějakou naší úžasnou aplikaci. Samozřejmě napsanou v Javě. Takže nejprve Java runtime … jakou verzi tam dát? Novou 1.7.1? Tu ještě nemáme odzkoušenou v reálném světě, tak radši poslední 1.6.29. OK. Pak tam hodím aplikační kontejner (Glassfish). V něm připravím zdroje pro aplikaci – datasource pro databázi. Nastavím hodnoty pro spojení na MS SQL Server, zmáčknu PING, aby si je Glassfish ověřil … a nic. Žádná odpověď. Ne chyba spojení, ale prostě žádná reakce.

Restartnu Glassfish. Stále totéž. Nu což, budu to řešit potom, snad jsem vše zadal správně, Nainstaluju aplikaci, zkusím její testovací URL … a aplikace zatuhne. Ve chvíli pokusu o připojení do MS SQL aplikace zatuhne. Bez jakékoli hlášky.

Tak jsem experimentoval s nastavením logování, Glassfishe jako celku, systému. Vsjo marno. 

Tak tedy Google. Po několika dotazech jsem našel popis problému podezřele se blížícího tomu mému: článek 1, článek 2. Ukázalo se, že Java 1.6.29 nefunguje s MS SQL Serverem 2008 běžícím na Windows Serveru 2008 R2 x64, pokud je na serveru povolena SSL komunikace. Chyba asi není tak úplně v JDBC driveru od Microsoftu, spíše někde v socketové komunikaci. Verze 1.7.1 (a novější) resp. 1.6.26 (a starší) fungují OK.

OK. Tedy rychlá reinstalace Javy na 1.7.1, která má fungovat. Aplikace se rozbíhá, štěstí na všech stranách. Aplikaci jsem předal k testování.

O den později se mi aplikace vrátila. V nějaké obrazovce nefungovalo načítání souboru z disku. Soubor se hledal podle data. A vypadalo to, že se hledá podle data o dva dny jiného, než které je v databázi. Tak jsem vynadal programátorovi, že tam někde nechal hardcodované testovací datum. Programátor se samozřejmě vykrucoval, jak to tak vždy programátoři dělávají. A to natolik, že mi ukázal kód. A bylo vidět, že data skutečně bere z databáze.

V databázi je datum 2.11. Aplikace však vidí 31.10.

Co s tím? Být to o pár hodin, je to adept na problém s časovou zónou. Ale posun o dva dny se na časovou zónu shodit nenechá.

Takže zase logování, debugování a nakonec Google.

Sakra.

Zase je to chyba Javy. V javě 1.7.0, 1.7.1 při čtení sloupečku typu DATE (jen datum, ne DATETIME) může být vraceno datum o dva dny jinde. Prý se to děje nejen u MS SQL, ale i u Postgresu, našel jsem jinde.

Tak jsem downgradnul javu na 1.6.26 a už vše funguje správně.

Nicméně tyhle dva incidenty nás stály minimálně jeden člověkoden, možná i o něco více.

Poučení?

  • Java 1.6.26 je ta pravá a nové verze zkoušet velmi opatrně
  • Už neplatí, že runtime Javy je spolehlivý.

Blame Canada Oracle!

 

Napsat komentář

Filed under Počítače, vývoj HW a SW

Nelze se připojit na Oracle z Javy, ale sql*plus nemá problém…

Situace: sqlplus se na server připojí, ale javská aplikace dostane ORA-12505 „Listener nenašel takovou službu, jakou chcete“. Co s tím?

Java aplikace při pokusu o připojení k Oracle 10g dostane chybu

java.sql.SQLException: Vyjimka vstupu/vystupu: Connection refused (DESCRIPTION=(TMP=)(VSNNUM=169870080)(ERR=12505)(ERROR_STACK=(ERROR=(CODE=12505)(EMFI=4))))

ale SQL*PLUS se stejným nastavením normálně funguje? Jak je to možné?

Po chvíli hledání na netu jsem narazil na informaci, že je to způsobeno nevhodným nastavením serveru. Řešení je jednoduché: místo „prostého“ connection stringu ve tvaru

jdbc:oracle:thin:@server:port/instance

je nutno tučný text nahradit celým popisem konexe z TNSNAMES.ORA a do sekce „CONNECT_DATA“ přidat položku (SERVER=DEDICATED).

Tj. mám-li v TNSNAMES.ORA třeba

APPTEST.world =
(DESCRIPTION =
(ADDRESS_LIST =
(load_balance=off)
(failover=on)
(ADDRESS = (PROTOCOL = TCP) (Host = adb) (Port = 1529))
(ADDRESS = (PROTOCOL = TCP) (Host = apsdb) (Port = 1529))
)
(CONNECT_DATA = (service_name=APPTEST)(FAILOVER_MODE= (TYPE=SELECT) (METHOD=BASIC) (RETRIES=1440) (DELAY =5))
)
)

pak connection string pro Javu bude

jdbc:oracle:thin:@(DESCRIPTION = (ADDRESS_LIST = (load_balance=off) (failover=on) (ADDRESS = (PROTOCOL = TCP) (Host = adb) (Port = 1529)) (ADDRESS = (PROTOCOL = TCP) (Host = apsdb) (Port = 1529)) ) (CONNECT_DATA = (service_name=APPTEST)(SERVER=DEDICATED)(FAILOVER_MODE= (TYPE=SELECT) (METHOD=BASIC) (RETRIES=1440) (DELAY =5)) ) )

a problém je vyřešen.

Původní zdroj: http://www.websina.com/bugzero/kb/oracle-connection.html

Docela mne překvapil i ten samotný fakt, že je možno takhle connection string zapsat.

 

Napsat komentář

Filed under Počítače, vývoj HW a SW