- Milyen okostelefont vegyek?
- iPhone topik
- Apple iPhone 16 Pro - rutinvizsga
- További kavarás a Pixel 10-ek körül
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Okosóra és okoskiegészítő topik
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Egyszerre legnagyobb és legkisebb is a Garmin Venu X1
- Magyarországon is kapható a Moto G85 5G
- Samsung Galaxy A56 - megbízható középszerűség
Új hozzászólás Aktív témák
-
kovisoft
őstag
válasz
#90088192
#6278
üzenetére
Igazából processzor típusonként és C fordítónként is változhat, hogy melyik milyen algoritmust használ. De az eléggé általános, hogy valamilyen gyorsan konvergáló iteratív algoritmussal történik, nem pedig táblázatból olvassák ki. Régebben, még az FPU-k előtti időkben volt inkább jellemző pl. játékprogramokban a táblázatok használata, ahol nem volt szükség nagy pontosságra, viszont nagyon gyorsnak kellett lennie.
-
kovisoft
őstag
válasz
#90088192
#6272
üzenetére
A processzorok általában egy speciális iterációs algoritmussal számítják ki a szögfüggvényeket. Ezt úgy hívják, hogy CORDIC, aminek az az alapja, hogy a szöget felbontják olyan kisebb szögek összegére, amiknek a tangense 1/kettőhatvány. Az ilyen szögekkel történő forgatásnál a szorzást shifteléssel lehet helyettesíteni, ezért lesz hatékonyabb ez a módszer a Taylor-sor használatánál.
-
buherton
őstag
válasz
#90088192
#6266
üzenetére
Vagy nem teljesen érthető a kérdésed, vagy nekem vagy nagyon hétfő.
Ha jól azt szeretnéd elérni, hogy ne kiszámolja, hanem rögtön adja vissza az értéket, ugye? Gondolom ez a sebesség miatt kell.
A lookup table-re keress rá. Ezt sokféleképpen lehet implementálni. Talán a legegyszerűbb, hogy minden fokra legenerálod előre egy tömbbe és majd arra hivatkozol. Valahogy így:
const float degree_to_sin[] ={0, /* 0 degree */0.017, /* 1 degree */...};float res = degree_to_sin[1]; // res = sin(1)Persze ilyenkor a pontossággal lehetnek gondok.
-
jattila48
aktív tag
válasz
#90088192
#6266
üzenetére
Tudtommal az Intel processzorok tartalmaznak transzcendens (sin, log,...) floating point műveleteket. Egyébként valószínűleg vegyesen használnak táblázat adatokat, és közelítéseket. Igen hatékony tört közelítések léteznek ezekre. A szögfüggvények hatványsorai ugyan gyorsan konvergálnak, de tudtommal nem ezeket használják. Lehet, hogy táblázatból kikeresik a legközelebbi érték sinusát, majd az akörüli Taylor sor néhány tagjából egy törtet számítanak ki. Ez csak tipp.
-
dabadab
titán
válasz
#90088192
#6224
üzenetére
A számítástudomány az tényleg sokkal előrébb járt, mint maguk a számítógépek, George Boole (a Boole-algebra (a számítógépeknél alkalmazott logika) megalkotója halála után még majdnem egy évszázadott kellett várni az első digitális számítógépre, az információelméletről meg Shannon kb. mindent elmondott az 1940-es években.
A GOTO-problematika viszont nem ide tartozik, az színtisztán gyakorlati kérdés - azt Ada Lovelace nem láthatta előre, amikor Babbage gépére talált ki pár soros programokat, hogy milyen érzés lesz olyan kódot túrni, amit egy tíz évvel ezelőtt más céghez távozott kolléga írt
Az, hogy feltétlenül kell egy olyan utasítás, ami megváltoztatja a program végrehajtási helyét, az soha nem is volt kérdés, persze, hogy kell. Sőt, több is kell, mert olyanok is kellenek, amik különféle feltételek alapján változtatják meg.
Az összes processzorban vannak ilyen utasítások, senkinek semmi baja nincs ezzel, senki nem akarja kiírtani, vagyis tulajdonképpen bármilyen program fut a gépeden az tele van JMP-kkel (a GOTO gépi kódú megfelelőjének ez a mnemonikja).
Viszont a magasabb szintű nyelvekbe ezt egyre inkább becsomagolták, mint ahogy minden egyéb ilyen nyers dolgot is, hiszen a programozók általában nem arra vágynak, hogy megváltoztassák a programszámláló tartalmát, mert csak, hanem valamilyen összetett struktúrát hoznak létre: hurkot, feltételes programvégrehajtást, ilyeneket. Márpedig ha ők ilyeneket akarnak létrehozni, akkor adjunk a kezükbe olyan eszközöket, amikkel ezt csinálják közvetlenül, ahelyett, hogy JMP-vel bohóckodnának.
Ezzel együtt a GOTO megmaradt egy csomó magasabb szintű nyelvben is, egyszerűen azért, mert az azokban meglévő struktúrák lefedték a GOTO-használat nagyon-nagyon-nagy részét, de nem az összeset, így aztán maradtak olyan helyek, amikor az ember azt használja, mert adott esetben nincs jobb megoldás rá.
-
pmonitor
aktív tag
válasz
#90088192
#6228
üzenetére
Ebben a témakörben én egyértelműen az ELTE-vel értek egyet(pedig az egyetemekről sem jó a véleményem ÁLTALÁNOSSÁGBAN). Egyébként meg minden esetben el lehet kerülni a használatát. Ez alól nincs kivétel. Az viszont igaz, hogy néha plusz változó(kat) kell bevezetni, de még így is áttekinthetőbb, mint a goto.
-
pmonitor
aktív tag
válasz
#90088192
#6226
üzenetére
Idézet innen: > Ezekben a különböző számítógépeken futó BASIC programok szinte mindig inkompatibilisek voltak egymással: az egyik géptípusra írt programot más számítógéptípusokon nem lehetett futtatni.
Ez azért nem a magas szintű nyelvekre jellemző tulajdonság. Továbbá: > Az 1990-es évek elejére sokan leírták a Basicet, mivel a Basic alapú mikroszámítógépek kora lejárt, PC-n a C/C++ és a Pascal nyelvek vívtak ki vezető szerepet.
Igazából nem csak sokan leírták a BASIC-et, hanem a valóságban meg is szűnt. A Visual Basic már nem BASIC, csak BASIC-alapján készült. De már a Visual Basic is inkább csak a VBA-ban létezik. A Vb.Net meg egészen más dimenzió.
sztanozs elítélt, mert pascal témakörben készült irományokból idéztem. De ezek az idézetek nem csak a Pascal-ra vonatkoznak, hanem általánosan is igazak. Mint ahogyan írták, Pascalban nincs is return. Ettől függetlenül lehet a függvény törzsében is értéket adni a függvénynek a
függvénynév:=valamiformátumban(ej, de régen Pascaloztam). De látható, hogy a C-hez viszonyítva ennyivel szigorúbb nyelvben is tiltják a Goto-t(alapból nem is lehet használni benne, csak direktívával lehet bekapcsolni).De ha mindenképpen ragaszkodunk ahhoz, hogy csak szigorúan C nyelvre létrehozott irományokat fogad el valaki, akkor az olyannak meg itt van ez. Itt ezt írja:
> A strukturált programozást a goto utasítás elkerülésére, a program olvashatóbbá tételére találták ki, ezért a goto használata egyáltalán nem javasolt.Ezt direkt a C nyelvre írták(nem Pascal-ra).
A "ma" használt nyelvek között már a BASIC nem található meg. Sőt, az ismertebb nyelvek közül pl. a Java-ban nem is létezik a goto. Ebben a nyelvben pl. a #6219-es hsz-emben írt kódot nem is lehetne megírni. Java-ban a break-nek van 1 olyan "kibővített" funkciója, hogy egymásba ágyazott ciklusok esetén label használatával meg lehet adni, hogy a break melyik ciklusra vonatkozik. De ez nem egyenlő a goto-val(amivel össze-vissza LEHET ugrálni).
Szóval akárhol nézegetek utána, mindenhol a legfinomabb megfogalmazás is az, hogy nem ajánlják a használatát.
-
pmonitor
aktív tag
válasz
#90088192
#6224
üzenetére
BASIC != Visual Basic. A BASIC nem magas szintű nyelv(legalábbis ez alapján). Amit írsz, hogy pont azért olyan amilyen, hogy Egyszerű legyen használni, ez a Visual Basic-re igaz. A BASIC-et nem volt 1szerű használni. Ha azt látod, hogy
GOTO 100, akkor honnan tudod, hogy mi van a 100-as sorban? De szükség volt a GOTO-ra a sorok számozása miatt. A Visual Basic-et valóban 1szerű használni, de ott meg szükségtelen a GOTO használata. Tényleg csak hagyománytiszteletből maradt benne.Azért a marcsának és a csajnak nem ugyanaz az eredménye. Marcsánál nincs, ami olajozza/ápolja a matériát!
-
pmonitor
aktív tag
válasz
#90088192
#6214
üzenetére
Hogy miért találták ki? Hát pl. azért, mert a BASIC-ben pl. lehetetlen volt a programozás nélküle(ott még a sorok számozva voltak. De itt is írják:
> Léteztek olyan ősnyelvek, amelyekben nélkülözhetetlen voltHát többek között ezért. Na meg azért, mert akkor még nem bizonyították be, hogy GOTO nélkül mindent meg lehet oldani, nincs szükség rá.
Egyébként itt osztályozzák a programnyelveket, ahol látszik, hogy a C/C++ is magas szintű nyelv.
-
-
#90088192
törölt tag
válasz
#90088192
#6108
üzenetére
Most már értem, a karakter kiírásban, az y_offset a koordinatat határozza meg, a string kiiaratasban, meg ugye léptetését kell csinálni, hogy ne egymásra írja a karaktereket. Vagyis SZVSZ nem tudok vele semmit csinálni, hiszen van ahol csak 1db karaktert akarok kiiratni, akkor pedig nem működne ha jól sejtem
-
kovisoft
őstag
válasz
#90088192
#6106
üzenetére
Arra gondoltam, hogy egy korábbi hozzászólásodban így hívtad meg a write_char-t:
for(j=0;j<=i-1;j++) write_char(line,y_offset+j*Font_width,test[j]);És ebben a második paraméterben használod a Font_width-et is, ezt lehetne kiiktatni, ha egy struktúrában úgyis átadod a font paramétereket. Ehhez át kellene alakítani egy kicsit a paraméterezést (pl. ahogy javasoltam: kettéválasztani egy y és egy j paraméterre, és a write_char függvényen belül elvégezni az y+j*Font_width számolást).
-
kovisoft
őstag
válasz
#90088192
#6104
üzenetére
Persze, teheted a font paramétereket egy struktúrába, és akkor elég átadni erre a struktúrára mutató pointert a font választáshoz (vagy csúnyább esetben mehet az egész egy globális változóba). Pl:
#include "font1.h"
#include "font2.h"
struct font_type
{
long int *font;
int font_width;
int font_height;
int font_offset;
};
struct font_type myfont[2];
myfont[0].font = Font1;
myfont[0].font_width = Font1_width;
myfont[0].font_height = Font1_height;
myfont[0].font_offset = Font1_offset;
myfont[1].font = Font2;
myfont[1].font_width = Font2_width;
myfont[1].font_height = Font2_height;
myfont[1].font_offset = Font2_offset;
int write_char(int page_select, int y_offset, int character_code,struct font_type *use_font)
{
...
send_data_screen(use_font->font);
...
}
write_char(line,y_offset+j*myfont[0]->font_width,test[j],&myfont[0]);
write_char(line,y_offset+j*myfont[1]->font_width,test[j],&myfont[1]);De lehet, hogy jobb lenne az y_offset paramétert szétszedni egy y és egy j paraméterre, és a font_width-tel való szorzást beletenni a függvénybe, hogy ne kelljen azt is font-tól függően átadni:
int write_char(int page_select, int y, int j, int character_code,struct font_type *use_font)
{
int y_offset = y+j*use_font->font_width;
...
send_data_screen(use_font->font);
...
} -
kovisoft
őstag
válasz
#90088192
#6101
üzenetére
Ha jól értem, paraméterben szeretnéd átadni a write_char() függvényednek azt, hogy milyen betűkészletet használjon. Ehhez össze kell szedned, mi definiálja a betűkészletet. Egyrészt a Font[] tömb, másrészt a Font_width, Font_height, Font_offset (ha nem hagytam ki valamit). Ezeket fel kell venned még plusz paraméterként és átadnod a write_char()-nak, pl:
int write_char(int page_select, int y_offset, int character_code,
long int *font, int font_width, int font_height, int font_offset)És így tudod pl. meghívni:
write_char(line,y_offset+j*Font_width,test[j],Font,Font_width,Font_height,Font_offset);Mivel az y_offset számolásában is használod a Font_width-et, így szebb lenne ezt a függvényen belül végezni.
Ha pedig mindegyik betűkészlet ugyanolyan méretű, akkor elég csak a font tömböt átadni, nem kellenek a betűméretek.
-
kovisoft
őstag
válasz
#90088192
#6095
üzenetére
Szerintem csak annyi a gond, hogy a data_read() egy függvény, aminek a visszatérési értékét (ill. ehhez hozzácsapva még biteket) akarod átadni a send_data_screen()-nek. Viszont hiányzik a "()", így ténylegesen nem hívod meg a data_read-et, hanem a függvény címét adod át. Próbáld meg így:
send_data_screen(data_read() | (BASE_ADDRESS_PIXEL << x%Display_pages)); -
#90088192
törölt tag
válasz
#90088192
#6079
üzenetére
Megvan a probléma, igen érdekes Hardvere jellegű, azt gondoltam valami hülyeséget csináltam a karakter kódolással. Nem
Ez a jó:
int strobe_E(void) //Turns enabling line off/on
{
DelayUs(10);
DISPLAY_EN = 1; //Turns Display On
DelayUs(10);
DISPLAY_EN = 0; //Turns Display Off
DelayUs(10);
}és ez a rossz:
int strobe_E(void) //Turns enabling line off/on
{
DelayUs(10);
DISPLAY_EN = 0; //Turns Display Off
DelayUs(10);
DISPLAY_EN = 1; //Turns Display On
DelayUs(10);
} -
jattila48
aktív tag
válasz
#90088192
#6053
üzenetére
Alapvetően azzal kell tisztában lenni, hogy az #include-okkal beszúrt fájlok az őket beinklúdoló fájlokkal együtt egy fordítási egységet (translation unit TU) képeznek. Az #include egy direktíva, a C előfordítónak szól, és egyszerűen szöveg-szinten beszúrja az inklúdolt fájlt. Tehát olyam, mintha copy-pastéval bemásolnád a fájlt. Ezért az inklúdokban nem lehet körbe hivatkozás (a.h inklúdolja b.h-t, ami inklúdolja a.h-t), és nem lehet többször inklúdolni ugyanazt a fájlt (mert ekkor keletkezik a többszörös defínició). Az utóbbi elkerülésére az ún. include guard megoldást használjuk:
Pl. egy include file így néz ki:#ifndef __include_guard_h //itt a nev include fájlonként különböző és a fáj nevére utal
#define __include_guard_h
//ide jön az include file tartalma
#endif
Ezzel azt érjük el, hogy egy TU-ban ne lehessen az include fájlt többször beszúrni. Ugyanis először az __include_guard_h makró még nincs definiálva, tehát a fájl tartalma feldolgozásra kerül, miközben a makró definiálttá válik. Következő eseleges beszúráskor a makró már definiálva lesz, de a #ifndef direktíva hamosra lesz kiértékelve, vagyis a feldolgozás az #endif után folytatódik. A körbe hivatkozások ellen az include guard nem véd, arra neked kell odafigyelni.
C forrás fájlokat tényleg nem szoktunk inklúdolni. Ha több forrás fájlból áll a projected, akkor azokat a project létrehozásakor (project fájlban) kell megadni. Ezek külön-külön fordítási egységet fognak képezni (az általuk beinklúdolt header fájlokkal együtt), amikben már újra inklúdolhatod a másik TU-ban beinklúdolt header fájlt. A külön fordítási egységekben definiált függvények és globális változók egymás közötti elérhetőségét a linkelés (linker) fogja biztosítani.
Esetenként előfordul (pl. template-ek használatakor), hogy header fájlban függvény definícót írnak, amik a különböző TU-kba való inklúdolások után a linker számára valóban többszörös defínicók lesznek, de ezt a legtöbb linker kezeli. Ettől még kerülendő ez a gyakorlat, ha nagyon kell akkor inline-ként megadható, bár azt a fordító dönti el, hogy valóban inline módon fordítja-e. -
buherton
őstag
válasz
#90088192
#6051
üzenetére
Minden .c fájlból fordítódik egy .o fájl. A .o fájlokat fogja a linker összeszerkeszteni, aminek a vége egy bináris, amit te is használni fogsz. A .h fájlok, azért kellenek, mert abban vannak deklarálva a .c/.o szempontjából a külső függőségek, amiket a linker old fel a bináris összeállítása során.
Példa: A foo.c-hez kell tartoznia egy foo.h-nak, amiben a foo.c kívülről is elérhető makrók, típusok, változók és függvények vannak felsorolva. A main.c-ben elég a foo.h-t includolni, hogy a main.c leforduljon. Majd a linker összerakja a két .o fájlt.
A fordítást/linkelést az IDE tipikusan megoldja, neked csak a forrás fájlokkal kell bíbelődni.
-
buherton
őstag
válasz
#90088192
#6049
üzenetére
screen.h
void delay(unsigned int usec);
void lcd_select(int s);
void strobe_E(void);
void set_y(int y);
void dsp_on(void);
void clr_scr (int t);
void write_char(int line_select, int y_offset, int c);
void string_out(char* message, float variable, char line, char y_offset);A
hardware.h-ban pedig függvény definíciók vannak a deklarációk helyett. Nem illik ilyet csinálni. De ha nagyon muszáj, akkor azinlinekulcsszót kell elétenni.Kerüld a fölösleges pontosvesszőket. Nem illik ilyet csinálni.
Ha pedig
voida függvény paramétere, akkor írd ki, mert így variadikus lesz.A register map-re struktúrát és uniont szoktak ráhúzni és akkor nagyon frankón végigkövetehető, hogy ez melyik regiszter. A macro mágiát érdemes elkerülni.
Az include pathért legyen a build környezet felelős és ne hardcode-ld bele a kódba.
Új hozzászólás Aktív témák
Hirdetés
● olvasd el a téma összefoglalót!
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- Milyen házat vegyek?
- Milyen légkondit a lakásba?
- Elektromos rásegítésű kerékpárok
- Milyen okostelefont vegyek?
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Samsung Galaxy Felhasználók OFF topicja
- iPhone topik
- Gaming notebook topik
- Apple iPhone 16 Pro - rutinvizsga
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- További aktív témák...
- MSI Sword 15 A12VF 15.6" FHD IPS i7-12650H RTX 4060 16GB 512GB NVMe gar
- GAMER PC : RYZEN 7 7800X3D /// 32 GB DDR5/// RX 9070 XT 16GB /// 1TB NVME
- Eladó garanciális Hohem iSteady V2S gimbal
- Creative 3D Blaster 3Dfx Voodoo Banshee PCI (CT6760)
- Samsung Galaxy S22 Ultra 12/256GB Megkímélt,Kétkártyás,Tartozékaival. 1 év Garanciával!
- Jo Nesbo: LEOPÁRD (nem olvasott)
- ÁRGARANCIA!Épített KomPhone Ryzen 5 4500 16/32/64GB RAM RTX 3050 6GB GAMER PC termékbeszámítással
- Csere-Beszámítás! Intel Core I9 14900KS 24Mag-32Szál processzor!
- ÁRGARANCIA!Épített KomPhone Ryzen 9 5900X 16/32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Lenovo ThinkPad 40AF docking station (DisplayLink)
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest