Egyébként, ha mozgóátlagot használtok, akkor arra is van egy gyorsított változat, a rekurzív mozgó átlag, ahol az előző értéket felhasználva kapod mg az újat:

Rekurzív Mozgó Átlag

Ennél csak a legelső alkalommal kell a "hagyományos" módszerrel kiszámolni az átlagot, utána a rekurzív formulát használja az ember.

No offense, de ilyen kódot nem szabad írni, mert kiszúrsz magaddal. Igaz, hogy az embedded egy picivel másabb világ, mert jobban oda kell figyelni az erőforrásokra, de azért van egynéhány "trükk", amivel megkönnyítheted az életed.

A teljesség igénye nélkül,
- használj define-okat a magic numberek helyett
- a "mi történik itt" típusú kommenteket ne használd
- helyette tedd bele szépen a funkcionalitást egy öndokumentálóan elnevezett függvénybe
- lehetőleg a függvényeket úgy írd meg, hogy csak és kizárólag egyetlen feladatot hajtsanak végre (separation of concerns, illetve single responsibility principle)
- ne spórolj ennyit a szóközzel
- ne használj újra változót, ha nem muszáj

A define-oknak kétszeres hasznuk van: Egyrészt nevet adnak az értéknek, ami a kód értelmezhetőségét javítja, másrészt, ha egy értéked valamiért nem jó, vagy egyéb okból változtatnád meg, nem kell 900 helyen lecserélned (vagy itt-ott kifelejteni, aztán pillogni, hogy miért nem működik helyesen a program), elég csak a define-ban.

Az említett kommentek használata nagyon rossz szokás. Egyrészt csak afféle kibúvónak jó a nem teljesen átgondolt kód felelőssége alól, másrészt rontja az olvashatóságot, ha az embernek váltogatnia kell, hogy mit próbál épp olvasni, harmadrészt értelmezési és karbantartási problémákat is felvetnek. Ne a komment beszéljen, hanem a kód. A komment arra van, hogy szükség esetén (velem az elmúlt 4 évben egyszer fordult csak elő) odaírhasd, miért választottál egy adott megoldást, ha egyébként nem volna magától értetődő. Egy szó mint száz, nem a kommentből kell kiderülne, hogy mi történik, hanem magából a kódból.

A függvények által szépen el tudod különíteni egymástól a különféle műveleteket. Ezáltal egy esetleges hiba felfedezésekor sokkal egyszerűbb lesz javítani, mert nem szanaszéjjel kell keresgélni, hol rossz a cucc, hanem tudod, melyik függvénynek érdemes a körmére nézni. Ebben plusz segítséget ad a megfelelően megválasztott név, amely az olvasónak ránézésre elárulja, mi megy végbe a függvény belsejében. Fontos, hogy egy függvény ne több különböző dologgal foglalkozzon, hiszen akkor több minden romolhat el benne, és nem lesznek jól elválasztva egymástól a részfeladatok. Ha egy függvényed olyan 20-25 sornál hosszabb, akkor sanszos, hogy rosszul van szervezve és szét kellene szedni (hívjon ő is pár másik függvényt, amelyek az alacsonyabb szintű részfeladatokat ellátják). Ez az olvashatóságot is szolgálja, mert így nem kell scrollozgatni és a szemeddel fel-alá pásztázni egy-egy részlet megértéséhez, hanem első pillantásra ott lesz minden előtted, ami szükséges, nagyjából egy fókusznyi területen.

A szóközzel kapcsolatban, azt hiszem, nem kell sokat magyaráznom. Ha sok karaktert - amelyeknek ráadásul eltérő célja/jelentése van - egymás mellé zsúfolsz, akkor azt nehezebb lesz olvasni, kellemetlenebb a szemnek.
Pl.:

helyett

Ilyen define-t elvileg (más néven) tartalmaznia kellene az SDK-nak.

A változók újrafelhasználásánál pedig az a fő probléma, hogy összezavarja az embert, egyrészt afelől, hogy hol is jár a kódban, másrészt afelől, hogy az adott szekcióban mire szolgál. Jelen esetben itt a ciklusváltozóra gondolok, ami épp nem olyan nagy hiba, de gondolom, más változó esetében is előfordult már, hogy "ha már ugyanaz a típusa...".

Lehetőség szerint különítsd el az LCD kezelését a méricskéléstől és a számításoktól, mert nem ugyanarra a lapra tartozik (ld. egy fgv egyetlen dologgal foglalkozik) és csak nehézségeket okoz, ha több dolgot összekutyulsz egy helyen.

Ne riadj vissza a több fájlból álló megoldások alkalmazásától sem. Ha szétkapod, szép, rendezett, újrafelhasználható építőkockáid lesznek, amelyeket egyszerű kezelni, ráadásul egy következő projektednél csak előhúzod a fiókból az ADC-t vagy épp LCD-t kezelő modulodat és azt a kérdéskört ezzel le is tudtad.

Mindehhez persze kell egy afféle paradigmaváltás, de ha rááll a szemed és a kezed, nagyságrendekkel hatékonyabban tudsz majd dolgozni. Próbálj meg nem egyetlen, monolitikus algoritmusban gondolkodni, hanem sokkal inkább kis, triviális, a feladat érdekében egymással együttműködő modulokban.

Végezetül mégegyszer: Kérlek, még véletlenül se vedd ezt támadásnak; én jótanácsnak szánom, amelyet kezelj saját belátásod szerint.

Igen, így van. Köszönöm a kiegészítést a rekurzív mozgó átlagra vonatkozóan.
Nem akartam nagyon kirészletezni, ha elkezdi valaki a megvalósítását, akkor szerintem rájön magától, legalábbis esetemben így volt.

A FIR szűrővel kapcsolatos tudásod előtt meghajlok. Éreztem én, hogy jobban kellett volna figyelnem, mikor a suliban próbálták a fejünkbe verni, de ott olyan baromi bonyolult matekkal tálalták. Most lehet, elindítottál bennem valamit. Adok ennek a barátságnak még egy esélyt.

Én magamtól tanultam programozni (sajnos senki nem mondta, hogy ezt vagy azt nem szabad), és bevallom, én is kommentelem a saját kódomat.
Ha előveszem néhány héttel vagy hónappal később a saját forrásomat, a kommentek gyorsan felfrissítik emlékeimet, és tudom folytatni a kódírást, nem kell átnéznem az egész programot.
Nekem még a saját kódom esetén is előfordul néha, hogy "ezzel itt meg mi a fenét akartam".


Azt hiszem valami Microsoft-os kódban láttam valami ilyesmi függvény elnevezést:
int16 sqrt32_dma_hivas_bufferpointer_interrupt_masked_tudomisen_1(pointer1, pointer2,...);
es utana:
int16 sqrt32_dma_hivas_bufferpointer_interrupt_masked_tudomisen_2(pointer1, pointer2,...);

En az ilyen kodoktol tudok falnak menni. Nem vagyunk egyformák. Biztos igazad van, a legtöbb netről letöltött forrásban sincs komment, én szenvedek is vele, mire megértem, hogy hogyan működnek. Lehet, hogy te egy magasabb szintjét űzöd a programozásnak, amit én már nem értek, de nem fogom fel, hogy a komment miért rossz dolog.
A többi javaslatoddal egyetértek.

Valóban nem tesz jót a program átláthatóságán, ha telikommenteljük, de pl. egy rövid leírás egy függvénynél, esetleg változó értékekkel, az nem árt. Sőt, minden irodalomban azt írják, hogy ajánlott a kommentelés (ésszerű keretek között).
Főleg ha nagyobb programról van szó.

Tökéletesen egyetértek minden gondolatoddal.

Valójában itt elmagyaráztad az OOP(Objektum orientált programozás) lényegét.

Ami minden programnyelvben megvalósítható valamilyen formában.

S ami még fontos az a program tervezése, szerintem. Elég ha pl a flowcode kezelői felületére gondolunk. Ez valójában a program tervezése csak megpróbálja azt egy lépésben kódolni is.Nyilván nem fog se tömör kód lenni se lényegretörő. Ezért szószátyár.

Elméletileg minden probléma megoldható szekvencia, itereáció, és szelekció használatával.

Mindaddig kell egyszerűsíteni bővíteni a program logikáját amig ez a feltétel nem teljesül.
Néha lehetetlennek tűnő feladat a goto kihagyása pedig ha ez sikerül akkor igazi és jó a program(általánosságban beszélek mint programozási elvekről)

Tudom még javasolni egy másik írásmódot a "beszélő" változók elnevezéséhez amik talán szimpatikusabbak lehetnek az alulvonásnál pl.MinHomersekletErtek MaxHomersekletErtek
Ez sok tucat alulvonást megspórol ami fizikailag kedvezőbb az alulvonásnál s mégis jól olvasható a kód.

A legjobb és leghatékonyabb eljárások mindenképpen a függvények. Még abban az esetben is ha függvény hív függvényt.

S valóban ha sok csak egy célra készült függvény gyűlik össze akkor egy komplett, nagyon jól használható saját gyűjteményyel szinte bármi megoldható.

