Van ez a jópofa karakteres időjárásjelző oldal, ez a Worldweatheronline adatait használja.
Az előrejelzés pontosságát tesztelni kell

Путин, иди нахуй!

Olvastam én, csak eddig nem volt időm rá, de most összeütöttem.

RMT-vel hogy csinálnál mondjuk 100 Hz 50% PWM jelet?

Így:
Bár most látom, hogy Te 100 Hz-et kérdeztél, én meg 10 kHz-re emlékeztem. Sebaj, átírhatja, akit érdekel.

Ha nem kell carrier, akkor ki kell kommentelni

// 10 kHz RMT


const uint8_t GPIOnum = 15;
const uint8_t RMTchNum = 0;
const uint8_t DutyCycle = 50 ; // %
const uint32_t freq = 10000 ;

const uint32_t clockAPBbus = 80000000 ; // RMT use APB bus clock
const uint16_t highCiklNum = (uint16_t) ( clockAPBbus / freq / 100 * DutyCycle ) ;
const uint16_t lowCiklNum = (uint16_t) ( clockAPBbus / freq / 100 * (100 - DutyCycle) ) ;

const uint32_t RMTdata = ( ( (lowCiklNum) <<16) + (1<<15) + highCiklNum) ;


void setup() {
Serial.begin(115200);
delay(1000);
Serial.println("start setup");

pinMode(GPIOnum, OUTPUT);

*((volatile uint32_t *) (0x3FF44530 + GPIOnum * 4 )) = 0x57 + RMTchNum ;
*((volatile uint32_t *) (0x3FF000C0)) |= 1 << 9 ;
*((volatile uint32_t *) (0x3FF000C4)) &= (~(1 << 9)) ;
*((volatile uint32_t *) (0x3FF560F0)) |= 1 ;
*((volatile uint32_t *) (0x3FF560F0)) |= 2 ;
*((volatile uint32_t *) (0x3FF56020 + RMTchNum*8)) = 1 ;
*((volatile uint32_t *) (0x3FF56020 + RMTchNum*8)) |= (1 << 24) ;

*((volatile uint32_t *) (0x3FF560B0 + RMTchNum*8)) = ( (0x80 << 16) + 0x80) ; // carrier freq
*((volatile uint32_t *) (0x3FF56020 + RMTchNum*8)) |= (1 << 28) ; // carrier enable

*((volatile uint32_t *) (0x3FF56024 + RMTchNum*8)) = (1 << 17) ;
*((volatile uint32_t *) (0x3FF56024 + RMTchNum*8)) |= (1 << 3) ;

for (uint16_t i = 0 ; i<(64) ; i++ ){
*((volatile uint32_t *) (0x3FF56800 + RMTchNum *64 * 4 + i*4)) = RMTdata ;
};

*((volatile uint32_t *) (0x3FF56024 + RMTchNum*8)) |= 1 ;


Serial.println("end setup");
delay(500) ;

} // end setup


void loop() {


delay(1000) ;

} ; // end loop

