Én is azért kezdtem el így használni.

Lenne ott még bőven mit ellenőrizgetni, de azzal nem töltöttem az időt. Majd most mindjárt megcsinálom kevésbé vázlatosan, figyelve a tegnapi dolgokra.

[ Szerkesztve ]

Szia!

Én annyit tennék hozzá, hogy mivel 0-tól 100-ig fogsz számokat tárolni így felesleges memória pazarlás int-et használni.
unsigned char *palyak;

Illetve a többi változó is lehetne char/unsigned char.

[ Szerkesztve ]

Igaz, köszi.

Olyan elengáns lesz lassan, hogy az már bűn.

Mivel defaultban ugyis aligned az egesz, igy aztan abszolut semmit nem takaritasz meg azzal, hogy chart hasznalsz, csak egy plusz korlatot vezetsz be, ami aztan a kesobbiekben problemassa valhat (ugyanez vonatkozik az unsigned-ra is).

Es ha mar kapcsos zarojelek: igazabol erdemes mindig kirakni oket, szemleltetem.

Kiindulasi allapot:

for(i=0;i<n;i++)
if (palyak[i]==0)
{
nemsi_index[a]=i;
a++;
}

Aztan az ember debuggol:

for(i=0;i<n;i++)
DEBUG("qweqwe");
if (palyak[i]==0)
{
nemsi_index[a]=i;
a++;
}

Es maris kesz a katasztrofa, amihez raadasul az IDE-k boldogan asszisztalnak (true story ).

[ Szerkesztve ]

DRM is theft

Már miért ne takarítana meg egy csomó memóriát a char?

Jester

Kenytelen vagyok visszakozni: megtakaritana, mivel itt csupa char lenne. Ha amugy egy csomo intje meg pointere lenne, es akoze rakna be egy-egy chart, akkor nem lenne megtakaritas, mert ott azoknak a 4 / 8 byte-os alignmentje bekavarna, de ha tenyleg mindenki char, akkor nincs ilyen gond.

DRM is theft

Én mindig ugyanabba a sorba rakom a nyitó kapcsost, még függvény definíciónál is

int main(void) {
return 0;
}

a típusjelölésre teszem a csillagot, mert olvashatóbb

char* nothing(char* string) {
return string;
}

Ja, és egy sorra soha nem használok kapcsost:

if (..)
for (...)
printf("Hit me!\n");

Hm, most látom csak hogy beírtam a voidot a paraméterek helyére - nem tudom, hogy ez mennyire szabványos, de a Pelles C compiler állandóan aggódik, ha nem teszem, ezért hozzászoktam

A kapcsos zárójel elhelyezése ízlés dolga, de az egy soros dolgok köré is erősen ajánlott kitenni őket, mivel ahogy arra dababab már rámutatott, később könnyen hibához vezethet.

Jester

Meg az ilyenek elkerülése végett:

#define PRINT_TEXT printf("foo"); printf("bar");

if(...)
PRINT_TEXT

vagy

if(...)
if(...)
else

Kihez is tartozik az else?

tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!

megint egy hülye kérdésem lenne a codeblocks-al kapcsolatban, valaki meg tudná mondani, hogy lehet kikapcsolni a kommentek helyesírás (?) ellenőrzését? most mindent szép piros hullámos vonallal aláhúz nekem, elég idegesítő hosszú távon, mert nehezíti a gyors olvasást.

nem is értem, legutóbb semmit nem kellett ilyenekkel vackolnom, most meg a angol hotkeyektől kezdve minden nevetséges hülyeséggel szívok.

What is your ikigai?

sziasztok!
restellem, hogy ilyenhez kell folyamodnom, de tudnátok segíteni programozás háziban? holnap van a leadási határidő, és marhára nem értem a témát. két feladatból áll. az egyik ez:
Írjon egy programot amely, létrehoz egy két dimenziós tömböt (mátrixot), tölti a mátrixot véletlen értékű elemekkel, és írja ki a tömböt klasszikus mátrix formában, utána még egyszer írja ki a mátrixot de a sorokból csinál oszlopokat és az oszlopokból csinál sorokat. Programja kalkuláljon a 3. sor és a 4. oszlop elemeinek az összegét.
a másik ez:
Írjon egy programot amely, megoldja egy lineáris egyenletrendszert.
Igazából magát a mátrix témakört nem értem, hogy az olyanokat, mint invertálás hogyan tudom megvalósítani c-ben.

Asrock B450 Pro4, AMD Ryzen 7 2700 @3.2GHz, Sapphire Radeon RX 5700 XT Pulse 8GB, Chieftec 600W

Sziasztok!
A problémám az lenne hogy c-ben elakadtam az fscanf használatánál. Egy file-ba irtam 138 db számot, 'k' a kezdőérték, 0.25-tal csökkentve. Ezt float-ban irtam ki (fprintf) és float-ban is olvastam vissza (fscanf). És hát a baj az hogy az első számot még jól olvassa be
de a többinél "levág" az elejéből. Előre is köszi a segítséget.

#include <stdio.h>
#include <stdlib.h>

int main()
{
FILE *file1;
char a='k';
int c=0;
double b, d;
file1=fopen("adat.txt","w+");
if(file1==NULL) printf("hiba");
while(c<138)
{
b=(double)(a);
d=b-(c*0.25);
fprintf(file1,"%f",d);
c++;
}
fclose(file1);

FILE *file2;
file2=fopen("adat.txt","r");
if(file1==NULL) printf("hiba");
char f;
float e=0;
while(!feof(file2))
{
fscanf(file2,"%f",&e);
printf("%f\n",e);
//f=(char)(e/1);
}
fclose(file2);
}

Privát üzenetre illik válaszolni!!!

rakj sortörést az fprintf-be
fprintf(file1,"%f\n",d);

Mellesleg minket suliban óva intettek az fscanf használatától. fgets-el kérd be majd sscanf-el jobban le tudod kezelni. // Nekünk így mondták és látok is benne rációt.

[ Szerkesztve ]

úgy már hibátlan köszi

Privát üzenetre illik válaszolni!!!

Hello!

Megkérdezhetném, hogy mi a gond a realloc függvénnyel? Miért nem tanácsos használni?
Mert az egyetemem úgy tűnik eléggé ellenzi.
Azt értem, hogy nem szerencsés sokszor meghívni (tehát pl minden új elemre egy tömbnél újraméretezni), mert ugye lehet hogy az egész területet át kell másolja. De pont olyan feladatot adtak ki, ahol le van írva, hogy minden új elemre növelni kell a tömb méretetét.
Így most kb. ugyanazt írom meg mint a realloc, csak éppen azt sem tudom megnézni, hogy van-e a memóriában hely a lefoglalt terület előtt...

http://flic.kr/ps/MuuJU | @gerhard_berger | https://github.com/gerhardberger

Szia!

Szerintem azért, mert sokan elfelejtik, hogy a realloc-nak a visszatérési értékét kell odaadni a pointernek. Ezt sokan elfelejtik, ugyanis ha új helyre másolja, akkor értelemszerűen a pointernek is változnia kell. Személy szerint nem tudom, hogy mi más probléma lenne ebből. Igaz, nálunk tiltott mindennemű dinamikus memória foglalás, mert ha használnánk, akkor a rendszer előbb utóbb lefagyna.

tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!

"Szerintem azért, mert sokan elfelejtik, hogy a realloc-nak a visszatérési értékét kell odaadni a pointernek."

Pont ezt nem szabad csinálni azelőtt, hogy megnézné az ember hogy NULL-t adott-e vissza a realloc – mert ha igen, akkor elveszted az eredeti memóriaterületet.

Ettől függetlenül se a realloctól, se a calloctól való félelmet nem értem az oktatásban, bár lehet hogy anno megmagyarázták; én meg elfelejtettem.

“All nothings are not equal.”

Megkérdezhetem, hogy milyen rendszert használtok, ami lefagy a dinamikus memória-foglalástól? MS DOS 3.0?

Én sem értem. Ha valakit érdekel itt van a slide, ahol felhívják a figyelmet erre. Leginkább a gondom amúgy az volt, hogy egy beadandónál nem fogadta el az oldal a programomat, mert szerepelt benne a realloc szó.

Még ezekkel kapcsolatban lenne olyan kérdésem, hogy ha meghívom realloc-ot, hogy kisebb memóriaterületet foglaljon, akkor levágja a lefoglalt területet? Ha igen, akkor mindig vagy ez függhet más dolgoktól?

http://flic.kr/ps/MuuJU | @gerhard_berger | https://github.com/gerhardberger

Gyanús hogy azért nem fogadta el, mert azt akarta, hogy kézzel implementáld le ugyanezt. A helyszínen kellett volna kifejtetni vele az ítéletét.

Az oldalon lévő szöveg is csak annyit mond, hogy lassú lehet – de ez éppúgy igaz arra is, ha kézzel mallocolsz nagyobb területet, átmásolod memcpyval, és felszabadítod az előzőt.

A kulcsmondat igazából ez: "Ne írjunk olyan programokat, amelyek gyakran méreteznek át tömböket!"

A szabvány alapján nincs arra garancia, hogy ha kisebbre reallocolsz, akkor nem fogja mozgatni a memóriát. Mindenképpen le kell kezelned a visszatérési értéket helyesen, azaz nézni a NULL választ, és nemNULL esetben kicserélni az előzőt siker esetén; ha fel-, ha leméretezel.

“All nothings are not equal.”

Áh értem most már.

(#4219) alapz@j: Nem op.rendszer függő, hanem architektúra. Az általunk használt ARM nem támogatja az MPU-t, így ha dinamikusan foglalsz memóriát, majd szabadítasz fel, akkor egy idő után teljesen széttöredezik a memória tábla, és lefagy az egész. De ha támogatná sem lehetne használni, mert automotive.

tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!

Van az alábbi kódom:
char *c = malloc(sizeof (char) * 5);
Tehát lényegében ezzel létrehoztam egy karaktertömböt. Ennek az értékét akartam megadni, majd kiíratni az alábbi módokon, de nem jött össze:
Két módszer az értékek megadására:
1. c = "Szia";
2. *c = "Szia";
Az 1. megoldást gondoltam hogy nem jó, mert ugye pointernek hülyeség értéket adni, az ugye csak a memóriacímet tudja tárolni.
A 2.-ban már bíztam, mert ugye a * operátorral visszamutatok a karaktertömbre, és úgy próbáltam megadni az értékét (mint hagyományos módon: char c[] = "Szia";)
Aztán ha esetleg működött is az előző, a printf()-el nem tudtam kiíratni sehogy.
Próbáltam így is: printf("%s",c); meg így is: printf("%s",*c); de mindkét próbálkozásnál kifagyott a program.
Szerintetek mi lehet a hiba?

:D Semmi :D

Így csak inicializáláskor lehet megadni, minden másra ott az strcpy / strncpy.

[ Szerkesztve ]

Ezzel már letárolod a memóriában a tömböt: "Szia!", erről nyugodtan lehet kérni pointert, ahogy függvény argumentumként szokták is csinálni, de csak megkötésekkel.

1 év PERL után tértem vissza a C-re, és nagyon felidegesítettem magam, hogy mi a hét szentségért nem hajlandó benyelni a fordító ezt: char foo[10]; foo = "bar";

strncpy, és strncmp függvényeket használd, és figyelj mindig a \0 karakterre. Az strlen-t pedig kerüld amennyire tudod.

(#4224) Korcsii: arra a MasterCard való .

tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!

Miért kell az strlen-t kerülni?

[ Szerkesztve ]

Mert ha elfelejtesz lezáró nullát tenni a string végére, akkor a strlen a világ végére is el tud menni.

tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!

Hát, de nem szabad kihagyni, amit mondjuk egy sima kiiratásnál azonnal észre veszel, ha nincs ott.

Igaz, de nem mindenhol elérhető a printf , vagyis éppen elérhető, de önmagában nem csinál semmit. AMúgy futottam már ilyenbe, és ha nincs rá debug akkor tud érdekes dolgokat csinálni.

tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!

Dehát ez nem az strlen hibája.
Most azért ne használjak egy már megírt fgv-t mert lehet, hogy hibás paraméterrel hívom meg?
A fejlesztő feladata és felelőssége, hogy helyesen használja a fgv-ket.
Most akkor a memcpy se használjuk mert lehet, hogy a source adatszerkezet kevesebb byte-ból áll mint amit a 3. paraméterben megadtunk?

Szerintem nem jó amit mondasz.
Tessék gondoskodni arról, hogy helyes paramétert adunk át a fgv-nek.
Az strlen() teljesen jól van megírva.

"Dehát ez nem az strlen hibája."

De. Nem veletlenul talaltak ki az strnlen()-t.

"Most azért ne használjak egy már megírt fgv-t mert lehet, hogy hibás paraméterrel hívom meg?"

Igen, foleg ilyen esetekben, ahol a parameter jo esellyel nem magabol a programbol, hanem inputbol szarmazik, mivel ezzel hatalmas kaput nyitasz a buffer overflow exploitoknak.

"Tessék gondoskodni arról, hogy helyes paramétert adunk át a fgv-nek."

Hat, ha 100%-ra meg tudsz eskudni arra, hogy az strlen csak es kizarolag rendesen null-terminated stringet kap (es ha barhol, barmikor, barki megvaltoztat valamit a programban, ami miatt ez majd nem all fenn, akkor abban a pillanatban lecsereled), akkor csinald, de nekem joval egyszerubbnek tunik az strnlen() hasznalata.

[ Szerkesztve ]

DRM is theft

A fejlesztőt védeni kell az ilyenektől, mert ha meg van a lehetőség a bakira, akkor a fejlesztő élni fog vele, és fog ilyen hibát véteni. Ahogy lehet látni az error exceptionokon, és rengeteg memory leak-en, és nem véletlenül retteg mindenki az optimazációs szint lépéstől , mert ilyenkor jobban összébb csúsznak a memóriában a dolgok, és igen hatékonyan eltudja rejteni a memória túl írásokat. A memcpy-nál meg tudod adni a méretet.

Nálunk új függvényeket csináltak erre, amivel biztosítva van, hogy a string mindig nullával végződik, így egy rakat hiba lehetősétől mentjük meg magunkat, de ettől függetlenül a hossz miatt még mindig vannak elírások akaratlanul is. Egy ilyen memória elírásnak a megkeresési ideje lehet 5 perctől 1 hétig terjedő idő, mert nálunk az OS nem árul el sokat, arról hogy hol történt a probléma.

tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!

Sziasztok!

Egy kis segítwséget szeretnék kérni.

Adott egy maximum 8 bájtos tömböm, amibe maximum 16 bites változókat szeretnék beszúrni bizonyos bitpozíciókra. A bitpozíciók a nyagságból adódóan 0-tól 63-ig lehetnek számozva. Az első megoldásom az lett volna hogy a tömb helyett használok egy 64 bites változót de ennek a kezelését nem támogatja az eszköz. Tudnátok erre a problémára valamilyen optimális megoldást mondani?

Köszönöm

mennyire jo megoldasod van?

en valami ilyesmit csinalnek:

uint16 array[4];

void insert(uint16 value, uint address)
{
uint pos;
uint shift;
pos = address >> 4;
shift = address & 0x0f;
array[pos] = value << shift;
array[++pos] = value >> ( 0x0f - shift);
}

Mondjuk ezt erosen endian-fuggo, szoval inkabb at kellene irni unit8-as tombre, de a lenyeg ez, meg kinullazza a byte-ok szelet, szoval ott valami maszkolni meg orozni kell, ha ez baj.

[ Szerkesztve ]

DRM is theft

Köszi.

Hát most végül működik 64 bites változóval de nem tudom mennyire optimális.
Ez az amikor kiveszek egy tömbböl elemeket

uint8_t LINReceiveBuffer[8];

LINScheduleTable[ScheduleTableIndex].LINScheduleTableFrame.LINFrameValue = 0;
for (Index = 0;Index < ResponseDataByteIndex-1;Index++)
{
LINScheduleTable[ScheduleTableIndex].LINScheduleTableFrame.LINFrameValue += (LINReceiveBuffer[Index+1] << ((LINScheduleTable[ScheduleTableIndex].LINScheduleTableFrame.LINFrameDataLength - 1 - Index)*8));
}

Ezzel rakom be:

if (ResponseDataByteIndex < LINScheduleTable[ScheduleTableIndex].LINScheduleTableFrame.LINFrameDataLength)
{

DataCheck = (uint8_t)(LINScheduleTable[ScheduleTableIndex].LINScheduleTableFrame.LINFrameValue >> (LINScheduleTable[ScheduleTableIndex].LINScheduleTableFrame.LINFrameDataLength - 1 - ResponseDataByteIndex)*8);
LINChecksumBuffer[ResponseDataByteIndex+1] = DataCheck;
USART_SendData(USART6,DataCheck);
ResponseDataByteIndex++;
}

Ize, ez nekem igy abszolut olvashatatlan, de ez alapjan nekem ugy tunik, hogy ezzel nem lehet tetszoleges bitre pozicionalni az adatot, csak byte hatarra.

DRM is theft

Igen itt már kész a 64 bites változó amit ki kell küldeni bájtosával. A te megoldásod sokkal jobban átlátható. Köszönöm

Továbbá még azt is vizsgálni kellene, hogy 16 bites határon van-e éppen, mert akkor elég 1 tömb elemet írni (ez ugye akkor fontos ha az utolsó elemről van szó, mert akkor a következő már túlírja a tömböt).

Ja és nem 0x0f - shift hanem 0x10 - shift

[ Szerkesztve ]

Jester

Köszi.
Melyik a jobb megoldás ha veszek egy 64 bites változót, és ebbe rakom be az adatokat, majd ezt bájtokra bontva elküldöm, vagy az ha a tömbbe rakom be a fenti módszerrel az adatokat és a tömböt küldöm ki?
Ugyanezt kell visszafele is, tehát van egy uint8_t tömb[8] tömb, amiből ki kell nyernem az adat pozíciótól az adott hosszú adatokat.

@dabadab: Bájtosával kell kiküldenem az adatokat, és úgy is kapom őket. Tehát vagy alapból bájt tömbben tárolom őket, vagy a 64 bites változómat darabolom bájtokra, valamint vételnél visszafele.

[ Szerkesztve ]

Igazan azt se ertem, hogy ha mar ott az adat a 64 bites valtozoban, akkor minek atmasolni a tombbe. Az endiannes miatt?

DRM is theft

Ha egy 64 bites változóban szeretném átírni a biteket az 5. bittől kezdődően 7 bit hosszan akkor hogy kellene kimaszkolni, hogy a többi bit ne változzon? Nem jut eszembe semmi értelmes általános megoldás. AZ offszet és a hossz változhat.

Köszi

uint64_t mask = (((uint64_t)1 << length) - 1) << offset;
val = (val & ~mask) | ((x << offset) & mask);

Ha a hossz 64 is lehet azt külön le kell kezelni. Ha az x eleve megfelelően van maszkolva akkor azt értelemszerűen nem kell mégegyszer.

[ Szerkesztve ]

Jester

Ha törölni akarod azt a szakaszt, akkor ÉSelned kell egy olyan számmal, ami a kívánt bitszakaszon 0, körülötte 1. Ha beállítani, akkor meg VAGYolnod kellegy olyannal, ami a szakaszon 1, mindenhol máshol 0.

Pl. 01010101 & 11100011 = 01000001,
Ill. 01010101 | 00011100 = 01011101

Persze az előbbi megoldás teljesebb, mert a maszkot is megcsinálja és konkrét értéket is tud

[ Szerkesztve ]

“All nothings are not equal.”

Nagyon szépen köszönöm, ez a -1 volt a kulcsszó
A hossz max 16 lehet.

@Karma: Köszönöm neked is, a maszkolást tudtam, hogy kell, csak kiszámolni nem tudtam a két értékből.

[ Szerkesztve ]

Sziaszto!

Egy érdekes problémával állok szembe. C-ben szeretnék stringeket darabolni. Ez egyenlőre nem tűnik nagy feladatnak, van egy függvényem ami szépen darabolja a dolgokat. A gond ott kezdődik, hogy amikor fel akarok szabadítani a feldarabolt részeknek allokált területet akkor egyszer a free függvény váratlan hibát generál és a mikrovezérlőm elmegy egy végtelen ciklusba.

EZ lenne a daraboló függvény:

char** str_split(char* a_str, const char* a_delim)
{
char** result = 0;
size_t count = 0;
char* tmp = a_str;
char* last_comma = 0;
size_t index;

/* Count how many elements will be extracted. */
while (*tmp)
{
for (index = 0; index < strlen(a_delim); ++index)
{
if (*(a_delim+index) == *tmp)
{
count++;
last_comma = tmp;
}
}
tmp++;
}


/* Add space for trailing token. */
count += last_comma < (a_str + strlen(a_str) - 1);

/* Add space for terminating null string so caller
knows where the list of returned strings ends. */
count++;

result = malloc(sizeof(char*) * count);

if (result)
{
size_t idx = 0;
char* token = strtok(a_str, a_delim);

while (token)
{
assert(idx < count);
*(result + idx++) = strdup(token);
token = strtok(0, a_delim);
}
//assert(idx == count - 1);
*(result + idx) = 0;
}

return result;
}

Ez pedig egy része a kódnak:

tokens = str_split(line, ",;");
if (tokens)
{
LINScheduleTable[frameIndex].Frame.SignalIDs_lda16[signalIndex] = atoi(*tokens);
LINScheduleTable[frameIndex].Frame.SignalOffsets_lda8[signalIndex] = atoi(*(tokens+1));
for (i = 0; *(tokens + i); i++)
{
free(*(tokens + i));
}

free(tokens);
}

Az érdekesség, hogy ez a részlet meghívódik kb 25-ször, és 26. lépésnél száll el.
Láttok valami hatalmas hibát a kódban?

Köszi

Milyen mikrokontrollerről van szó? Van benne MPU? Ha nincs, akkor a malloc/free használata teljes öngyilkosság, és borítékolható a fagyás. Ha auto változóba tárolod le a stringet, akkor azt stackre rakja, ha jól rémlik.

MPU nélküli MCU-kban is lehet dinamikus memóriákat foglalni, de ahhoz neked kell a kezedbe venned a memória menedzsmentet. A mi projektünkben a kommunikációs driver pont így működik.

[ Szerkesztve ]

tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!

Nincs MPU benne, egy stm32f407vg-ről van szó. Cortex M4 mag van benne.

Akkor meg van válasz a kérdésedre. A malloc/calloc/realloc/free tabu.

tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!

Köszi Nem tudtam hogy ennyire tiltott. Azt tudtam hogy beágyazott környezetben kb halál, de most szükségem lenne rá sajnos.

Van az oprendszerben saját heap kezelő. Sajnos ez is kiakad egy ponton. Amikor fel akarom szabadítani a char** változót.
Megnéznétek a kódot, hogy biztosan jól használom a dolgokat? Sajnos valami programozási hibára gyanakszom.

[ Szerkesztve ]

Az a baj a dinamikus memória használattal, hogy MPU nélkül nincs ki töredezettségmentesítse a memória táblát, és így előbb utóbb jön a hard fault exception, és jöhet a fej vakarás, hogy most ez mi a bánat volt, mert az RTOS-ek nem arról híresek, hogy szájbarágósan leírja, hogy mi történt (tapasztalat). Azt szokták csinálni, hogy előre lefoglalnak x memóriát, és arra írnak egy vezérlőt, ami karbantartja azt a területet, és ha kell akkor neked pointert, de ennek a technikai részletét nem ismerem. De mondom használj auto változót, vagy hát ha valaki másnak van jobb ötlete.

tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!