Igaz ez minden programmal működő bármire CNC-re, Pic-re bármire amiben processzorral kell dolgozni.

Ne gondold ezt magadról. Nyilván senki nem úgy születik, hogy azonnal tudná, hogyan érdemes megírni valamit. A Microsoft API-jainak függvényneveit ne nagyon nézd, mert egy letűnt korból származnak, ráadásul sok esetben a kényszer szülte őket. Értelemszerűen olyan nevet érdemes adni valaminek, amiből rögtön tudod, miről van szó. Pontosan ennek a hiánya és a kommentek alkalmazás ehelyett az okozója az "ezzel itt meg mi a fenét akartam" érzést. Magam is megjártam ezt sokszor, de amióta komoly gondot fordítok a kódminőségre, nem fordult velem elő ilyen. Pont a minap vettem elő egy 3-4 évvel ezelőtti kódomat, rögtön látszott, mi merre hány méter, kivéve azokat a részeket, ahol - no ezt nem szabad - siettem és összeb*tam kutyafuttában.

A programozás során szükség van a struktúráltságra. Jó, ha egy nagyobb projectben az összetartozó elemek külön file-okban vannak, define-okat használunk, így ezek az építőkockák jobban olvashatók, könnyebben újra felhasználhatók.
Azért ne essünk át a ló túloldalára. Nem akarom nagyon szétOFF-olni a topic-ot, de amikor egy egyszerűbb funkciójú programnak meglátom a forráskódját, és mondjuk több, mint 100 file-ból áll, és ugyanahhoz a hardverhez tartozik 10 header file, akkor felindultságomban egyből csapok a Delete gombra.
Hogy ne a levegőbe beszéljek: ARM programozásnál ott van a CMSIS, ami egy API gyűjtemény és az ARM adott ki, hogy segítse a programozók munkáját. Igyekszem nem használni.
Ha valamit vissza kell követni, hogy melyik regisztert hogyan állítja, legszívesebben sírva fakadnék.
4 file mélységben csak a #define-okat bogarászom, hogy melyik regisztert minek nevezte el.
Minek? Értem, hogy kompatibilitás, de agyonvágja a debugot.
Helyette lelkes amatőrök csinálnak API gyűjteményt, ami kiválthatja a CMSIS-t, ez a libopencm3. Sajnos hiányos, vannak benne hibák, de inkább ezzel szívok, mint a gyárival. Számomra sokkal olvashatóbb, nem hív meg 6-7 függvényt egy funkcióra, amiből 4 kb. annyit csinál, hogy felold egy-egy define-t. Kevesebb RAM-ot és Flash-t is eszik. A reference manual-ból is jobban követhető ez a fajta megoldás.
Nem tudom miért csinálnak ilyeneket, csak arra tudok gondolni, hogy az API-t nem egy emberke írja, és mindenki a feladatának nekiállva létrehozza a maga kis define elnevezéseit, hogy utána könnyebben tudjon hivatkozni valamire. Aztán persze ezt a sok részt egybe kell gyúrni, de akkorra már egy káosz lett a külön-külön kitalált sok hivatkozás.

Csak megerősíteni tudom, a camel case olvashatóbb. Ahogyan szvsz a "same line opening brace" is, mivel nem csapja szét a forrást egy plusz, felesleges, jelentést amúgy nem hordozó sorral.

Egyébiránt, ha valakit esetleg bővebben is érdekel a téma, akkor nem tudom eléggé ajánlani Robert C. Martin "Clean Code: A Handbook of Agile Software Craftsmanship" című könyvét, ami magyarul is megjelent, "Tiszta Kód: Az agilis szoftverfejlesztés kézikönyve" címmel. Igaz, hogy a példák többnyire Java, néha C++ nyelven íródtak, de minden tökéletesen érthető és követhető, a leírt technikák nagy többsége pedig bármelyik nyelvben sikerrel alkalmazható. Itthon 7-8 ezer forintért kínálják a könyvesboltok, de ha valaki esetleg attól tartana, hogy a futár elveszíti útközben, akkor PDF formában fellelhető az interneten (nekem is ez van meg; viva la előre jogdíjazott adathordozó )

A CNC-re eddig még nem is gondoltam, de mostmár kíváncsi vagyok

@toto: Igen, sajnos vannak rossz API megoldások. Pl. Android, bár az kevésbé borzalmas, mint amit te most leírtál. Vagy ott a PHP, ami az elnevezési és függvényhívási inkonzisztencia fellegvára hogy csak egy negatív példát említsek belőle. Persze, ettől függetlenül használom, csak nem a legjobb...

Igen mégpedig oly módon, hogy a függvényeket itt alprogramként értelmezzük. Ugyanúgy átadhatunk neki paramétert és kinyerhetünk belőle visszatérési értéket.