/*

Comments:

*((volatile uint32_t *) (0x3FF44530 + GPIOnum * 4 )) = 0x57 + RMTchNum ; // GPIOnum output = RMT CH RMTchNum
// p 58 (Tech. Ref, 4.12 Register Summary)
// 0x3FF44530 = Peripheral output selection for GPIO_0 (GPIO_FUNC0_OUT_SEL_CFG_REG)
// (0x3FF44530 + GPIOnum * 4 ) = Peripheral output selection for GPIOnum
// 87 (0x57) = rmt_sig_out0 (p. 53 , 4.9 Peripheral Signal List)
// GPIO_FUNC2_OUT_SEL_CFG_REG


*((volatile uint32_t *) (0x3FF000C0)) |= 1 << 9 ; // BIT9, Remote Controller (p. 93)
// DPORT registers/DPORT_PERIP_CLK_EN_REG =1 : enables the peripheral clock (p 92.)
// PERIP_CLK_EN_REG (p. 95 , 5.4 DPort Register Summary)
// BIT9, Remote Controller
// DPORT_RMT_CLK_EN = bit 9 = 0x200

*((volatile uint32_t *) (0x3FF000C4)) &= (~(1 << 9)) ; // PERIP_RST_EN_REG reset for peripherals (p 95)
// BIT9 = DPORT_RMT_RST (RMT reset)
// DPORT registers/PERIP_RST_EN_REG = reset for peripherals
// DPORT_PERIP_RST_EN_REG = (DR_REG_DPORT_BASE + 0x0C4) = 0x3FF000C4

*((volatile uint32_t *) (0x3FF560F0)) |= 1 ; // bit 0 RMT_APB_CONF_REG 1 = Set this bit to disable apb fifo access
// RMT_APB_CONF_REG / bit 0 RMT_MEM_ACCESS_EN Set this bit to disable apb fifo access
// This bit must be 1 in order to access the RMT memory (p. 402.)

*((volatile uint32_t *) (0x3FF560F0)) |= 2 ;
// RMT_APB_CONF_REG / bit 1 RMT_MEM_TX_WRAP_EN This bit enables wraparound mode: when the transmitter of a channel
// has reached the end of its memory block, it will resume sending at the start of its memory region

// RMT_CHxCONF0_REG 15. Remote Control Peripheral/ 15.3 Register Summary (p 396, 397.):
*((volatile uint32_t *) (0x3FF56020 + RMTchNum*8)) = 1 ; // frequency divider's factor , bit7-0 (p. 396)
// freq = 80 Mhz / 1
*((volatile uint32_t *) (0x3FF56020 + RMTchNum*8)) |= (1 << 24) ; // memory blocks allocated to channel , bit27-24

*((volatile uint32_t *) (0x3FF560B0 + RMTchNum*8)) = ( (0x80 << 16) + 0x80) ; // carrier freq
*((volatile uint32_t *) (0x3FF56020 + RMTchNum*8)) |= (1 << 28) ; // carrier enable


*((volatile uint32_t *) (0x3FF56024 + RMTchNum*8)) = (1 << 17) ; // CLK = 80 Mhz
// bit 17: RMT_CHxCONF1_REG / RMT_REF_ALWAYS_ON_CHn
*((volatile uint32_t *) (0x3FF56024 + RMTchNum*8)) |= (1 << 3) ;
// bit 3 : RMT_CHxCONF1_REG / RMT_MEM_RD_RST_CHn Set this bit to reset the read-RAM address
// for channel n by accessing the transmitter


for (uint16_t i = 0 ; i<(64) ; i++ ){
*((volatile uint32_t *) (0x3FF56800 + RMTchNum *64 * 4 + i*4)) = RMTdata ;
};

*((volatile uint32_t *) (0x3FF56024 + RMTchNum*8)) |= 1 ;
// bit 0 : RMT_CHxCONF1_REG / RMT_TX_START_CHn . Set this bit to start sending data on channel n

*/

[ Szerkesztve ]

Az amerikaiak $ milliókért fejlesztettek golyóstollat űrbéli használatra. Az oroszok ceruzát használnak. Én meg arduinot.

Kedves Mindenki!

Nemrég vettem egy PZEM004T modult, 230V-on lehet vele feszültséget, áramot, teljesítményt fogyasztást mérni.
Már napok óta szívtam vele, mert a modulhoz a neten egyetlen kódot találtam, ami az istennek se akart működni. Végül az oldotta meg a problémát, hogy a kódban jelzett IDE verziót, az 1.6.6-ot töltöttem le, és azzal szépen működik.
Az arduino.cc-n levő legújabb IDE-vel, az 1.8.8-al, és egy régebbivel, az 1.0.?? verzióval sem megy.

Lehetséges, hogy valóban a verziók közötti különbség miatt nem akarja lefordítani, vagy én vagyok a béna, és valamit nem jól csinálok??

Azért még nem tökéletes a dolog, mert a fogyasztás adatot megjegyzi a kütyü, amit elvileg a rajta levő gombbal lehetne törölni, nullázni, de nem felejti el, akár mennyit nyomkodom.
Arra, hogy szoftveresen milyen parancsal lehet resetelni, még nem jöttem rá, pedig biztos vagyok benne, hogy van rá lehetőség.

