- Windows 10
- Videó stream letöltése
- Autodesk - Revit
- Szilícium-karbid chipekkel tompíthatnak az AI energiaéhségén
- ASUS routerek
- DIGI kábel TV
- Programozás topic
- Megpróbálják a spanyolok: megvédenék a gyerekeket a közösségi médiától
- Musk átirányította a Teslának szánt AI-chipeket
- A személyes adatainkkal, képeinkkel tréningezi az AI-t a Meta
-
IT café
Arduino hardverrel és szoftverrel foglakozó téma. Minden mikrovezérlő ami arduinoval programozható, és minden arduino program, board, és hardverrel kapcsolatos kérdések helye.
Új hozzászólás Aktív témák
-
őstag
válasz Flashback #2226 üzenetére
Régóta vagyok PH-s és Arduinos is, hogy nem találtam eddig erre a topicra?
Ha esetleg az számít, az NRF24L01+ ugyan 2.4Ghz-en megy, de annyi klassz beépített tulajdonsággal ruházták fel, hogy nem kell tartani a zajtól.
Szerintem volna olyan biztonságos mint a 433MHz , és kevesebb vele a szenvedés (nekem legalább is a 433-as modulokkal nincs jó tapasztalatom)
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
A második egy nagyon elegáns megoldás. Az egyetlen dolog, amire figyelned kell, hogy a for ciklus ne rohanjon kontrolálatlanul.
Az általad megírt verzióban ugyanis egy pillanat alatt végigfut, ennyi idő alatt nem végignyomni a szükséges gombokat.
Ha prellezésmentesek lesznek a gombok amiket használsz, akkor így menni fog:
#include <SoftwareSerial.h>
int ButtonPins[] = {0, 1};
int buttonState[] = {HIGH, HIGH};
//int index; ha globális a változód, a for ciklus csak egyszer fut, hacsak ki nem nullázod utána kézzel
int numberOfBUTTON = 2;
void setup() {
Serial.begin(9600);
/*for (int i = 0; i < numberOfBUTTON; i++) {
pinMode(ButtonPins, INPUT_PULLUP);
}*/
pinMode(ButtonPins[1], INPUT_PULLUP);
pinMode(ButtonPins[2], INPUT_PULLUP);
}
void loop() {
for (int index = 0; index < numberOfBUTTON; index++)
{
bool buttonPressed = false;
while(!buttonPressed)
{
for (int i=0; i<numberOfBUTTIN;i++)
{
if (!digitalRead(ButtonPins[i]) buttonPressed=true;
}
}
/*az fenti rész megoldja, hogy amíg te nem nyomtál semmilyen gombot, addig ne akarja ellenőrizni a lenyomott gombokat. Másképp akkor is ellenőrizne, ha nem nyomsz épp semmit.*/
buttonState[index] = digitalRead(ButtonPins[index]);
if (buttonState[index] == LOW) {
Serial.print((String)(ButtonPins[index]));
Serial.print(" elem");
while(!digitalRead(ButtonPins[index])){} //megakadályozza, hogy rögtön továbblépjen, mikor még a gombot nyomod
} else {
Serial.println("rossz sorrend");
break; //kiugraszt a for ciklusból, ha már egyszer elrontottad
}
}
delay(2000);
}Így hirtelen ezt tudtam, lehet még benne hiba, de erre indulj el.
Majd tájékoztass[ Szerkesztve ]
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
válasz gyapo11 #2244 üzenetére
Nagyon sok éve dolgozom hardverrel is szoftverrel is (és talán pont azért mert ismerem őket) soha nem bíznék egy gázbovdent egy arduinora meg egy csigás motorra.
A riasztó meg a tájékoztató dolgok hasznosak, de anyagi vagy személyi biztonságot kockáztató módosításokat sokszor még autógyártók sem vállalják be csak úgy.
Ez csak a véleményem, nem akarok senkit befolyásolni.Mások számára a kondi fáradós, nekem farad-os...
-
őstag
-
őstag
válasz seatibiza #2261 üzenetére
Attól függ, milyen modellt szeretnél.
Az UNO verzióból kismillió van, azoknál általában annyi a redukció a kínai verziókban, hogy nem atmel chip csinálja a soros-usb kommunikációt, hanem valami dedikált FT232 vagy CH340
Ezen kívül a nyák kialakítása és az USB csatlakozója is változhat.Nano esetén csak a soros-usb móka különbözik
Igazából átlag felhasználóként nem fogsz különbséget érezni.
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
Valamilyen szinten ma már minden valamiféle computer, így teljesen igazad van. Az ECU szigorúan véve egy vezérlő. Realtime kontroller, ami hardverfelépítésében sem számítógép, szoftverberendezésében sem, és amiért én írtam hogy csak ECU az az ember-gép interfész hiánya. Ahogy az Arduinot vagy egy PLC-t sem hívjuk computernek, úgy az ECU-t sem. Erre gondoltam, bocsánat a kukacoskodásomért.
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
válasz dave0825 #2284 üzenetére
Az eladó tényleg toppon van, nagyon sokat rendeltem már én is tőle, és sosem volt gond. Megnézem neked a témát. Talán még ilyen szenzorom is van valahol.
A poti tekerése a digitális lábra van hatással, azzal tudod trimmelni, hogy mi a küszöbérték, ami felett a digitális láb bekapcsol. Azt pl tesztelheted simán, mert a komparátor kimenete egy LED-el is indikálva van. Ha elég hangos vagy, akkor annak fel kell villanni.
[ Szerkesztve ]
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
-
őstag
válasz Gergosz2 #2309 üzenetére
NRF chiphez kimondottan ajánlott saját 1117-el 3V3-at csinálni, sőt még egy plusz kondit is rá szoktak hackelni, mert az Enhanced ShockBurst használatakor még azt is meg tudja zuhantatni.
A chip maga 3.3V-os de a kommunikációs lábak, 5V toleránsak, erre még érdemes figyelni.
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
Az adó azért nem ír semmit soros porton, mert nem is kell neki. Az alap kódban nincs erre utaló sor.
A vevőd meg azért nem ír semmit, mert nincs adás a rádión. Amikor kihúzod azért ír hülyeségeket, mert akkor nyitott a bemeneted, ami full zajt eredményez. Ezt a rádiótól jövő blablának gondolja, amit megpróbál feldolgozni.
Első lépésben az adót kezdeném debugolni.
void loop(void)
{
sensors.requestTemperatures();
float temperature = sensors.getTempCByIndex(0);
radio.write(&temperature, sizeof(float));
Serial.println(temperature);
delay(1000);
}Így nézd meg soroson, hogy mit ír. Az aláhúzott résszel bővítve az adó loopját kiderül, hogy a szenzorérték beolvasásánál már elhalt, vagy csak a rádió híjja a dolognak.
[ Szerkesztve ]
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
-
őstag
Nekem az a gyanúm, hogy gyenge a tápod.
Hány amperes a táp, és milyen motort használsz?
DrojDtrollBrushless motorvezérlőhöz 48V 3,5A esetén sok tízezres vezérlő elektronika kell, nem elég csak az arduino.
Léptetőnél az elv nagyjából ugyan ez, de a kisebb sebesség miatt elég olcsóbb elektronika is. Ott már bevett szokás szimpla erősítőkön keresztül az Arduinoval kapcsolgatni a motortekercseket.
Sima kefés DC motor esetén a legegyszerűbb és legolcsóbb a dolog. Optocsatoló és néhány fet segítségével akár teljes H-hidat is lehet csinálni egyszerűen.
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
Van egy függvény, aminek a neve millis.
double start = millis();
Ez az a pont, amikortól számolni szeretnéd az időt.
double now = millis() - start;
A now fogja tartalmazni, hány ezredmásodperc telt el a start óta.
A millis() visszatérési értéke egyébként az arduino futása óta eltelt idő ezredmásodpercben. A szám túlcsordul 50 nap futás után.
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
Motor nélkül rendesen nyitott, vagyis meg volt a kellő feszültség.
Ugye tudod, hogy ennek az állításnak nem sok értelme volt?
A tranzisztor nem relé, hogy feszültséget kapcsolj rajta. A tranzisztoron áramot tudsz vezérelni, azt pedig üresjáraton mérve nyilván megkapod a névleges feszültséget, akkor is, ha nem nyitott teljesen. Ha viszont adsz neki egy terhelést, akkor jön a feszültségesés, mert a kapcsolt áram kevés a potenciálkülönbség fenntartásához.
Egyébként az 1K val szerintem is mennie kellett volna.
[ Szerkesztve ]
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
válasz Tankblock #2496 üzenetére
Azon felül, hogy már a Rambó ( ) is elég sokat lehet kezelni, az is csak akkor korlát, ha az arduinon lokálisan akarod tárolni folyamatosan a megjelenítendő LED szín variációt a szalagra. Ha az arduino csak az interfész a LED-ek vezérlésére, vagy nem akarod tárolni a fényfüzér színkombinációját, akkor végtelen sokat tudsz kezelni vele. Ha még nem nézted meg az adatlapot, röviden összefoglalva soros a protokol láncolva, azaz van egy bemenő szín, amit magára vesz, és van egy kimenő, ami az előző színe volt. Ezt továbbítja az utána lévő bemenőjére. Indukcióval (nem a Faraday félével, hanem a Pascaléval) bizonyítható, hogy tetszőleges n-t választva n+1 darabbal is működik, tehát végtelen nagy számú üzemeltethető így.
Pontosabban akkor pedig a vezérlő PC ramja lesz a korlát, de szerintem az egész íbéjen nincs annyi RGB led aminek a kiosztása betelítene egy 8 gigás ramot Ha mégis van, akkor is meg kell várni PaksII-t vele.Mások számára a kondi fáradós, nekem farad-os...
-
őstag
Lehet. Az usb is a soros programozókat használja, szóval soros porton nem biztos hogy sikerrel jársz, ha az usb nem ment. ICSP programozóval kellene próbálkozz. Találsz rá tutorialt a neten, hogyan tudsz pl uno-ból icsp progamozót csinálni.
bacus:[link] én ilyet használok. Ennek ugyan a venti a markolatában van, de szerintem nagyon kényelmes vele dolgozni. Sokkal kényelmesebb, mint a vastag levegős csövet is tekergetni magad után. Kicsit ugyan 10k fölött van, de tényleg nagyon szépen lehet vele dolgozni, és kényelmesen.
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
-
őstag
válasz dave0825 #2562 üzenetére
Ha az Arduinod 5 voltos, akkor bizony minden digitális lába, így a rajta lévő rx-tx lábak is 5 voltot kapcsolnak. Emiatt kell a szintillesztő, nem a táp miatt. Hogy a modulon lévő 3.3V-ra készített RX ne kapjon 5V TX-et bemenetként.
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
Pontos adatok a témával kapcsolatban annak akit érdekel:
Az Arduinoban lévő atmel chipek határértékei:308. oldalA TTL-nél a tól-ig értékek:
Bemenetnél:
Magas: 2V-5V
Alacsony: 0V-0.8VKimenetnél:
Magas: 2.7V-5V
Alacsony: 0V-0.5VA CMOS-nál:
Bemenet:
Magas: 3.5V-5V
Alacsony: 0V-1.5VKimenetnél:
Magas: 4.95V-5V
Alacsony: 0V-0.05VGyakorlati tapasztalat:
Az arduino elvileg 3.5 fölött lát high-t, valójában pl az NRF24L01+ modulok 3V3 feszültségen kommunikálnak, de 5V toleránsak. Így ha kimarad a level shifter, akkor nem romlik meg, és az arduino is hallja a modult, pedig 3v3.Mások számára a kondi fáradós, nekem farad-os...
-
őstag
-
őstag
válasz DrojDtroll #2634 üzenetére
Nekem megvan, dobj egy privátot, amúgy is akartam tőled valamit kérdezni a logout-od alapján
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
-
őstag
Ezt nem kimondottan értem, hogy hogyan történhet meg.
Eleve a FET-et telítési tartományban kellene használnod, nem alulfeszeléssel vezérelni. A PWM lényege pont az, hogy rövid időre bekapcsolva használod.
Az a gyanúm, hogy te jelenleg a PWM-et analóg feszültség előállítására használod, annak meg nincs elég kraftja, hogy meghajtsa a FET-et (nem tudom, nem néztem az adatlapot, de ha kell átfutom)
JozsBiker : Gondolom nodemcu
[ Szerkesztve ]
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
válasz DrojDtroll #4783 üzenetére
Ahogy nézem, nem Arduino IDE a fejlesztőkörnyezet, csupán az eszköz kompatibilis az Arduino form faktorral.
Tehát az eredeti ötletnek, hogy kevés tanulással nagyot ugorj, nem felel meg.
Lehet, hogy lemaradtam, de miért nem jó mondjuk egy Due?
Szerk.:
Megtoldanám annyival, hogy ha nem számolsz sokat, főleg lebegőpontosat nem, akkor érdemesebb a 8 bitesek felé nézelődnöd. Rövidebb címek, rövidebb utasítások, gyorsabb gpio.A 2000 analóg olvasást milyen pontossággal szeretnéd?
[ Szerkesztve ]
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
válasz DrojDtroll #4803 üzenetére
Szerintem nem lesz szükséged kettőre
Ahogy említették egy csatornára ez alig több 50kHz-nél.
Ha a tied simán csak kódot pörget, és az ADC-k beolvasását interruptosan végzed, akkor bőven meg tudod haladni ezt.
Port-manipulációval és átállított timer interrupttal 100kHz-et simán lehet csinálni, úgy, hogy egy egész portot, azaz 8 kimenetet pulzálsz ezzel a frekvenciával.
Timer interrupt nélkül az ADC amire várni kell csak. Egy joysticknál szerintem bőven overkill a 10 bit, így felgyorsíthatod az AD konverziót egész nyugodtan. Ha a prescalert átállítod 16-ra az ATMEL reference szerint felmehetsz 1MHz ADC órajelig, (13 órajel egy konverzió) tehát az AD konvertered 77kHz gyors lesz, és mindez még pontosságvesztés nélkül. Ha kiteszteled a joy használatához elegendő felbontást, egy duplázás még lehet, hogy belefér.
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
Én csak azért nem bíztatom a raspberry-re, mert az nagyon ügyesen számol, meg nagyon jó a multitaszking benne, de ez a gpio sebesség rovására megy.
A legtöbb jól implementálható gpio kezelő módszer kifullad pár tíz kHz-nél.
Persze vannak módszerek, amivel 22MHz-et is elértek, de az már lement a processzor hardver szintű programozásáig, illetve az egyéb MHz körüli módszerek is csak magas optimalizációval tudtak elérni 1 csatornára ekkora sebességet.
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
válasz DrojDtroll #4828 üzenetére
Google első találata, de ez a hiba szerintem a joystickból adódik.
Egy olyan poti, aminek a zaja kisebb 0,8mV-nál több tízezer forint, nem hinném, hogy ilyen van benne
Az ADC felbontásával még azért lehet érdemesebb lemenni, amit korábban is írtam: Gyorsítható a konverzió
Tegyél rá egy súlyozott mozgóátlagot. A lényeg, hogy az utolsó pár értéket vedd, és nézd meg, hogy az új érték mennyire dominál a régiekhez képest. Ezzel egy 512,512,512,513,512 szekvenciát el tudsz simítani, de egy 512,512,512,513,514 szekvencia már megindítja az alapjelet.
Minél több értéket veszel a mozgóátlagba annál stabilabb, de annál lassabb lesz a felfutás.
Minél nagyobb sújt adsz a múltbeli ismétlődő értékeknek, annál kevesebb értékre lesz szükséged a mozgóátlagban.
Meg kell találni a harmóniát
az hogy egy arduino eredeti, vagy nem, nem számít... a szerelés minősége, a design, esetleg a soros-usb átalakító ic különbözik, de a rendszer agya mindig ugyanazon gyártó által készített chip
[ Szerkesztve ]
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
Én az analóg eszközöket úgy szoktam használni, hogy a kezembe veszem a hardvert, elkezdem mozgatni olyan pici lépésekkel, amekkorákat tudok okozni.
Ez megszámolom, tegyünk feltudok végállástól alapállásig 10 pozíciót csinálni.
Ha ezt tudom, megnézem soros monitoron, hogy mettől meddig csinál értékeket az eszköz. Pl. 7-1013
Végeredmény map függvénnyel:
map(analogRead(A0),7,1013,-10,10);
Ez így bőven elég szokott lenni, hogy feldolgozzam a mozdulataim qvantumát, és kiküszöböli a nulla körüli jittert is.
Ha gondolod élj vele, és akkor nem kell szűrőkkel bajlódnon.
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
Szia!
1, Ez nagyon szerteágazó dolog, egy táblázat igen kiterjedt lenne, ha mindent bele szeretnénk foglalni. Ha kezdő vagy, szerintem kezdd az alapoktól, arra bőven elég az Uno-Nano. Ha már észreveszed, hogy kevés, akkor már tudni fogod, hogy mit keress.
(Amiről pl írsz, az nem is inkább az arduino-tól függ, mintinkább a benne lévő soros-usb átalakítótól)2, A legtöbb integrált alkatrész tönkremegy, ha például fordított polaritással kötöd be. Egy LED, IR fototranzisztor, stb lehet hogy kibírja.
A legtöbb elemnek nem lesz jelölve a lába. Ha szeretnél valamit vele kezdeni, keress rá a neten, és mintaprojektben meglátod, mit kell tenned.3, Nem, nem befolyásolja. A már említett soros-usb átalakítók usb2.0 full speed kompatibilisek, de teljesen működőképesek már 1.1 alatt is.
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
válasz Janos250 #4921 üzenetére
Ez pont nem azt magyarázza, hogy rosszul megy.
"a manual azt írja, hogy ha a 16 bit besiftelése után nem visszük fel a chipselectet, akkor kisiftelődik az új bevitellel párhuzamosan a régi. Ha jól értelmezem. Viszont hiába viszem fel a CS-t a 16 bit után, a következő 16 bit besiftelésekor az előzőt akkor is tovább küldi a másodiknak is, tehát a kettő ugyanazt csinálja. Mit értelmezek rosszul?"
Azt értelmezed rosszul, hogy a CS megállítja az IC shiftregiszterét. A CS csupán egy load jel, a lényege, hogy a shift regiszterben lévő logikai tartalmat átkapcsolja a kimenetekre. Az adattartalmat hordozó shiftregiszter viszont nem áll meg.
Ha jól sejtem, te azt szeretted volna, hogy a lánc első (tehát aminek a DataIN-je a mikrokontrollerről megy) tagját feltöltöd adattal, aktiválod a CS-el, majd folytatod a másodikkal. Csak ezzel az lesz a baj, hogy így kishifteled az adatot az elsőről, így miután újra aktiválod a közös CS-t az első elállítódik.
Amit kéne helyette:
A teljes láncot feltöltöd, N*16 bittel, ahol N az elemek száma. Az első 16 bit a legtávolabbi IC adata lesz, az utolsó 16 bit pedig a mikrokontrollerre kötött IC-n fog megjelenni. Amikor kiküldted az N*16 bitet, mehet a közös CS
Ha pedig valamelyiket nem akarod aktiválni, akkor az adott IC 16 bitjében no-op kódnak kell lennie.
A lényeg tehát, hogy közös CS lábbal nem tudod egyenként frissíteni a kimeneteket, csak úgy, ha betolod mint az N db IC-re a 16 bites kódot, a fent leírt sorrendben.
[ Szerkesztve ]
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
-
őstag
A morcogás az gyakori. Mechanikai nemlinearitások miatt nem képes oda beállni, ahova szeretne, de a szabályzójában nincs integrátor, így azzal a pici erősítéssel próbálja megoldani.
Ha pici a táp árama, akkor növeld, ha elég nagy áramot tud a táp, akkor próbálj neki nagyobb feszültséget adni. 5,5V simán jó, de az RC-s alkalmazásokban a jobb beállási idők miatt a 6V-ot is rájukteszik.
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
ICSP programozóval (vagy egy annak felprogramozott arduinoval) le tudod menteni a programmemóriában lévő HEX fájlt.
Bár ebből arduino kód a büdöséletben nem lesz szerintem (én legalábbis nem tudok olyan módszert, ami HEX-et visszafordít), így csak arra jó, hogy legyen egy backupod. Ezt a hex-et később vissza tudod tölteni.
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
válasz Speeedfire #4978 üzenetére
Azért nem feltétlenül kuka, lehet elég a CH340G-t cserélni rajta.
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
Jó tanács a témával kapcsolatban mindenkinek:
Saját tervezésű teljesítményvezérlésnél (pl H-híd, fél H-híd, Power LED vezérlő) mindig kell tenni egy pullup/pulldown ellenállást a processzor vezérlő lábaira az ilyen esetekre.
Resetkor, programozáskor, elrontott programkor a processzorlábak leggyakrabban nagyimpedanciás módban vannak, amik nem húzzák se fel, se le a zajokat, amiket a vezetékek vagy a nyák huzalozása összegyűjt. Ilyenkor vagy elindul a motor, vagy olyan FET-eket kapcsol be, amik rövidre zárják a tápot, vagy ha a külső zaj nem telíti a FET-et, akkor analóg módban kezd üzemelni a FET, aminek következtében valószínűleg elfüstöl.
Hogy melyik eset a jobb, az helyzetfüggő, de mindig a rosszabbik történik meg
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
válasz JozsBiker #5435 üzenetére
Mint már írták lehet venni külön is a lényeg pedig:
Az RF termékek esetén (legyen az BT, Wifi, RC) marginális a nyákterv. Ahhoz, hogy ezeken a magas frekvenciákon zajmentes adás-vétel legyen, olyan dolgokra kell odafigyelni, amik egyébként nem ilyen érzékenyek:
- Elemeket összekötő huzal vastagsága, szélessége, hossza
- Huzalozás egymástól való távolsága
- Passzív elemek egymástól való távolságaEzért, ha valamikor céleszközt terveznek, kevésbé bevett szokás a rádiofrekvenciás procikat lepakolni a nyáktervre. Ehelyett inkább a moduloknak a footprintjét teszik le, és azt úgy forrasztják be (sok példát sorolhatnék, most pont egy ilyennel dolgozom link)
A backplane inkább már a fejlesztőknek készült, hogy anélkül tudják használni a modulokat, hogy mindenféle trükközéssel lábakat kelljen rájuk varázsolni.
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
kevésbé bevett szokás
Pont miattatok írtam így, és nem úgy, hogy egyáltalán nem szokás. Egyébként szerintem nem csak darabszámtól függ, hanem kivitelezéstől, annak igényességétől, kategóriájától is. Sok olyan kütyüm van, amit valószínűleg szintén többszázezres darabszámban dobtak piacra, és mégis így oldották megmarginális
Yup, a kardinális szót akartam használni.Mások számára a kondi fáradós, nekem farad-os...
-
őstag
Szia!
Van egy nagyon hasonló cuccom, szinte ugyan ez a modul, csak az outputnál van hely egy USB aljzatnak a PCB-n.
Az enyémen (és a tieden is 99%) ilyen IC van. Elég nehéz volt felkutatni, mert a rajta lévő feliratnak nem sok köze van a típushoz (ellenben a datasheetben ott a jelentése)
Szóval a válaszok:
Elvileg működhet egy ceruzaelemről, mert kvázi 0-6V a bemenő igénye.
Ahogy nézem, datasheet szerint 2A a benne lévő power mosfet felső határa, de ez a kialakításból adódóan lehet, hogy szándékosan korlátozott. A datasheetben látható, hogy ez is beállítható. Nálam mondjuk 2A-re van belőve az "overcurrent detection" ellenállás.
A kimenet állítása ugyan így be van lőve gyári ellenállásokkal. (Az én 5V-os modulomnál számolva csak 4.2 jön ki ...)
És akkor a valóság:
- 1,5V vadi új elemmel nem működik. A kimeneten 1,5V van
- LiIon cella bemenetre 5,2V a kimenet, és tudja a 2A-t (rövidzárása 5A de ekkor bőven bezuhan az output az input feszültségre) 2A mellett viszont nagyon melegedett, szerintem huzamosabb ideig azt sem bírta volna.Szóval vagy a datasheet nem ehhez való, vagy passz. Elvileg klappol a kiszerelés, a termékkód, és a kapcsolás is olyan, mint a datasheetben, a mérések mégis mást mutatnak... Ha esetleg találsz róla valami konkrétabbat, szólj
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
Valószínűleg elbírja a kisebb terhelést.
Mondom, nálam valami nem volt oké ceruzaelemmel (nálam sem világított a visszajelző sem) de ha nálad meg, érdemes megpróbálni. Egy arduino fogyasztása jóval kisebb mint egy motoré
Szerintem hűtőborda nem kell, ha melegszik akkor már inkább hagyd, de szerintem egy arduinos teher alatt nem fog megszakadni.
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
Az ESP8266 önmagában egy processzor. Amit te linkeltél az egyfajta modul ESP8266-al. Ez egy másik modul [link].
Amikor esp-ről beszélünk ezt értsem ezalatt, vagy van olyan lap ami ezzel a chippel épült, de olyasmi mint a nodemcu csak olcsóbb?
A NodeMCU-ban is ESP8266 van, amikor ESP8266-ról beszélünk, olyankor ESP8266 procit tartalmazó IC-ről/SoC-ról beszélünk. A változatok általában annyiban különböznek, hogy több-kevesebb kiegészítő van a modulon. A NodeMCU-n például soros-USB átalakító, adott esetben analóg multiplexer is van.A szintillesztést nem tudom, ki-hogy oldja meg, személy szerint a linkelt modul Rx Tx pinjeit gond nélkül használom szintillesztés nélkül már jóideje (nem azt jelenti, hogy ez így jó is, de nekem működik). Ha vigyázni szeretnék rá, akkor [link].
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
-
őstag
válasz gilfoyle #6245 üzenetére
Ha esetleg érdekel ezen felül:
A TTL (Tranzisztor-Tranzisztor Logika) önmagában hordozza, hogy digitális "logikai" jelekről van szó. A TTL szabvány szerint egy kimenet 0.5V alatt nulla (vagy hamis) 2.7V-5V tartományban pedig 1 (igaz). A kettő közötti érték egy tiltott zóna, ahol nem helyezkedhet el a jel feszültségértéke.Arduino-n az analóg bemenet használható digitálisként is, ilyen esetben ajánlott is, ugyanis egy analóg olvasás időben sokszorosa egy digitálisnak, információtartalma pedig az adott tartományokon belül nincs a változó értékeknek.
Mivel enkóderről van szó, ahogy írták is, a digitális lábon belül is célszerű megszakítással rendelkező (interrupt) lábat találni neki.
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
válasz gilfoyle #6249 üzenetére
Nem feltétlenül kell Mega hozzá:
Az enkódercsatornák egyikét elég interruptra tenni->x1 kiértékelésnél csak az egyik csatornát nézed interrupttal, és a másik csatorna értéke alapján határozod meg, hogy mi az irány.
soldi3r :
Többször volt fölösleges újrakondiznom monitort az elmúlt időszakban. Újrakondizás után sem működtek nekem. Ha a táp esetleg elvitte magával a megjelenítő logikát, akkor gazdasági totálkár. Azt kellene megnézd, hogy a megfelelő feszültségekkel betápolva legalább a logika elindul e. (kép nincs ugyan, de lehet látni, hogy menne a monitor)
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
válasz BlackPriest #6296 üzenetére
Linkelj kérlek, hogy mit is vettél pontosan.
Széthúzás-összedugás után ha nem megy, (és az első feltöltés ment) akkor az a gyanúm, hogy a bootloader nem hozzá való.
(Az Arduino ugyanis minden kódfeltöltés alkalmával a bootloadert ((aminek köszönhetően lehet soroson programozni)) is újratölti, majd aztán a kódot.)
Ha úgy programoztad, hogy a bootloader nem a boardhoz való, akkor egy még működő kártyából csinálj ArduinoAsISP-t (google segít benne) és pörköld rá a jó bootloadert.
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
válasz BlackPriest #6299 üzenetére
Fogós a keresztkérdésed. Ha a bootloader elakad, akkor szerintem nem jut el a kódfuttatásig.
Köszi a linket, ahogy nézem 168-as proci van rajta.
Arduinoban átállítottad 328-ról 168-ra a processzort a board beállítása után?
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
válasz Teasüti #6340 üzenetére
Ha már heftelsz, (oké tudom, nem autóba lesz a végleges), akkor csináld inkább azt, amit mostanában az autógyártók is beletesznek az autókba gyárilag: Intenzív fékezésnél bekapcsol a vészvillogó.
Kevésbé zavarod vele össze a mögötted jövőt, mert ez a villogó féklámpával ellentétben egy bevett szokás. Villogni ugyanúgy villog, szóval az észrevehetőségre se lehet panasz.Nem mellesleg egy megjegyzés, amit egyáltalán nem rosszból mondok, de gondold át:
Ha esetleg mégis belédfutnak, majd a vétkes arra fogja, hogy azért ment beléd, mert a féklámpád össze vissza discozott, és esetleg megtalálják a heftet az összetört kocsi hátuljában, akkor ne csodálkozz, ha a végén még meg is büntetnek.
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
Sziasztok!
Eljött lassan az ideje, hogy ebben a topicban is rontsam a levegőt.
Nagy mikrokontroller (azon belül pedig leginkább Arduino kompatibilis) fan vagyok, de eddig valahogy sosem volt olyan nyíkom, amivel kimondottan ide jönnék.
Ahogy nézem, pont ATTiny van porondon, szóval íme a kérdésem:
Terveztem a fórumról egy kollégának a gépházába a gyári RGB stick (szalag szélességű, de 1.6-os PCB) helyett egy ATTiny85-ös alapú retrofitet.
Az első hibát ott követtem el, hogy a Digispark pinelnevezései után mentem, amikor a PCB-t terveztem, és nem a beültetendő IC lábszámozás szerint. (Guess what? Persze, hogy nem ugyanaz.) De ez még nem lenne showstopper. Amúgy sem volt nagy kedvem még PC oldalra is host szoftvert csinálni ami kommunikálna az attiny féle virtuálisUSB-vel.Mivel a gépházon van dedikált RGB gomb eredetileg, gondoltam csinálok egy egygombos menürendszert, ami rövid - hosszú - dupla gombnyomásokkal navigálható a különböző effektek között.
Na és itt kezdődik a baj.Az összes színt felvettem statikus változóként, és megírtam (természetesen ciklusokkal és nem diszkrét állapotokkal) az összes effektet, és így a végén a következőbe futottam:
digispark_ARGB_controller.ino.elf section `.text' will not fit in region `text'
/avr/bin/ld.exe: region `text' overflowed by 3394 bytesNem nagyon értettem ezt a hibát, kikommenteltem random részeket, és akkor volt hogy ez jött:
A vázlat 6598 bájt (109%)-ot használ a program tárhelyből. A maximum 6012 bájt.
A [link] és az üzenet segít: Túl nagy a kódom.
text section exceeds available space in board
A globális változók 182 bájtot használnak a dinamikus memóriából.
Sketch too big; see https://support.arduino.cc/hc/en-us/articles/360013825179 for tips on reducing it.A durva az, hogyha kiveszem csak(!) az effekteket, a kódból, akkor egyből megáll ilyen 70%-ban.
Az effektekben használt függvényeim:
max()
abs()
random()illetve van, amiben használom a % operandust.
Létezik, hogy egy pár eljárásban lévő ciklusban több programmemóriát foglalok, mint a teljes addigi könyvtárarzenál? (A globális változóim bőven határon belül vannak, mint látható).
Futott már bárki ilyesmibe?
Mások számára a kondi fáradós, nekem farad-os...
-
őstag
válasz Tankblock #16217 üzenetére
Szia!
Elég masszív a kód, és még próbálom optimálni, mielőtt bárkit megkínoznék azzal, hogy belenézzen.
De, próbálok egy rövid példát mindjárt feltenni, megszépítem és érthetővé teszek a kód azon részét (ha csak egy egyszerűbb effektet hozzáteszek, már az is relatíve zabálja a programhelyet)Arduinós könyvtárak: csak az EEPROM és a NeoPixel könyvtárak vannak használatban, de a programtárhely vészes fogyása valahogy független ezektől.
Serial debug: Attiny lévén nem használomMások számára a kondi fáradós, nekem farad-os...
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen