[C] Delay

[Verwijderd]

Hallo allemaal,

Ik heb nog nooit in de programmeertaal C gewerkt en nu moet ik voor school een opdracht maken in de programmeertaal C. Nu gaat het erom, dat ik een char array op het scherm laat zien, letter voor letter, met een vertraging tussen elke letter.

Ik heb overal gezocht maar (en waarschijnlijk zal dat aan mij liggen) ik kan simpelweg niet goed vinden wat ik nu moet doen om een kleine delay te creëren. De voorbeelden die ik vind heb ik geprobeerd, maar die lijken niet te werken.

Is er iemand die weet hoe ik het gevraagde moet doen? Dan kan ik daar namelijk op verder.

Met vriendelijke groet,

Marcel Sinteur

[Sleepkever]

Dat moet toch kunnen met een gewone sleep() lijkt me?

[TJHeuvel]

Ik ben geen C expert, maar de sleep functie lijkt te doen wat je wilt.

Waar heb je op gezocht? En wat deed het niet aan de samples die je gevonden hebt? Let wel, het is niet de bedoeling om alles zomaar te copy-pasten, probeer te begrijpen wat er gebeurt. Anders heb je er alsnog niets aan

[ Voor 45% gewijzigd door TJHeuvel op 26-04-2011 16:47 ]

[Verwijderd]

CyCloneNL schreef op dinsdag 26 april 2011 @ 16:46:
Ik ben geen C expert, maar de sleep functie lijkt te doen wat je wilt.

Waar heb je op gezocht? En wat deed het niet aan de samples die je gevonden hebt? Let wel, het is niet de bedoeling om alles zomaar te copy-pasten, probeer te begrijpen wat er gebeurt. Anders heb je er alsnog niets aan

Maar als ik unistd.h include en de sleep functie aanroep, krijg ik een melding met:
"Undefined reference of sleep"

Ik snap er even helemaal niets meer van. De methode sleep zou dan toch gewoon aangeroepen moeten kunnen worden? (Excuses voor het amateur-gehalte)

[L0we]

De methode kan gewoon aangeroepen worden op het moment dat je de juiste headerfiles include. (waar sleep() in beschreven is).

[Matis]

Het ligt nogal aan de compiler en OS waarop je bouwt.

GNU / Winbuild (POSIX), op Windows, Linux of Unix. Check ook je include paths en wat voor IDE gebruik je?

[Thralas]

Verwijderd schreef op dinsdag 26 april 2011 @ 16:43:
Hallo allemaal,

Ik heb nog nooit in de programmeertaal C gewerkt en nu moet ik voor school een opdracht maken in de programmeertaal C. Nu gaat het erom, dat ik een char array op het scherm laat zien, letter voor letter, met een vertraging tussen elke letter.

Slecht onderwijs als ze je niet de juiste constructs aanreiken (sleep in dit geval, of tenminste wat referenties naar leesmateriaal)

Is er iemand die weet hoe ik het gevraagde moet doen? Dan kan ik daar namelijk op verder.

Hangt helemaal af van je platform. Onder Windows zoek je Sleep() (declared in Windows.h.), onder een POSIX-compliant OS (Linux), sleep() in unistd.h (en het argument dat ze verwachten verschilt!)...

[Verwijderd]

@L0we;

Ik include unistd.h (Daar zou sleep() in moeten staan)

@Matis;

Ik ontwikkel op Windows, en gebruik Eclipse als IDE

[PieterAelse]

Probeer eens Windows.h te includen en Sleep(100); aan te roepen dan

[Matis]

Verwijderd schreef op dinsdag 26 april 2011 @ 16:57:
@L0we;

Ik include unistd.h (Daar zou sleep() in moeten staan)

@Matis;

Ik ontwikkel op Windows, en gebruik Eclipse als IDE

unistd.h bestaat helemaal niet onder Windows. Beter gebruik je windows.h

[Reptile209]

Kijk eens in de language-help van je IDE (F1) in welke headerfile deze functie zou moeten zitten. Blijkbaar zit hij - in jouw IDE - niet in unistd.h, want anders zou je je probleem al verholpen hebben.

[Verwijderd]

Matis schreef op dinsdag 26 april 2011 @ 17:01:
[...]

unistd.h bestaat helemaal niet onder Windows. Beter gebruik je windows.h

Dat heb ik ook gedaan, maar dan geeft ie een foutmelding over windows.h

Kan dat dan liggen aan het feit dat die misschien mist ofzo?

@Reptile;
sleep kan ik uberhaupt niet vinden als ik zoek in Eclipse.

Overigens wat eventueel belangrijk kan zijn maar ik vergeten was; Het is voor de Nintendo DS.

[ Voor 10% gewijzigd door Verwijderd op 26-04-2011 17:05 ]

[MacWolf]

Een hele simpele manier om een vertraging in te bouwen is gewoon een loopje te maken

for (int i = 0; i < 10000; i++) /* do nothing */ ;

Wel hopen dat je compiler het niet optimaliseert door de functie te verwijderen

[RobIII]

Verwijderd schreef op dinsdag 26 april 2011 @ 17:04:
maar dan geeft ie een foutmelding over windows.h

Ooooh! "Een" foutmelding! Ja, dan weten we wel waar je op doelt.

Verwijderd schreef op dinsdag 26 april 2011 @ 17:04:
Kan dat dan liggen aan het feit dat die misschien mist ofzo?

Dat vertelt die "een foutmelding" je dan wel lijkt me

Anyhow: dit is met foutmelding(en) en evt. je lesmateriaal lezen prima zelf op te lossen. Het feit dat dit "huiswerk" is (gezien de TR's) maakt dit topic nog niet fout; dat er geen eigen inzet aan te pas komt wél.

/edit:

Verwijderd schreef op dinsdag 26 april 2011 @ 17:04:
Overigens wat eventueel belangrijk kan zijn maar ik vergeten was; Het is voor de Nintendo DS.

Moet je vooral op zoek gaan naar windows.h ja

MacWolf schreef op dinsdag 26 april 2011 @ 17:06:
Een hele simpele manier om een vertraging in te bouwen is gewoon een loopje te maken

for (int i = 0; i < 10000; i++) /* do nothing */ ;

You're kidding, right? Wil je écht iemand die nog lerende is (en overigens: anyone for that matter) zoiets "leren"? Je vindt dit een serieuze suggestie? (Ja, het creeërt "een delay", zoals gevraagd, maar toch...)

[ Voor 44% gewijzigd door RobIII op 26-04-2011 17:13 ]

[RobIII]

En omdat deze edit:

Verwijderd schreef op dinsdag 26 april 2011 @ 17:04:


Overigens wat eventueel belangrijk kan zijn maar ik vergeten was; Het is voor de Nintendo DS.

kwam tijdens dat ik 't slotje plaatste zet ik 't weer even open; dit verandert de zaak wel wat en lijkt me idd lastig(er) te vinden. Neemt niet weg dat TS eens wat documentatie erop na kan/moet slaan en duidelijker/completer moet zijn met het posten van (relevante) info.

[ Voor 16% gewijzigd door RobIII op 26-04-2011 17:16 ]

[Manuel]

Als ik zo wat source-code bekijk van homebrew projecten, zie ik:

C:

#include <nds.h> 
#include <nds/system.h>
#include "sleep.h"

Lees anders ook eens: Introduction to Nintendo DS Programming

[RobIII]

Manuel schreef op dinsdag 26 april 2011 @ 17:23:
Als ik zo wat source-code bekijk van homebrew projecten, zie ik:

C:

#include <nds.h> 
#include <nds/system.h>
#include "sleep.h"

Dat lijkt me de DS in een sleep-mode ("power-save"?) te zetten?

[Manuel]

RobIII schreef op dinsdag 26 april 2011 @ 17:25:
[...]

Dat lijkt me de DS in een sleep-mode ("power-save"?) te zetten?

Ah, dat was het dus.

Het enige wat ik zo 1,2,3 kan vinden is een soort 'stopwatch' wat gebruikt maakt van timers.h, zie ook: http://devkitpro.org/libnds/a00049.html#a10 Wat ik mij alleen afvraag is waarom je voor school iets als dit moet maken zonder dat je enige informatie kan raadplegen.

[Icekiller2k6]

http://devkitpro.org/viewtopic.php?f=2&t=211

dit lijkt wel op wat je wilt.


edit:
en dit blijken ze overall in C te gebruiken
http://www.dreamincode.net/code/snippet2169.htm

[ Voor 40% gewijzigd door Icekiller2k6 op 26-04-2011 17:34 ]

[roy-t]

Is het echt voor de Nintendo DS? Het lijkt me erg vreemd om een indroductie curus C te geven op een DS

[Soultaker]

Even voor de goede orde: C (de programmeertaal) heeft hier geen standaardfunctie voor. Vandaar dat je op zoek moet naar platformspecifieke functies (sleep() of usleep() voor POSIX, Sleep() voor Windows).

Ik moet wel zeggen dat ik dit een waardeloze manier vind om een cursus C te geven.

[MacWolf]

RobIII schreef op dinsdag 26 april 2011 @ 17:06:
...

You're kidding, right? Wil je écht iemand die nog lerende is (en overigens: anyone for that matter) zoiets "leren"? Je vindt dit een serieuze suggestie? (Ja, het creeërt "een delay", zoals gevraagd, maar toch...)

Ik ben het met je eens dat het niet netjes is, maar ik kreeg het idee dat men op de opleiding van de topicstarter waarschijnlijk net een introductie C hebben gehad, dus misschien was dit wel het idee van de docent (na een les over loopjes bijv.). Maar het is inderdaad uiterst smerig

[farlane]

MacWolf schreef op dinsdag 26 april 2011 @ 18:58:
Maar het is inderdaad uiterst smerig

Nee, het is uiterst fout. Zelfs op een embedded uP waarbij je zeker weet dat het niet wordt weggeoptimaliseerd ( bij deze versie van de compiler ) is het een r*kconstructie. Al jaren. Gewoon niet doen.

[Verwijderd]

C:

char[] array = { 'A', 'B', 'C'};

int i;
for(i = 0; i < array.length; i++) {
     printf(array[i]);
     sleep(1);
}

Zoiets moet het zijn, dan zet ie het op het scherm met en delay van ik dacht 1 seconde
C is niet mijn sterkste kant, er kunnen fouten in zitten (Character ipv char ofzo )

[ Voor 17% gewijzigd door Verwijderd op 26-04-2011 22:05 ]

[RobIII]

Verwijderd schreef op dinsdag 26 april 2011 @ 22:03:

C:

char[] array = { 'A', 'B', 'C'};

int i;
for(i = 0; i < array.length; i++) {
     printf(array[i]);
     sleep(1);
}

Zoiets moet het zijn, dan zet ie het op het scherm met en delay van ik dacht 1 seconde
C is niet mijn sterkste kant, er kunnen fouten in zitten (Character ipv char ofzo )

Heb je überhaupt 't topic gelezen

[PrisonerOfPain]

Soultaker schreef op dinsdag 26 april 2011 @ 18:49:
Even voor de goede orde: C (de programmeertaal) heeft hier geen standaardfunctie voor. Vandaar dat je op zoek moet naar platformspecifieke functies (sleep() of usleep() voor POSIX, Sleep() voor Windows).

Mja goed, als je de thread wilt yielden terwijl je wacht heb je gelijk. Je kunt natuurlijk ook busy-waiten op clock().

[dragontje124]

Het is lang geleden dat ik voor de DS gedeveloped heb, maar volgens mij zou dit in ieder geval moeten werken:

C++:

int i;
for(i = 0; i<=1000; i++)  {
    swiWaitForVBlank(); //wachten op de vertical blank
}

wat swiWaitForVBlank(); doet is wachten totdat het scherm van boven tot onder getekend is.

[ Voor 16% gewijzigd door dragontje124 op 27-04-2011 00:09 ]

[MacWolf]

Nou, bij deze dan een nettere oplossing die mogelijk werkt op de DS:

Sleep()

Hello, I am currently tryig to make a small homebrew game and I would like to ask you if you know in what library is the sleep() function defined in. For windows, the function is declared in windows.h; do you know what the header is called for Wii/GameCube? I am using DevkitPro. Diego_pmc Talk 18:52, 21 September 2009 (UTC)
You may want to use my msleep function (you need to include ogcsys.h):
/**
* Waits for an amount of time in msec.
* @param[in] milisec Number of milliseconds to wait.
*/
void msleep(unsigned long milisec)
{
struct timespec req = {0};
time_t sec = (int)(milisec / 1000);
milisec -= (sec * 1000);
req.tv_sec = sec;
req.tv_nsec = milisec * 1000000L;
while(nanosleep(&req) == -1)
continue;
}
--Crayon 19:36, 21 September 2009 (UTC)
usleep could be found in unistd.h (I think). But consider reading this before using usleep. --Crayon 19:56, 21 September 2009 (UTC)
Yes, thanks you. I'll read the article you linked to as soon as I can. Diego_pmc Talk 16:26, 22 September 2009 (UTC)
msleep() works very well, thanks! Is this from you blog, 'cause I want to cite the sources for every code snippet that I use and is not written by me. Diego_pmc Talk 11:28, 27 September 2009 (UTC)
This is not my blog, when I said my function, I meant the one I'm using inside my app But if you want, just put a link to the Web site. --Crayon (talk) 14:32, 27 September 2009 (UTC)

Is van deze site met focus op Wii programmeren, dus geen 100% garantie dat dit de oplossing is, maar het is het proberen waard.

[TheBorg]

Het gaat niet om een DS, daarnaast is een loop voor een wacht functie nogal inefficient.
Ook kan ik me voorstellen dat een slimme compiler die een lege for lus ziet het ding gewoon weghaalt.
De "officieele" sleep functie lijkt mij dus het beste.
Misschien moeten ze op scholen maar eens les gaan geven in ANSI C/C++, dan heb je deze discussies niet nodig.

[RobIII]

MacWolf schreef op woensdag 27 april 2011 @ 01:03:
Nou, bij deze dan een nettere oplossing die mogelijk werkt op de DS:


[...]


Is van deze site met focus op Wii programmeren, dus geen 100% garantie dat dit de oplossing is, maar het is het proberen waard.

Al die busy-waits... blegh. dragontje124 in "[C] Delay" lijkt me een heel aardige nette oplossing mocht er geen "native sleep()" bestaan; de resolutie zal wel relatief laag zijn maar lijkt me voor de opdracht van TS meer dan voldoende.
edit: Ah, ik zie net ook de links naar o.a. hier staan; die zijn met je copy/past niet (goed) meegekomen.

TheBorg schreef op woensdag 27 april 2011 @ 01:08:
Het gaat niet om een DS

Huh? Volgens mij wel hoor?

Verwijderd schreef op dinsdag 26 april 2011 @ 17:04:
Overigens wat eventueel belangrijk kan zijn maar ik vergeten was; Het is voor de Nintendo DS.

[ Voor 49% gewijzigd door RobIII op 27-04-2011 01:24 ]

[PrisonerOfPain]

RobIII schreef op woensdag 27 april 2011 @ 01:14:
[...]

Al die busy-waits... blegh.

Mwa, het is voor een embedded systeem met twee CPUs van respectievelijk 66 en 33Mhz die elk één hardware thread runnen. Het enige waar je je druk over zou kunnen maken is de batterijduur van het ding maar ik betwijfel of de ARM ISA een instructie heeft die een CPU voor een bepaalde tijd laat slapen zonder daar een negatieve invloed op te hebben. Kortom, busy waiten is prima in dit geval.

dragontje124 in "[C] Delay" lijkt me een heel aardige nette oplossing mocht er geen "native sleep()" bestaan; de resolutie zal wel relatief laag zijn maar lijkt me voor de opdracht van TS meer dan voldoende.

Wachten op de vblank heeft ook z'n nadelen (ga maar uit van een accuracy van 33milliseconde - een frame - en wellicht gedoe met de vloeiendheid van je graphics-routines) en is ook gewoon geimplementeerd als een busy wait: http://devkitpro.svn.sour...revision=3919&view=markup

edit: Ah, ik zie net ook de links naar o.a. hier staan; die zijn met je copy/past niet (goed) meegekomen.

Dat is geschreven door iemand die z'n sleep functie recursief laat wachten (genoeg interrupts kunnen een stack overflow veroorzaken) en niet ieder codepath een return value geeft.

C:

int __nsleep(const struct timespec *req, struct timespec *rem)
{
    struct timespec temp_rem;
    if(nanosleep(req,rem)==-1)
        __nsleep(rem,&temp_rem);
    else
        return 1;
}

[ Voor 53% gewijzigd door PrisonerOfPain op 27-04-2011 02:27 ]

[farlane]

PrisonerOfPain schreef op woensdag 27 april 2011 @ 01:44:
Mwa, het is voor een embedded systeem met twee CPUs van respectievelijk 66 en 33Mhz die elk één hardware thread runnen. Het enige waar je je druk over zou kunnen maken is de batterijduur van het ding maar ik betwijfel of de ARM ISA een instructie heeft die een CPU voor een bepaalde tijd laat slapen zonder daar een negatieve invloed op te hebben. Kortom, busy waiten is prima in dit geval.

Om te gaan busywaiten in de ms range is wel vies dan ja imho ( zeker als ie ook nog in je main loop zou zitten ). Als je toch zo dicht op de hardware zit neem dan een hardware timer.

[Verwijderd]

PrisonerOfPain schreef op woensdag 27 april 2011 @ 01:44:

[...]


Dat is geschreven door iemand die z'n sleep functie recursief laat wachten (genoeg interrupts kunnen een stack overflow veroorzaken) en niet ieder codepath een return value geeft.

C:

int __nsleep(const struct timespec *req, struct timespec *rem)
{
    struct timespec temp_rem;
    if(nanosleep(req,rem)==-1)
        __nsleep(rem,&temp_rem);
    else
        return 1;
}

Dat is een tail call, dus het zou niet bepaald uit moeten maken. Een beetje compiler weet hier raad mee, denk ik.

[ Voor 7% gewijzigd door Verwijderd op 27-04-2011 09:50 ]

[PrisonerOfPain]

Verwijderd schreef op woensdag 27 april 2011 @ 09:48:
[...]
Dat is een tail call, dus het zou niet bepaald uit moeten maken. Een beetje compiler weet hier raad mee, denk ik.

Ik vertrouw mijn compiler niet; het kan prima het geval zijn dat je compiler hier geen raad mee weet.

@farlane: agreed :-)

[Verwijderd]

MacWolf schreef op dinsdag 26 april 2011 @ 18:58:
[...]


Ik ben het met je eens dat het niet netjes is, maar ik kreeg het idee dat men op de opleiding van de topicstarter waarschijnlijk net een introductie C hebben gehad, dus misschien was dit wel het idee van de docent (na een les over loopjes bijv.). Maar het is inderdaad uiterst smerig

Leuker nog; We hebben nog níets over C gehad. Geen introductie niks. Alleen de opdracht om iets in C te maken. Echter weet ik wel weer genoeg van programmeren om te concluderen dat onevenredig veel 'nutteloze' opdrachten uit te voeren, om een delay te creëren, niet de juiste oplossing is. Lijkt me niet zo netjes.

Ik heb nu inderdaad de oplossing van dragontje124 gebruikt.

(Reden dat ik laat reageer is overigens, omdat ik dacht dat het topic nog gesloten was..)

[EddoH]

Verwijderd schreef op donderdag 28 april 2011 @ 15:29:
[...]

Echter weet ik wel weer genoeg van programmeren om te concluderen dat onevenredig veel 'nutteloze' opdrachten uit te voeren, om een delay te creëren, niet de juiste oplossing is. Lijkt me niet zo netjes.

Ik heb nu inderdaad de oplossing van dragontje124 gebruikt.

Ach, waarschijnlijk doet swiWaitForVBlank() iets als:

code:

 while(! REG & VSYNC_BIT);

dus of het minder 'nutteloze' acties doet valt te betwisten

[PrisonerOfPain]

EddoH schreef op donderdag 28 april 2011 @ 16:03:
[...]


Ach, waarschijnlijk doet swiWaitForVBlank() iets als:

code:

 while(! REG & VSYNC_BIT);

dus of het minder 'nutteloze' acties doet valt te betwisten

Dat is precies wat het doet

[EddoH]

edit: ahum, excuus, waande me in de devschuur

[ Voor 91% gewijzigd door EddoH op 28-04-2011 16:10 ]

[Verwijderd]

PrisonerOfPain schreef op donderdag 28 april 2011 @ 16:05:
[...]


Dat is precies wat het doet

offtopic:
Verschilt de 'swi'-instructie niet significant met een echte no-op?

[PrisonerOfPain]

Verwijderd schreef op donderdag 28 april 2011 @ 17:37:
[...]

offtopic:
Verschilt de 'swi'-instructie niet significant met een echte no-op?

Als ik het goed lees gebeurt er een fall-though naar wait_irq welke gewoon busywait tot 'ie er bij neervalt. Let op dat 'bx lr' een return statement is en 'nop' niet Geen idee wat de 'swi' instructie doet verder, heb heel weinig kennis van ARM assembly.

[ Voor 10% gewijzigd door PrisonerOfPain op 28-04-2011 17:44 ]

[Verwijderd]

PrisonerOfPain schreef op donderdag 28 april 2011 @ 17:42:
[...]


Als ik het goed lees gebeurt er een fall-though naar wait_irq welke gewoon busywait tot 'ie er bij neervalt. Let op dat 'bx lr' een return statement is en 'nop' niet Geen idee wat de 'swi' instructie doet verder, heb heel weinig kennis van ARM assembly.

SWI roept een software interrupt aan. Hij roept dus over een system call aan tot deze een acceptabel antwoord retourneert (in r0). Zo heel busy is het dus niet als dit de system call voor 'wacht op hardware interrupts' is.

[RobIII]

Verwijderd schreef op donderdag 28 april 2011 @ 17:54:
[...]
SWI roept een software interrupt aan. Hij roept dus over een system call aan tot deze een acceptabel antwoord retourneert (in r0). Zo heel busy is het dus niet als dit de system call voor 'wacht op hardware interrupts' is.

Dat is ook precies zoals ik 't las/begreep. Maar ook voor mij is deze materie niet echt dagelijkse koek so I could be mistaken

[PrisonerOfPain]

Verwijderd schreef op donderdag 28 april 2011 @ 17:54:
[...]
SWI roept een software interrupt aan. Hij roept dus over een system call aan tot deze een acceptabel antwoord retourneert (in r0). Zo heel busy is het dus niet als dit de system call voor 'wacht op hardware interrupts' is.

Ah! De hamvraag is of dat ding z'n executie blockt of niet. Het waarschijnlijkste lijkt me dus van wel?

[farlane]

PrisonerOfPain schreef op donderdag 28 april 2011 @ 18:11:
Ah! De hamvraag is of dat ding z'n executie blockt of niet. Het waarschijnlijkste lijkt me dus van wel?

Het is een software interrupt, volgens mij draaien die altijd met een hogere prioriteit dan de user context.

[Verwijderd]

farlane schreef op vrijdag 29 april 2011 @ 23:11:
[...]

Het is een software interrupt, volgens mij draaien die altijd met een hogere prioriteit dan de user context.

Geen idee waar je het over hebt. Bij een SWI wordt direct de program counter op 0x8 gezet, gaat de processor over in supervisor-modus en worden een paar registers uitgewisseld. Eigenlijk is het een branch plus wat administratieve zaken.

[Wolfos]

Sleep werkt geloof ik alleen op Unix systemen, een Windows programmeur zei ooit tegen mij dat die functie niet werkte.

[MLM]

Wolfos schreef op zondag 01 mei 2011 @ 10:39:
Sleep werkt geloof ik alleen op Unix systemen, een Windows programmeur zei ooit tegen mij dat die functie niet werkte.

Sleep met een hoofdletter werkt alleen op Win32, sleep zonder hoofdletter werkt met POSIX (zoals, linux and unix). Argument type is volgens mij altijd integral, maar de grootte (in bits) en de interpretatie verschil per OS, dus lezen van de documentatie is een goed plan

[farlane]

Verwijderd schreef op zaterdag 30 april 2011 @ 12:42:
Geen idee waar je het over hebt. Bij een SWI wordt direct de program counter op 0x8 gezet, gaat de processor over in supervisor-modus en worden een paar registers uitgewisseld. Eigenlijk is het een branch plus wat administratieve zaken.

