Fórum témák
» Több friss téma |
A klónok CH340 Soros-USB illesztőjének drivere (Letöltés)
Köszi!
Ki próbáltam! A kimeneteket tudom vezérelni. Úgy veszem észre a 6, 7 vissza van kötve a bemenetre?
Igen!
A kimenet kapcsoló szinte azonnal reagál, a bemeneten a visszajelzésre 2-3 másodpercet várni kel.
A kapcsoló állásokat valójában csak akkor küldi el ha több mint 1s-ig nem kapcsolsz semmit, és a frissítés is hasonló sürüségű - lehetne gyorsítani, de ez azért ilyen, hogy több klienst is ki tudjon szolgálni. Így ha más átkapcsol egy kapcsolót, akkor az nálad is átkapcsolódik.
Tesztelési célból van rajta egy kép is:tiger.jpg A hozzászólás módosítva: Jún 21, 2015
Szia! Én eddig egyszer próbáltam képet kirakni arduinó web szerveren, de az volt a baj, hogy nagyon sokára töltött be a kép. Van erre valami megoldás? Mondjuk nem tudom a tied mennyi idő alatt tölt be. A másik kérdésem, pedig, hogy azt mondják, hogy a nagyobb feladatokhoz inkább raspberry-t használjak, még nem próbáltam ki, majd most akarok egyet venni, de ott ha rendes oprendszert teszek rá, akkor nem tudom a saját programot üzemeltetni, ugye? Illetve azt mennyire nehéz programozni.
153k a kép és olyan 3,3sec alatt jön le. De ez az arduino csak 8MHz körül jár ha jól tudom. Tervezem, hogy veszek arduino due-t, azon 32bites ARM provci van 84MHz-es órajellel. Gondolom azzal jóval gyorsabb lenne.
Ebbe a projectbe én is beszállnák! Ha lehetséges?
„Tervezem, hogy veszek arduino due-t, azon 32bites ARM provci van 84MHz-es órajellel.”
A Tiger csak elsőre vonakodik, másodikra már villám gyorsan ki ugrik!
Ezt én is tudtam.
Viszont ez 1. 1680*1060-as kép, a kis AVR hoz képest nem rossz teljesítmény!
Mindenkinek elküldtem a jelszót aki kérte! A programom csak 8db sütit tárol (kevés a RAM), igy előfordulhat, hogy kidob valakit (újra kéri a jelszót), ha sokan jelentkezünk be rá.
A hozzászólás módosítva: Jún 21, 2015
Viszont mivel a port forwardolással kapcsolatban nem igazán jöttek ötletek, jöjjön egy másik hiba amibe beleütköztem, hátha erre lesz ötlet. Az alábbi kódrészlettel küldöm a pl. képfájlokat az arduinoról:
A MAXBUFF értékét (MEGA2560 esetén) 64byte és 2k között változtatva tapasztalható némi sebességkülönbség (a mostani duemilanove esetén ez 256 mert nincs több memo erre a célra). Viszont ha a MAXBUFF 2049 vagy nagyobb, akkor a fájl hibásan érkezik meg a böngészőbe! Vagy a file.read(), vagy a client.write() függvény, vagy a hardver hibázik.... de melyik? És javítható? Ha pufferelés nélkül küldöm az adatokat akkor sokkal lassúbb a szerver, és akkor is ha én töltöm fel ciklussal a puffert, gopndolom mert a "gyári" függvény ASM-ben készülhetett. Erre van ötlet? Vagy hibás lehet a kód, elrontottam valamit?
A raspberry-nek kevés a port láb kivezetése, ezért nem igazán jó vezérlési feladatokra.
Erre inkább alkalmasak a 100 lábú ARM-ok. Szerintem a MAXBUFF 2049 ??? legyen páros számú. MAXBUFF 2048 A hozzászólás módosítva: Jún 21, 2015
Bármilyen, 2048-nál nagyobb érték esetén hibázik, mindegy, hogy páros-e vagy kerek szám-e.
Megnéztem a due-t, és azt írja, hogy azon nincs 5v csak 3,3, akkor szerinted a lan shield fog rajta működni vagy nem?
Köszönöm szépen, eddig ezt észre sem vettem. Gyártási hiba lehet mert a C4-es kondi másik fele tiszta, tehát a soron rakta le így a gép. Megpróbálom helyre tenni.
Remélem, hogy fog menni, úgy tudom az is 3.3V-os, de később wifisre szeretném alakítani.
Különben nem is kel nagyobb puffer, úgy is körbe címzed.
Viszont ezt nem így szokták megoldani. Az SD SPI kezelést megszakításban kel megoldani. Elindítod az olvasást, ott hagyod, majd kér megszakítást, ha megjött a byte, és elteszed a pufferba, kéred a következőt. ( A SPI mindig gyorsabb, mint az USART) Külön indexeled az olvasást, és az írást. Közben mikor az olvasás index előrébb jár, mint az írás elküldöd a kővetkező bytet a soros vonalra. Mindkét HW egység függetlenül dolgozhat egyszerre, ugyanazon a pufferen. Csak vigyázni kel, hogy ne keresztezzék egymást. Röviden bizd a HardWere, gyorsabb mint a Softveres móka!  És legyen előjel nélküli: unsigned long s; A hozzászólás módosítva: Jún 21, 2015
Kedvet kaptam, lehet én is veszek egy due-t, de azt nézem, hogy nekem az 1.0.6 van fent progiból, mert az új nem volt szimpi és visszaraktam a régit, de ebben meg nincs due. Az újban viszont már van, akkor amíg nem volt az 1.6.4 addig mivel lehetett programozni?
Nem vagyok teljesen képben. Az arduino esetében az adatátvitel a kártyáról és a programom között még ott van egy filerendszer kezelés - amit nem biztos, hogy én akarok megírni. Viszont az SD kezelésére nem igazán láttam megszakítással működő függvényt. Hasonlóképpen az ethernet modul kezelésére sem. Ez megírni jól, elég nagy feladat lenne. Nekem jelenleg talán túl nagy. Az arduino duemilanove 30k flashba lehet, hogy el sem férne.
Mivel az SD és az Ethernet osztozik az SPI buszon, egyszerre úgyis csak az egyik tudja használni, ebben az esetben mennyit lehetne nyerni a megszakításos kezeléssel? Te készítettél már ilyen megoldást? Mennyivel lett gyorsabb? Az unsigned long s; -el mindjárt kipróbálom.
Ahhoz elvileg le lehet tölteni a Tools/Board Manager... menüpontból.
Mi nem tetszett az újabb verzióban?
Az nem tetszett, hogy a színek nagyon fakók, és összefolyik a program, nem látom át rendesen.
Hoppá tévedtem!
Azt hittem az Ethernet soros porton kommunikál!  Ezért nem lehet programozni az adott HW birtoklása nélkül! Hiába vannak ötletek, ha nem tudja az ember letesztelni élőben! A hozzászólás módosítva: Jún 22, 2015
Pufferelés: az unsigned long változó sem oldja meg a problémát sajnos.
A tesztelés alapján úgy tünik, hogy a client.write(buff, buffsize) függvény (amivel az adatokat küldi a program kliens felé) 2048-nál nagyobb pufferrel nem működik jól. Konkrét okot nem találtam, csak utalást 2048 bájtos TCP csomagméretre - tehát lehet, hogy ekkora az ethernet chip saját buffere? Ha saját ciklussal kezelem a puffert, (magyarul bájtonként küldöm el az adatokat belőle) akkor nagyobb értékkel sem hibázik, cserébe sokkal lassúbb lesz.
A „Due R3 Board SAM3X8E 32-bit ARM” még annyira újdonság.
Kíváncsi vagyok milyen sikere lesz? Nekem tetszenek a 32-bit ARM-ok. Jóval gyorsabbak és fejlettebbek, mint a 8-bit AVR-ek. Csak sokan félnek tőle, mert bonyolultabb programozni!
Sziasztok!
Olyan eszközt szeretnék készíteni, amiben PWM-el van szabályozva a fűtés és minél "messzebb" van a valós hőmérséklet a beállítottól, annál nagyobb a PWM kitöltése. A hőmérés és letárolás, valamint a beállítás része meg van a programnak, csak a PWM-es részénél akadtam el. Szóval ha valakinek lenne kézzel fogható ötlete, esetleg mintakódja, akkor annak nagyon örülnék. Hálás köszönetem.
Ha jól értem, mit szeretnél, akkor valami ilyesmi kéne:
|
Bejelentkezés
Hirdetés |