Ha valaki használt már ilyet és megosztaná a tapasztalatait róla, azt szívesen venném.

Sziasztok!

Van ötletek arra, hogy mi az az alkatrész, ami "felrobbant" a PIC felett?

Köszi előre is mindenki segítségét!

Olyan nincs, hogy valami nem sörnyitó ....

Szia!
Az egy ULN2003 vonalmeghajtó IC.
Üdv.

Köszi!

Olyan nincs, hogy valami nem sörnyitó ....

Ez az alkatrész jó lehet a felrobbant helyére?

Magának a PIC-nek vajon lehet baja? Az áramkor 230V-ot kapott egy 24VDC-s tekercsű relé kapcsaira.
Ezek után a készülék elindul, de nem működik rendesen. A PIC által meghajtott kezelő panelen látszódnak a dolgok, de a nyomógombokra nem reagál normálisan.
Tudom, hogy ez elég ködös és nem túl "szakmai" így, de hátha valakinek így is van tippje.

[ Szerkesztve ]

Olyan nincs, hogy valami nem sörnyitó ....

Az ugyan az az IC, mint ami a képen is van.

Vagy-vagy

Úgy látom elkövették az áramkör tervezésénél ugyan azt a hibát, amit anno kezdő fejlesztőként én is...

[ Szerkesztve ]

Úgy látom elkövették az áramkör tervezésénél ugyan azt a hibát, amit anno kezdő fejlesztőként én is...

Ami mi is pontosan? Csak hogy tanuljunk belőle.

I did nothing, the pavement was his enemy!

A driver direkt kapcsolatban van a pic lábaival. Így ha olyan károsodást szenved el a driver túloldala, amit a belső védelme nem tud kezelni a pik fejét is szétveri. Ezt már nagyon jól kitapasztaltam rengeteg erre irányuló védelmet teszteltem.

Jo az ugy! Nem kell minden aramkornek javithatonak maradni, ha valami elhiccen... Mondjuk, ha jol meg van csinalva, nem lehet baja a meghajtonak sem.
Vagy nem tudom...

"Mindig a rossz győz, és a jó elnyeri méltó büntetését." Voga János

Nálam nem a tervezett elavulás dominá, de más kategóriára fejlesztek. Nem lakossági felhasználás a fő cél.
Amúgy elbtudom kézelni, higy ez direkt van így. Hisz ha a picet agyonvete ez a művelet, akkor a forráskód hiányávan javíthatatlan a termék.

A jól megcsinálást egyes esetekben felülírja a felhasználó😁

[ Szerkesztve ]

Mi a f...
Hát ez elég komplikált.
PWM-mel ez ennyi:
#define PWM_CHANNEL_1 1
#define PWM_TIMER_12_BIT 12
uint_16t speed_freq = 100;

void setup() {
ledcSetup(PWM_CHANNEL_1, speed_freq, PWM_TIMER_12_BIT);
ledcAttachPin(PinNumber, PWM_CHANNEL_1);
}

void loop() {
ledcWriteTone(PWM_CHANNEL_1, speed_freq); //Min 5Hz 12 biten. Ledc driverben a Tone függvény alapból 10 biten dolgozik.
delay(100);
}

[ Szerkesztve ]

Kérdeznék viszont könyvtár írással kapcsolatban, akinek ez ujjgyakorlat!
Osztályt próbálok írni, aminek rá kéne kapcsolódnia a Serial Stream-re, viszont sehogy se jövök rá hogy kell átadni a könyvtárnak a Stream-et. Kérhetnék ebben némi segítséget?

Jelenleg itt tartok és nagyon nem jövök rá hogyan kellene működnie:
[kép]
[kép]

Köszönöm!

[ Szerkesztve ]

Valamint tőled kérdezném még, mint ESP32 gurutól, hogy találkoztál-e már olyan hibával, hogy pánikol a CPU 1 a sok task miatt, viszont olyan 5-6 reset után végül csak képes elindulni a oprendszer?
Jelenleg 6-7 taskom van, amit szétszórtam a két mag közt (0. magon a gyors függvények, 1. magon a hosszabb programok), prioritásnak alacsony 10 alattiakat adtam meg és mindegyik task-nak eltérőt.
Ha csökkentem a taskok számát, akkor nem pánikol a proci. Van erre vmi ötleted mi lehet?
Minden task-ot szabályosan írtam meg: végtelen ciklusban futnak valamennyi delay()-jel a végükön.