Waar ik op doelde is dat de prioriteit van de SWI hoger is dan de normale, en volgens mij ook hoger dan een ander normaal interrupt, dus het kan niet anders dan dat de processor eerst die taak uitvoert en daarna pas verder gaat.

Tenzij de processor in de SWI naar een of andere sleep mode gaat moet het dus wel een busywait zijn.

/edit
Is dus niet hoger dan andere interrupts

[ Voor 4% gewijzigd door farlane op 01-05-2011 14:45 ]

[Soultaker]

Het punt is niet dat de swi-instructie in slaapstand gaat, maar dat je er een operating system functie mee callt, die dan hopelijk iets slimmers doet dan busy waiting.

Met wat Googlen vind ik deze site met specs van de Nintendo DS. Onder de aanname dat het om de ARM7-gebaseerde versie gaat, wordt de Halt BIOS-functie gecalld:

SWI 06h (NDS7/NDS9) - Halt
Halts the CPU until an interrupt request occurs. The CPU is switched into low-power mode, all other circuits (video, sound, timers, serial, keypad, system clock) are kept operating.

Samenvatting: dit is geen busy loop.

[dragontje124]

Soultaker schreef op zondag 01 mei 2011 @ 16:36:
Het punt is niet dat de swi-instructie in slaapstand gaat, maar dat je er een operating system functie mee callt, die dan hopelijk iets slimmers doet dan busy waiting.

Met wat Googlen vind ik deze site met specs van de Nintendo DS. Onder de aanname dat het om de ARM7-gebaseerde versie gaat, wordt de Halt BIOS-functie gecalld:

[...]

Samenvatting: dit is geen busy loop.

De Nintendo DS bestaat uit 2 ARM CPU's (een ARM7 en een ARM9 CPU) met elk eigen taken
de ARM7 CPU zorgt volgens voornamelijk voor bijvoorbeeld de WiFi verbinding en het geluid.
Zoals hier ook staat: http://nocash.emubase.de/gbatek.htm#dstechnicaldata
onder het kopje "The two Processors" wordt de meeste gamecode op de ARM9 chip uitgevoerd, Nintendo laat officieel developers niet eens programmeren op de ARM7 CPU.
Meestal wordt de door devkitPro standaard meegeleverde ARM7 code gebruikt om te compilen.
De kans is dus groot dat het hier om de ARM9 CPU gaat en niet om de ARM7 CPU

[farlane]

Soultaker schreef op zondag 01 mei 2011 @ 16:36:
Het punt is niet dat de swi-instructie in slaapstand gaat, maar dat je er een operating system functie mee callt, die dan hopelijk iets slimmers doet dan busy waiting.

Met wat Googlen vind ik deze site met specs van de Nintendo DS. Onder de aanname dat het om de ARM7-gebaseerde versie gaat, wordt de Halt BIOS-functie gecalld:

Samenvatting: dit is geen busy loop.

Die functie beschrijft toch een 'sleep mode', hij heet alleen 'low power mode'. Hoe zou je anders op OS niveau iets anders kunnen doen dan busywaiten, dat moet toch een hardwarematig iets zijn?

De opmerking van Tinctorius mbt de 'wacht op hardware interrupt' was dus wel terecht.

[ Voor 5% gewijzigd door farlane op 01-05-2011 19:35 ]

[Soultaker]

dragontje124 schreef op zondag 01 mei 2011 @ 17:41:
De kans is dus groot dat het hier om de ARM9 CPU gaat en niet om de ARM7 CPU

Ook goed; volgens de documentatie die ik quotte wordt dan dezelfde functie aangeroepen.

farlane schreef op zondag 01 mei 2011 @ 19:32:
De opmerking van Tinctorius mbt de 'wacht op hardware interrupt' was dus wel terecht.

Ja, inderdaad. Ik geloof dat ik je punt niet helemaal begrijp, want voor zover ik weet zijn we het eens

[farlane]

Soultaker schreef op maandag 02 mei 2011 @ 00:11:
Ja, inderdaad. Ik geloof dat ik je punt niet helemaal begrijp, want voor zover ik weet zijn we het eens

Ehm ja, ik geloof het ook. Weet nou eigenlijk ook niet meer wat mijn punt precies was