is there any reason why the thread has to stay on one core?
And on the topic of threads, what about changing to prioritising
threads? especially the audio thread.
And lastly, put in a schedular so threads dont have to explicitly
yield (maybe this will stop the problem where you have to reset if
/me backs away... quickly...
On 07/08/06, Daniel Stenberg [EMAIL PROTECTED] wrote:
On Mon, 7 Aug 2006, Jonathan Gordon wrote:
(This has nothing to do with Dan's original questions. I thought his
suggestions looked fine!)
is there any reason why the thread has to stay on one core?
At 05:18 07-08-2006, you wrote:
Greetings all,
I have been looking at using both cores on PortalPlayer based devices
(iPod, Sansa E200, iRiver H10.)
I think that supporting this is going to require changes to the threading
API so that threads can be run on both cores.
I propose:
1. Changing the
test
My SanDisk contact sent me a dev board with a JTAG cable attached.
Here's a
few early rough pictures of it:
http://daniel.haxx.se/sansa/e200/devb/tiny/
Looks like read sophisticated extra hardware. ;-)
BTW, the page is continuously reloading, at least for me.
Jörg
--
Echte
Hi,
During my holiday (in rockbox-country! Sweden :-) - but I forgot to look up
where rockbox HQ was...) I had some time to extensively test rockbox. I came
up with a few ideas, some of which I can implement myself, but lazy as I am,
if someone else likes them too and implements them for me,
Test recieved.On 8/8/06, mat holton [EMAIL PROTECTED] wrote:
test
: With regards to creating a thread on the second core, there is no
: guarantee that this will be available even on PortalPlayer machines, so
: the code to create a thread on the second core would be something like:
:
: my_thread = create_thread_on_core(COPROCESSOR, my_function, my_stack,
:
