> A kivétel annyit jelent, hogy külső programozóval kell beírni a sketchet és kész?
Igen.
> Melyik külső programozó ajánlott?
Mindegy, csak működjön. :-)
Ha úgyis van több Arduino-d, akkor az UNO-ra tudsz feltölteni olyan programot (mellékelve az Arduino IDE-hez Arduino ISP néven), aminek a segítségével fel tudsz programozni egy MCU-t.
Én csináltam magamnak shieldet is, amin vannak állapotjelző ledek, meg többféle csatlakoztatási lehetőség (IC foglalat, ISP csatlakozó, stb.)
Sokat használtam, mielőtt lett volna dedikált programozó. Most AVR Dragont és JtagIce-t használunk. A Dragon az nem drága, és lehet vele debuggolni is.
Ha szeretnél olcsó, dedikált programozót, akkor nézz körül a tavir.hu oldalon! Árulnak is programozót, de a teljes kapcsolása és programja is fent van (open source), elkészítheted magadnak is.
Szerintem egy mikrovezérlő nem billegtethet kimeneteket bekapcsoláskor vagy resetkor, mert az a ráakasztott perifériát működtetni fogja. Bemenetként kell indulni, és majd ha a programban outputnak deklarálom, akkor már villoghat, de addig egyet se.
Sose fogom teljes mértékben ismerni az arduinot, csak annyi energiát fektetek bele, amivel a kitűzött célt elérem. Erre jók a fórumok, ahol a különböző tapasztalatokat meg lehet osztani, választ lehet kapni kérdésekre sokkal gyorsabban, mint a dokumentáció tanulmányozásával. És pont az ilyen hw viselkedések a nehezebben kideríthetők, egy programozási kérdésre sokkal könnyebben találni választ a példákban, reference-ekben.
Paksot nyilván nem szó szerint kell érteni, de lehet rajta olyan, amit nem szabad kapcsolgatni ilyen rövid időn belül, mert tönkremegy, vagy valami mást tesz tönkre. És hiába programozom be szépen az időket, ha induláskor önállósítja magát, és pár másodperc alatt 10-szer kapcsolja be a portot.
De tkp. fölöslegesnek látszik ezen agyalni, nem pc usb portra dugva fog működni, és táppal meg jól viselkedik.
> Az a baj, hogy bármi okozza, mi van ha azon a porton van Paks, akkor elkezdi kapcsolgatni pár másodpercig?
1. Milyen porton?
Az RS232 szabvány leírja, hogy milyen adatvezetékeket használ, milyen feszültségszinteken, mi jelenti a nullát, mi jelenti az egyet, stb.
Napjainkban két vezetéket használunk ezekből a legtöbbször: Tx, Rx. Adat küldés és adat fogadás.
Valamint nem az eredeti feszültségszinteken (-15 Volt +15 Volt), hanem TTL (0 és VCC) között.
A DTR, DCD, DCE, DTE, stb vezetékeket már nem nagyon használjuk. Ezeknek a buta terminálok korában volt funkciójuk. Ma is benne vannak minden soros eszközben, csak nem, vagy nem az eredeti funkciójukra használják őket. Benne van az adott rendszer dokumentációjában.
2. Ismerni kell a rendszert, amivel dolgozol. Van dokumentáció, és abban le van írva. Az Arduino rendszer tervezésénél NEM volt szempont a megbízhatóság vagy a biztonságkritikus működés. Az egyszerű és gyorsan tanulható, rövid időn belül sikerélményt adó játszadozás a célja. Ehhez tartozik az auto resetes feltöltés a bootloader várakozással együtt.
3. Paks nem Arduino-ra van kötve, valamint a tervezők és az üzemeltetők ismerik a specifikációját annak, amit használnak.
Az a baj, hogy bármi okozza, mi van ha azon a porton van Paks, akkor elkezdi kapcsolgatni pár másodpercig?
Közben próbáltam tápról is de szintén az usb aljzatba dugva, és akkor nem csinálja, 1 és 2 s között valahol elkezdi a normál villogást mindkét board, az uno kicsit hamarabb. Tehát valószínű, hogy a pc karattyol valamit az usb-n, és ez ilyen portkapcsolgatáshoz vezet.
A portkiosztás attól függően változhat, hogy melyik USB portra dugod fel, de ez természetes.
Igen, nálam egy porton mennek az usb-s eszközök hubbal. Van egy másik a scannernek, meg egy harmadik az usb-s wincsinek, de azok fixek. A hub is variálja, minden lukban más a portszám. Nincs ezzel gond, csak valamelyiken menjen.
A bekapcsoláskori villogás a bootloader alapvetően. Ha valami történik a soros porton, függetlenül attól, hogy pontosan mi az, az RX/TX villogni fog. Ha van még mellette port nyitás, akkor a boot is belejátszik pluszban a villogásba.
Tápról nincs ez a jelenség, csak pc usb porton.
A Bootloadert ki tudod szedni, de az, hogy azt visszafejtsd elég komoly felkészültség kell úgy szoftveresen, mind tudásban, mind eszközökben. Az Uno és a Nano bootloadere eltér egymástól, ezért az eltérő villogás.
Nem is a bootloaderre lettem volna kíváncsi, hanem a gyárilag beletöltött sketchre. De persze ezt nem lehet kiolvasni, csak az assembly kódot, azzal meg nem tudok mit kezdeni.
Végülis ez a pc usb portján lógás meg serial monitorozás csak a fejlesztéskor érdekes, a tyúkólban már nem lesz ilyen, hanem táp és rs485/BT/ethernet/rádió.
Fogyasztáscsökkentési céllal az összes led kiiktatására mit javasoltok? Ellenállásokat vagy ledeket leforrasztani vagy fóliát átvágni?
A Serial port, mint csatlakozó felület / kommunikációs szabvány, nem tud resetelni semmit. :-)
Az Arduino panelek java része úgy van kialakítva, hogy az USB-TTL illesztő IC magas DTR (Data Terminal Ready) jelre földre húzza a fő MCU reset lábát, vagyis reseteli.
> (kivéve Leonardo meg pár speckó darab).
A Leonardo trükkös, csúnyán trükkös. Nem is szeretjük. :-)
Nincs benne USB-TTL átalakító, a fő és egyetlen MCU virtuális USB soros portján kapcsolódik a számítógéphez.
Feltöltés menete Arduino IDE-ből:
1. Nyitott soros kapcsolat bontása.
2. Soros kapcsolat nyitása 1200 baudon.
3. Soros kapcsolat zárása.
4. Az MCU-n (Atmega32u4) futó serial kezelő firmware ennek hatására reseteli saját magát.
5. Az MCU elindul bootloader módban, egy másik! soros portként jelentkezik, és 8 másodpercig vár új program feltöltésére.
6. Az Arduino IDE figyeli, hogy mikor tűnik fel új soros port.
7. Ha van új soros port, akkor azon megpróbálja feltölteni a programot.
Javaslat: 1. rádug, megvárod, amíg felmegy az usb meghajtó. 2. Lehúzod, windows restart. 3. Ugyanarra a kábelre feldugod, ha nem nyavalyog, akkor bármelyik USB porton jó lesz ha nyavalyog, akkor szar vagy a kártya vagy a meghajtó. Amíg egy eszköz nem megy üzembiztosan így, többet ne tégy fel.
A portkiosztás attól függően változhat, hogy melyik USB portra dugod fel, de ez természetes.
Serial port reseteli az alap Arduino kártyákat (kivéve Leonardo meg pár speckó darab).
A bekapcsoláskori villogás a bootloader alapvetően. Ha valami történik a soros porton, függetlenül attól, hogy pontosan mi az, az RX/TX villogni fog. Ha van még mellette port nyitás, akkor a boot is belejátszik pluszban a villogásba.
A Bootloadert ki tudod szedni, de az, hogy azt visszafejtsd elég komoly felkészültség kell úgy szoftveresen, mind tudásban, mind eszközökben. Az Uno és a Nano bootloadere eltér egymástól, ezért az eltérő villogás.
1. A beépített serial terminal induláskor felhúzza a soros kapcsolat DTR (Data Terminal Ready) vonalát, ami reseteli az Arduino-t. Ez nem bug, hanem feature, le is van írva a dokumentációban. Ha ezt nem szeretnéd, akkor használj olyan terminált, amin ez a funkció kikapcsolható. Például CoolTerm.
2. A bekapcsoláskori furcsa viselkedést okozhatja a bootloader (várakozik, közben villog, hogy jelezze a várakozást). Vagy bizonytalankodó táp is. Vagy valami. :-)
Megérkezett a nano meg az uno, és a ch340 driver fölment, látta, átküldtem a klasszikuls blinket, villog, aztán eltűnt a port. Akárhányszor kihúztam-visszadugtam, már nem jelent meg a device managerben. Reboot xp, újra jó, de már nem 9-es com port, hanem 10 és 11, mert közben rádugtam az unot is.
Átírtam a blinket, hogy a serial portra írja ki a millis értékét. Aztán ha elindítom a serial monitort, akkor a millis 0-ról indul. Ha puttyban nyitok sessiont a portra, akkor is. Vajon miért? A nanon folyamatosan villog a tx led, nyilván folyamatosan küldi a karaktereket, azt gondoltam akkor nézek rá amikor akarok, ennek nem kellene beavatkoznia semmibe.
A másik érdekes az uno. Első usb csatlakozáskor valami érdekes morze jeleket villogott a led, aztán beállt az 1 sec világít, 1 sec sötét ritmusra, resetre két rövidet villant, utána a stabil blink. Kis kínai berakott valamit? Ki lehet ezt olvasni valahogy? A nano is villogott, de ott más volt a tempó. Táp ki-bekapcsoláskor újra morzézik, 3-4 rövideket villog 4-szer, majd jön a blink.
A nano is érdekes, mert táp rá, és vagy 3-4 másodpercig egész másképp villog és nem villog a tx led, utána kezdi futtatni a betöltött sketchet, vagy elkezdi a sketchet, de 2 másodperc után jön a más temójú villogás 3-4 másodpercig, és utána folytatja a rendes üzemet.
Az uno Visduino a nano XTWduino.
A gyári program egy dolog, azt úgyis felülírja az első sketch. Ez a nanon meg is történt, és bekapcsolás után nem az történik, hogy elindul a program és kikapcsolásig fut, hanem valami mást is csinál az elején, és ez nem annyira jó. Most csak a led villogást látom, de ki tudja a többi porton mi történik.
Az elsőn mindkét board látható a normál működéssel, balra a nano, 50 ms be, 50 ms ki, és tx led a legfölső. Jobbra az uno, erről nem tudok semmit, nem én töltöttem bele, de a kezdeti furcsa villogás után a működése stabilan ez, kb. 1 s be, 1 s ki.
A középsőn az uno bekapcsolása, először mintha egyből indulna a program, de utána 4.8 s-nál kezdi a furcsa villogást, és 10 s-tól folytatja az 1 Hz-et.
A harmadikon a nano bekapcsolása, furcsa villogással kezdi, tx led (legfölül) sötét, majd 12 s-nál kezdi a normál működést.
Elég egy progmem mátrix túlméretezése és a kártya gyakorlatilag csak dísznek lesz jó. Mert lefordítja és ki is küldi. Aztán a kártya meg azt mondja, hogy kakukk, bocs. És onnan már hiába az AVR-Dude és társai, nincs az az isten, hogy kitakarítsd (mindent végigjártam, ha valaki akar játszani vele, odaadom szívesen).
Remélem, ezek után senki sem veszi úgy, hogy Arduino ellenes vagyok. :-)
Az Arduino kiváló eszköz. Olyan, mint amikor pedálos Moszkvicsról fűnyírómotoros gokartra vált a kiskamasz. Szerel, megy vele 10 percet, lerobban, szerel, megy, örül.
Megtanulja az alapokat, közben élvezi az egészet. Ilyen egy átlag hobbista is, mindegy hány éves, és mi a hobbija.
Szokásos autós példa: Egy átlag autósnak nem kell tudnia, hogy honnan jön, mi okozza a hibakódot. Elég, ha ilyenkor elviszi szervizbe. Ott viszont tudni kell. A gyári fejlesztőrészlegen pedig pláne.
Attól, hogy kapsz egy egyszerűsített, könnyen tanulható rendszert hobbihoz, és gyors fejlesztéshez, még fejlesztő vagy és nem végfelhasználó. Ez fontos különbség.
> az IDE látszik, ebben írom a programot, ezzel ellenőrzöm és töltöm át a boardra, és ha valamit nem enged vagy hibaüzenet jön, akkor nekem mindegy melyik mögötte levő sw egységből eredt.
Pedig nem mindegy. (Ráadásul engedi, és nem jön hibaüzenet sem. Csak nem az történik, amit szeretnél.)
Az Arduino ebből a szempontból nagyon csúnyán elmossa a határokat.
Arduino-nak hívják a fejlesztőeszközt. Ami nem más, mint egy (buta) szövegszerkesztő, és néhány menüpont, amik parancssori programokat hívogatnak felparaméterezve. (avr-gcc, avrdude, stb)
Arduino-nak hívják a szoftverkönyvárak összességét (framework), ami lehetővé teszi, hogy ne alacsony szinten kelljen programoznod. Ezek többé-kevésbé használhatóan vannak megírva, de nem a legjobban, mint ahogy azt feltételezed.
Arduino-nak hívják a board-ot is, amin a szoftver fut, pedig az nem más, mint egy Atmega MCU, egy kevés körítéssel.
Láttam már tapasztalt programozót meglepődni azon, hogy a const char-ok miért is foglalnak RAM-ot.
Ez ennek az architektúrának a sajátja, amit ismerni kell ahhoz, hogy például egy LCD szöveges menü-je ne rakja tele a memóriát. És nem, nem szól neked semmi. A kód lefordul, felmegy a board-ra, és megfagy az egész, anélkül, hogy bármiről is értesülnél.
Ezek ráadásul (majdnem) mind felcserélhetőek valami mással. Másik IDE, másik fordító, másik programozó, másik MCU, stb.
Az Arduino framework-öt szoktam használni, mert valóban gyors prototipizálást tesz lehetővé. De az IDE-t nem, mert nagyon buta, és korlátozó. Nincs kódkiegészítés. Nem lehet követni a változók deklarálását, nem érhetőek el a library-k forrásai egyetlen kattintással, stb.
/* TwoWire.h - TWI/I2C library for Arduino & Wiring Copyright (c) 2006 Nicholas Zambetti. All right reserved.
This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */
#ifndef TwoWire_h #define TwoWire_h
#include <inttypes.h> #include "Stream.h"
#define BUFFER_LENGTH 32
class TwoWire : public Stream { private: static uint8_t rxBuffer[]; static uint8_t rxBufferIndex; static uint8_t rxBufferLength;
Szerintem az átlag felhasználó sem. Ő nem fog Linux-ot letölteni, meg a hardvert parancssori utasításokkal működésre bírni, meg még külön az alkalmazásokat installálni.
Te is azt kérdezgeted hogy mit kell tudjon egy jó riasztó.
Pontosabban mi lehet benne olyan, amihez 10-20 óránál többet kell fordítani az arduino programozására. Ha mátrixokat kellene szorozni vagy Fourier transzformációt számolni akkor érteném, de ilyesmiről szó sincs. Van a hw, az más tészta, vannak a funkciók, amiket le kell programozni. És egyelőre nem láttam olyat, amire sok programozási idő kellene.
Ha lenne egy ilyen doksi, amiben le van írva hogy mi mindent kell tudjon egy jó riasztó, akkor baromi egyszerű lenne jó riasztót csinálni.
Szerintem nem a funkciókat titkolják, hanem a megvalósítást. Tehát az hogy mit tud egy riasztó az nyilvános, hogy azt hogy érték el, milyen sw és hw elemekkel az lehet az üzleti titok. Nem lenne értelmes úgy eladni egy riasztót, hogy a felhasználói kézikönyvben a funkciók negyedét említem, akkor minek dolgoztam a másik háromnegyedével.
Másrészt ha leírnak 200 funkciót, és azt tényleg mind tudnia kell egy jó riasztónak, attól nem lesz baromi egyszerű megcsinálni.
Kevered az IDE, az SDK, a framework és a driver/library fogalmát.
Nem biztos. Nekem mint usernek az IDE látszik, ebben írom a programot, ezzel ellenőrzöm és töltöm át a boardra, és ha valamit nem enged vagy hibaüzenet jön, akkor nekem mindegy melyik mögötte levő sw egységből eredt.
A wire.h-ban van definiálva az i2c láb. Az Arduino.cc-n sok ilyen hivatkozás hibás, erre a fórumokat meg kell nézni.
Javaslom, hogy első körben külön teszteld a két érzékelőt (soros kiolvasással elég), ha így megy, akkor lehet ezt az egyesített megoldást tesztelni. Nincs agyam most visszafejteni, gyors blikkre ennek így (legalábbis i2c viszonylatában) mennie kellene.
persze hogy tervezesi kerdes. es persze hogy van ra jo megoldas. csak van meg ilyen masik 200. meg kell oket talalni, meg kell talalni rajuk a megoldasokat, es utanna johet a programozas meg a forrasztas.
"I2C: A4 (SDA) and A5 (SCL). Support I2C (TWI) communication using the Wire library"
A TWI lábkiosztás gyárilag előírt.
Vigyázz: az utángyártott, egyéb paneleken a számozás nem feltétlen 0-val kezdődik. Ebayos Eth.shiledl sz..ptam egy napot mire rájöttem, hogy 1-től indította a számozást, nem 0-tól.