[ Szerkesztve ]

Nem aktuális.

Köszi!

Olyan nincs, hogy valami nem sörnyitó ....

Ha még működik a mikrovezérlő, csak a kimenetei közül pusztult el néhány, akkor a benne lévő programot még le lehet tölteni és visszatenni egy másik új vezérlőbe, ugye?
Ha igen, akkor mi kell hozzá? Illetve van esetleg Győr környékén olyan szaki, aki el tudja végezni a műveletet?
/Nekem sajna nincs tapasztalatom PIC-el. Annó AVR-el foglalkoztam kicsit, ahhoz talán még valahol van programozó cuccom is, de a PIC-et nem ismerem./

Olyan nincs, hogy valami nem sörnyitó ....

Hello

A második képeden a bementi változó referencia ként van átadva.
Ha tárolni szeretnéd, akkor egy rámutató pointerrel lehet megtenni, ha jól emlékszem. Mivel C++ ezért a PRivate részbe tenném bele és itt csak anyit tennék, hogy

class SillyClassNameRules {
protected :
Stream * s;
int x;
int y;
public:
SillyClassNameRules(Stream &p, int X, int Y) : s(p), x(X), y(Y)
{
// If I not made a huge mistake
//do init here pl.call any additional fnc()

}
}

[ Szerkesztve ]

Release the Beast....

Hello,

ha elindul akkor később nem hal bele?
Van-e benne szálkezelés, erőforrásra mutex vagy bármi más ami konkurrens erőforrásokat használ?
Az simán okozhat ilyen tüneteket.
Kódot oszd meg pl githubon akkor kicsit egyszerűbb.

Release the Beast....

Nem találok megosztás gombot Github-on, így remélem a repo oldalának címe elég lesz.
Mondjuk lefuttatni nem fogod tudni szerintem a függőségei nélkül.
De ha belekukkantasz és látsz vmi gyanúsat, azt megköszönöm!

Azt nem mondtam, hogy egyszerű, mert nem erre találták ki, hanem eredetileg az infra távirányítók jelének adására/vételére. Egyébként, ha valaki megcsinálja hozzá a könyvtárakat (mint pl. példádban a ledcSetup, stb.), akkor ebben is pár sor. Persze nem valószínű, hogy valaki megcsinálja, mert valószínűleg nem így akar PWM-et gyártani. Egyébként, ha valaki használja azokat a struktúrákat, amiket korábban Te is használtál a led szalag meghajtására (illetve használja az általad használt könyvtár), akkor némileg szintén egyszerűbb, de akkor meg nem tudja az emberfia, hogy mit csinál. Én szeretem tudni, hogy mit csinálok, ezért szeretem a Tech. Ref-eket.
Pár éve, mikor valahova PWM kellett, akkor azt STM32-vel csináltam, azok is jó procik. Ott is Tech. Ref. alapján.

Az amerikaiak $ milliókért fejlesztettek golyóstollat űrbéli használatra. Az oroszok ceruzát használnak. Én meg arduinot.

Na, azért én sem vagyok ám nagy ESP szakértő attól, hogy a T.R.-et használom! A 10 alatti prioritás biztos, hogy elég kicsi? Én megpróbálnám 3-mal. De ez csak egy tipp, lehet marhaság is.

Az amerikaiak $ milliókért fejlesztettek golyóstollat űrbéli használatra. Az oroszok ceruzát használnak. Én meg arduinot.

Hogy kell privát repohoz linket gyártani? Csak olvasóként ismerem az oldalt.

Hagyjuk, így egyszerűbb!

Prioritások:
Vhol azt olvastam, hogy 18 fölött vannak az RTOS taskok. Bár nem vagyok meggyőződve róla.
Amúgy kell némi mozgástér. 6-7 task még csak egy kis része a to-do listámnak.