Önálló egy és csak egy feladat végrehajtására kell megírni őket majd akár fix értékkel akár paraméterezett értékkel bárhol meghívhatjuk a program végrehajtása során, feltéve hogy az input feltételek megfelenek(szerszámok a megfelelő helyen a tárban stb, stb)
Én több száz parametrikus programot írtam úgy ,hogy gyakorlatilag oop elven épült fel.
Az alprogramok önállóan bármely programban felhasználhatóak voltak, s a főprogram kizárólag a szükséges és elégséges hívásokat tartalmazta. Exact számértékek helyett minden esetben a kiszámítási képletek lettek programozva a koordinátákhoz így nem én kerekítettem hanem a vezérlés.

Igaz a mai fejlett Cam programok, sajnos "elavulttá" tették az egész eljárást, csakhogy az ilyenben szerzett tapaszatalat nélkül sajnos az a generáció aki kizárólag a cam-et ismeri és nem ért a klasszikus programozáshoz, az nem tud megfelelően gondolkozni sem.
Mivel a topic témája általános és technikáról szól, ezért nem gondolnám, hogy offolunk.
Bár kétségtelen tény, hogy ebben a témakörben tényleg a kinek a pap kinek a papné az érvényes.
"de gustibus non est disputandum"

Egy gondolat még ami talán ideillik.

Michelanelo kezében volt egy véső és egy kalapács, s a végeredmény a Dávid szobor.

Azóta hány ember vett a kezébe vésőt és kalapácsot, s hány Dávid szobor született?

Nem az a lényeg ki mit használ, hanem van-e hozzá érzéke vagy nincs.
Még magyarabbul nem mindegy hogy ki tolja a talicskát.

Nice! Valamikor belenézek

Sziasztok.
Kicsit lehet le leszek hurrogva, de azért megkérdezem.
Bent iskolában idén van először programozásunk. Ma írtunk először egy egyszerű programot (szöveg kiírása a képernyőre). Turbó PASCAL-ban tanulunk programozni _{(na ezért leszek lehurrogva, de sajnálom C-ben nem tanítanak)}, én pedig szeretnék itthon is gyakorolni. Ha esetleg valaki még használja ezt a régi programozási nyelvet ma is (vagy csak használta valamikor), akkor segítsen nekem. Milyen programozási környezetet (jól nevezem?) ajánl, amit winXP (esetleg MS-DOS) alatt el lehet indítani, és legálisan van ingyenes verzió belőle?

Szia!

Ha használhatót keresel, amiben esetleg még érdemlegeset is alkothatsz, akkor próbáld ki a Lazarus környezetét. Inkább Delphi, mint turbopascal, de a két nyelvben nagy az átfedés.

Köszönöm. Már töltődik is lefelé.

A Turbo Pascal 1.0, 3.02 és 5.5 ingyenes:

És a 7.01 francia változat:

Turbo Pascal for Windows 7 and Windows 8

Lejött, kipróbáltam, de nekem így elsőre nagyon repülőgép irányító pult.

Letöltöttem inkább a Turbo PASCAL 5.5-öt (köszönöm Hp41C), sokkal letisztultabb. Az első pár percben hiányzott ugyan az egér, de azután hozzászoktam.

Tényleg. Mekkora eséllyel indulna el a TP 5.5 egy IBM 8550 PC-n? Vagy erre inkább próbáljam ki az 1.0-át?
Csak érdekességképp kipróbálnám...

"Lejött, kipróbáltam, de nekem így elsőre nagyon repülőgép irányító pult. "

Az lehet,de hosszú távon jobban jársz vele. A Lazarus Delphi kompatibilis!

Ebben szinte biztos vagyok vagyok! Majd ha jobban megy már a programozás, akkor mindenképp fogom abban is gyakorolni. Egyelőre azért maradok az TP 5.5-nél, mert iskolában is ezt használjuk (illetve a TP7-est, de szinte ugyan az, csak a 7 már kezeli az egeret is).

Sziasztok. Meg tudná nekem mondani valaki, hogy miért nem működik az alábbi php programom?
Nem teszi be az adatokat az adatbázis táblába, de semmi hibaüzenetet nem ír ki.

<?php
require_once 'connect.php';