[ Szerkesztve ]

Sziasztok, ESP32-höz szeretnék oled kijelzőt rendelni. Ez működne? [link]

Szia, igen.

Hello,

Miért az összes file végződése .ino?

Azt nem értem, hogy miért van a fps_cap paramétered a Setup függvényben kiszámolva, de a task már rég fut mire odaérne a számolásban???
A taskok közötti változók kezelésére volatile kellene ha nem lehet máshogy muszáj. Ha meg csak 1x kell
futnia inkább tedd a Task elejére mielőtt a végtelen ciklus futna.....

ez inkább C kód mint C++...

Amit tanácsolok, dekomponáld a projectet kisebb részegységekre majd egyesével integráld vissza.
NE használj változókat különböző taskokban főleg ha az csak egy konstans --> arra van a #define

Minimalizáld a változóidat és funkcionlításokat rendezzd classokba...
Task elején class init majd végtelen ciklusba számolja amit kell. Taskok közötti communikációra FreeRTOS is van ajánlása xQueue vagy xEventGroup ha szignálozni kellene,

A debug üzeneteket is mentsd le, mert sokat segítenek abban, hogy merre kellene nézelődni. Pluszban most egy MQTT C++ dolgozom és memory leak után nyomozok.

Itt pl a ESP_LOGI(TAG, "[APP] Free memory: %d bytes", esp_get_free_heap_size()); használom a szabad memória fellelhetőségének.

Release the Beast....

Multi tab program, azért .ino az összes. HondaCBR az első a sorban.

Tehát már meghíváskor futnak a taskok mielőtt a végére érne a setup()-nak. Ez új.
Akkor csak átrendezem a setup()-ot.

Vannak globális változók, mert végső soron sokminden interaktív lesz. Ha olyan könnyű lenne könyvtárba rendezni mindent, már rég portoltam volna.

A komponenseket természetesen egyesével tesztelem ki, azt is tudom hol jött be a cpu pánik.
Az utolsó három tasknál. Önmagában minden jól fut. Csak együtt nem annyira.

Az xQueue és xEvent még új, majd utána nézek. Köszi!

[ Szerkesztve ]

Hello

Az összes változó amit több mint 1 task használ közösen legyen volatile....

Ha lenne időm (már nem lenne) akkor megnézem még a hétvégén.

Melyik az a 3 task ami okozza a problémát? Amelyikek a 0 core ra mennek?
Van- benne olyan változó amit az1 es is használ?

Release the Beast....

Sziasztok!

ESP32 SPIFFS-el foglalkozott valaki? Csak olvasgatás szinten néztem rá és felmerült kérdésként a működése. Ez ha minden igaz a 4MB flash-ből foglal le egy bizonyos méretet fájl tárolására, így kevesebb hely marad a fő program számára ha jól értem. Tovább menve az elv is kérdés számomra:

Since if SPIFFS was never formatted it will fail mounting and we need to format it, then we will pass this flag as true. In my case, I already had my file system formatted, so this flag has no effect.

Eszerint hasonló mint egy winchester partícionálás? Ha egyszer lefoglaltam az SPIFFS-nek egy bizonyos méretet (leformáztam), akkor később hiába töltök rá egy egyszer LED Blink programot, nem fogja az egészet letörölni, programot rátölteni és a fentmaradó részt üresen hagyni? Tehát ha többé nem kell a fájlrendszer akkor le kell valahogy törölni az SPIFFS partíciót?

Üdv!
Eredeti Arduino Ethernet Shieldet látott valaki mostanában valahol, magyar beszerezhetőséggel? Kellene egy sürgősen, mihamarabb, de sehol nem találok...

"Go to work, get married, have some kids, pay your taxes, pay your bills, watch your tv, follow fashion, act normal, obey the law, and repeat after me: I AM FREE"

Köszönöm a figyelmet!
Most nincs előttem a kód, de az utolsó három tasknál jött elő a jelenség. Nem használnak sok változót, a két PCNT-t használó csak beállít egyet-egyet, a harmadik meg kiküldi PWM-re a beállított változót. (Tudom ez mehetne egy taskba is, de a multitask lényege nem pont az, hogy kismillió folyamatot indíthatok?) Mindegy melyiket veszem ki, külön-külön mindegyiktől pánikol az 1. mag. És a 0. magon futnak.
Úgy tűnik magától a taskok számától jön be a jelenség.

Nem értek annyira hozzá, de a taskok nálam is furán működtek. Már korábban lehet írtam, de most hogy szóba került leírom megint hát ha van összefüggés vagy ötlet.

Task nélkül tökéletesen fut a program: ESPNow, I2C, Wifi(Webserver + NTP), SPI. Ezeket használom. Taskokkal megoldva már kevésbé. I2C-n olvasva nem mindig kérte jól le az adatokat az ESP. Próbáltam prioritásokat állítani, próbáltam 0 és 1 mag között ide-oda pakolászni a taskokat. Néha jól olvasta az I2C adatokat, néha nem, néha meg többször egymás után rossz adatok jöttek. Néha reset segített, néha az se. Emellett volt még a wifi-nél NTP-vel is gond, bár ott nem emlékszek, hogy kimondottan a task okozta-e, de azóta hogy nem task-al oldom meg nincs egyikkel se baj.

Tehát ahogy kezdtem nem értek hozzá, tapasztalatot írtam le, de gyanúm az lenne, hogy az ESP nem teljes értékű 2 magos eszköz mint egy számítógép processzor. 0. magon mennek a perifériák, 1. magon meg nem véletlen van a loop is. Tehát lehet próbálkozni taskokkal, de valójában 1 magos az eszköz, 0. mag a sok periféria elem miatt van, hogy ne akadjon össze. Szerintem.

Szívesen fogadok bármiféle észrevételt.

Ilyen nem jó?

https://www.ebay.com/itm/LAN8720-Module-Physical-Layer-Transceiver-PHY-Module-Embedded-Web-Server/263128425395?hash=item3d43ad23b3:g:8SwAAOSw8GhZhu2Q:rk:1:pf:0

Az amerikaiak $ milliókért fejlesztettek golyóstollat űrbéli használatra. Az oroszok ceruzát használnak. Én meg arduinot.

Nem próbáltad thread -del?
Akkor az op. rendszer állítgatja be a prioritásokat.
http://arduinouser.hu/esp32/AszalakEsAzESP32.pdf

Az amerikaiak $ milliókért fejlesztettek golyóstollat űrbéli használatra. Az oroszok ceruzát használnak. Én meg arduinot.

Hello,

Én inkább a memória/erőforrás kezelés rovására írnám.

Direct használod mindig a PCNT0 csatornát? Az IDF es példaprogramban interuptba számolja az eventeket és xQueue küldi a fő programba.

Szerintem ott akad szét, hogy ugyanazt az erőforrást címzed meg 2 külön taskből és már a setupnál kifagy ahogy írtad.

Amikor megy gondolom valaiért az egyik szál kicsit megcsúszik a FreeRTOS miatt és nem egyszerre próbál funtni 2 init.

Szálkezeléshez jó tervezés kell, mert könnyen lehet Deadlockba futni.

Release the Beast....

Két PCNT csatorna van használatban, semmi más nem hívja meg a saját taskján kívül.
Szándékosan nem szeretnék megszakítást használni és elvenni a cpu időt mástól, ha hardverből is mehet.

Megpróbálom a volatile változókat és a setup() végére rakom a task indítást. Meg utána nézek a szálkezelésnek, xQueue-nek.