if(isset($_post['submit'])){
if (isset($_POST['veznev'], $_POST['kernev'], $_POST['adatok']) && !empty($_POST['veznev']) && !empty($_POST['kernev'])){
$veznev=htmlentities(htmlspecialchars($db->real_escape_string(trim($_POST['veznev']))));
$kernev=htmlentities(htmlspecialchars($db->real_escape_string(trim($_POST['kernev']))));
$adatok=htmlentities(htmlspecialchars($db->real_escape_string(trim($_POST['adatok']))));

$db->query("
INSERT INTO `emberek` (`id`,`veznev`,`kernev`,`adatok`,`csatlakozas`)
VALUES (null,'{$veznev}','{$kernev}','{$adatok}',NOW())
");
}
}
?>
<!DOCTYPE html>

<html>
<head>

<title>MySQLi...</title>
</head>
<body>
<?php
if($result = $db->query("SELECT * FROM `emberek`")){
if($result->num_rows){
$table = $result->fetch_all(MYSQLI_NUM);
echo '<table border="1">';
foreach($table as $row){
echo'<tr>';
foreach($row as $record){
echo'<td>'.$record.'</td>';
}
echo'</tr>';
}
echo '</table>';
}else{
echo '<p>Nincs hibás adat.</p>';
}
$result->free();
}
?>
<hr/>
<form action="<?php echo $_SERVER['PHP_SELF'] ?>" method="post">
<table>
<tr>
<td>*Vezetéknév:</td>
<td><input type="text" name="veznev" /></td>
</tr>
<tr>
<td>*Keresztnév:</td>
<td><input type="text" name="kernev" /></td>
</tr>
<tr>
<td>Magamról:</td>
<td><textarea name="adatok"></textarea></td>
</tr>
<tr>
<td colspan="2"><input type="submit" name="submit" value="Küldés!" /></td>
</tr>
</table>
</form>
</body>
</html>
<?php
$db->close();
?>

Köszönöm előre is.

Szia!

Én úgy csinálnám, hogy a query paraméterét (a lekérdezés tartalmát) egy önálló szöveges változóba raknám, és azt ki lehet íratni a képernyőre PHP-ból, mielőtt még a lekérdezést elküldenéd. Ebből két dologra is következtetni lehet:

1) minden adat, amire számítanál a PHP bemeneti oldalán, rendben megjelenik.

2) ha az 1-es pont helyes, akkor adatbázis oldalon megpróbálhatod a lekérdezést manuálisan elvégezni, s akkor az adatbázis motor hibaüzenettel visszatér, ha ott a gond.

Egyébként baj lehet a DB-struktúrával is akár, de sokminden ismeretlen a feladatról.

Illetve fejlesztés idejére célszerű bekapcsolni a PHP-ban a warning-ok és error-ok kijelzését. Ezzel is előrébb kerülhetsz, ha részeredményeket kiíratsz képernyőre, mert ha gond lenne, a PHP hibaüzenetet generál.

Köszönöm a válaszodat, de nem igazán értem miről is van szó.
Egyébként Erről a tutorialról csináltam de mégsem működik.

Az adatbázisod SQL kódját is tedd fel, hátha azzal van a gond.
Ha az adatbázis kezelőben viszel fel adatot a táblába, azt listázza a program?

Igen azt listázza, csak ha a "localhost/index php" ban adom be az adatokat. akkor semmi eredmény

Ha a phpMyAdmin -ban futtatod a kérést, akkor bekerül a táblába a record? Ott látnod kell a hibaüzenetet, ha nem tud lefutni.
Pl:

Erre mit ír ki, ha nem fut le hiba nélkül?

Igen Ha a phpMyAdmin -ban futtatom. akkor látom az adatokat.

Akkor tegyél a php kódodba ellenőrző részeket.
Pl: exit("Eddig OK");
Ellenőrizni kell, hogy megkapja- e a postolt adatokat, ha nem, miért nem, ha igen, akkor lefut-e az sql kérés, stb...
Ezeket ilyen pluszban beszúrt ellenőrző kódrészekkel meg tudod nézni.
Jó lett volna, ha kódként formázva teszed fel a kódodat, mert akkor könnyebb hivatkozni a kódrészekre azok sorszámával.

A teszteléskor minden egyes mező kötelezően ki volt / van töltve egyébként?

Arra gondolok, pl. a keresztnév mezőben volt-e érték. Ugyanis a PHP kód szerint ha ez a mező üres, akkor nem is hajtódik végre a további kód, nem kerülhetnek be az adatok.

---

Illetve kérdés még, hogy a megfelelő jogosultság be van-e állítva az adatbázisban ahhoz a felhasználóhoz, ami a connect.php fájlban meg van adva, és hogy a connect.php-ban ezek jól vannak még megadva.

Van egy pár hibalehetőség.

Inkább ez lesz a probléma...

Szia, igazad volt, így már működik!!! Ennyit számít a kis/nagy betű a kódban?
Köszönöm.