(#10288) Janos250
Még nem olvastam el a linket, de "thread"? Ha ez nem ugyanaz mint a task, akkor most hallok erről először.
Ezt intelligensebben kezeli az RTOS?

szerk: na ilyet most látok először! És jóval egyszerűbbnek tűnik, mint az RTOS féle xTask.
Viszont gondolom ez nem ugyanazon az absztrakciós rétegen fut, ugye?

[ Szerkesztve ]

Szia

Vagy én néztem be (csak notepadba)

de csak a PCNT_CHANNEL_0 használod, tehát ugyanazt a csatornát próbálod meg 2x configolni.

static void initSpeedCounter(void)
{
pcnt_config_t pcnt_config = {
SPEED_SIGNAL_CAPTURE,
-1,
PCNT_MODE_KEEP,
PCNT_MODE_KEEP,
PCNT_COUNT_INC,
PCNT_COUNT_INC,
SPEED_COUNT_UNIT,
PCNT_CHANNEL_0
};

és itt is ugyanaz a channel 0...

static void initTachoCounter(void)
{
pcnt_config_t pcnt_config = {
SPEED_SIGNAL_CAPTURE,
-1,
PCNT_MODE_KEEP,
PCNT_MODE_KEEP,
PCNT_COUNT_INC,
PCNT_COUNT_INC,
TACHO_COUNT_UNIT,
PCNT_CHANNEL_0
};

Release the Beast....

Nem sajna... Ilyen kínai másolat modulokkal már meg szívtam, csak eredeti Arduinot szeretnék, csak sajna már sehol sincs...

"Go to work, get married, have some kids, pay your taxes, pay your bills, watch your tv, follow fashion, act normal, obey the law, and repeat after me: I AM FREE"

Nem próbáltam, nem hallottam még róla. Hasonló mint az RTOS task?

[ Szerkesztve ]

Pedig nem sok különbség van arduino és a kínai között. Biztos van kivétel, de tuti lehet találni olyat ami jól működik. Ja és jóval olcsóbban is. Nekem eddig egyik kinai modullal se volt bajom.

Jó észrevétel, ezt a bugot ki se szúrtam volna talán, csak telepítés után!
Amúgy nem hiszem, hogy ez volt a gondja. Azért nem, mert most nem tudom reprodukálni a hibát.
Letöltöttem újra azt, amit megmutattam kódot és most az sem hibázik bootoláskor.
Azóta annyi változás történt, hogy frissítettem az Arduino Core-t 1.0.1-re.
(Egyébként az új verzióban már rendesen működik a BT Serial, akit érdekel. Az 1.0.0 eldobálta a küldött adatot.)

Ezt a pvParameters-t nem tudom elképzelni hogy tudnám használni a task folytonos meghívása nélkül.
Nálam egyszer setup()-ban el van indítva a végtelen ciklus és ennyi. Indításkor tudnék átadni egy paramétert, de ez haszontalan futás közben.
Vagy arra célzol, hogy ez a koncepció eleve hibás? Lehet nem különálló és független ciklusokat kellene indítani, hanem minden egyes alkalommal meghívni mindent egyesével, majd ha lefutott törölni a példányt?
Ezzel viszont az a gondom, hogy így lényegében lineáris programfuttatás lenne belőle, ha nekem kell sorban elindítgatni a szálakat.

[ Szerkesztve ]

Én anno klón Uno-val szívtam. Volt, hogy a beletöltött program interrupt után lefagyott. Sőt volt olyan program ami meg bele se ment.
Érdekesség képpen, a két említett iromány a mega 2560ban meg minden gondolkodás nélkül hibátlanul futott.

[ Szerkesztve ]

Hello

Erre próbáltalak rávezetni...

A taskokat futattod, és a szükséges információkra vársz bennük.
xQueue meg küldöd az adatokat akár még interuptból is.

A folyamatos object létrehozás és törléstől én óvakodnék real time rendszerben.
- Sok idő lehet amíg azobjetumok törlődnek és újból létrehozódka
- Ha valamit nem szabadítasz fel a memóriából, vagy az alatta lévő könyvtás hibás akkor memory leak jelenséged lesz.

Tanácsom, hogy írd le mit szeretnél, --> requirement
tervezz hozzá tervezési minta alapján valami szép architectúrát
implement
teszt :-)

Enjoy it!

Release the Beast....

Épp az XQueue-val és az xSemaphore-ral ismerkedek.
Szeretnék kipróbálni egy bináris szemafort, amit egy megszakításból szeretnék "adni".
Kérdésem, hogy hogy lehet megcímezni Arduino-ban az UART RX portjára érkező adathoz kapcsolódó megszakítás vektort?

Jelenleg a Serial.available() függvénnyel végzek polling-ot, viszont biztos meg lehet valahogy oldani ezt megszakítással is.