13.02.2014, 21:33
SI{AY писал(а):так что ищите у себя узкие места.
Да тут как бы и искать нечего, я уже раньше писал что SD карта у меня от дядюшки Ляо и четвёртого класса.
13.02.2014, 21:33
13.02.2014, 22:59
все карты уже давно от дядюшки ляо. Сколько брал ничем они не отличаются. Уже давно большая часть всего ток там и делается) Так что Вы рано сдаетесь. Если я праивльно прикинул, что скорость Вашего варианта, что скорость утилиты из комплекта DS, примерно одинаковы) Может дело реализации в KOS? у японца то похоже совсем самописаня. Протестите, будет ли результат лучше чем у Вас http://www.theisozone.com/downloads/drea...by-jj1dom/ тогда точно будет видно в карту упирается или в реализацию
14.02.2014, 08:11
PHP код:
<panel x="40" y="115" width="150" height="50">
<label width="150" height="20" x="0" y="0" font="arial" color="#000000" text="Enter name image" align="left" />
<input type="text"
font="arial"
fontcolor="#000000"
value="My_game"
size="30" x="0" y="20"
width="150"
height="20"
name="gname-text"
normal="input-normal"
highlight="input-high"
focus="input-focus" />
</panel>
Как в lua сохранить введённый текст в переменную?
14.02.2014, 08:11
Да я думаю еще флешка косячит, надо бы другую попробовать. У меня тоже есть флешки, которые работают примерно на такой же скорости.
А вот с DMA cybdyn верно сказал, сам по себе он скорости не прибавит, а вот если пустить его в параллель записи на флешку, тогда будет толк. А то у тебя простаивает проц пока ждет DMA, а ведь в этом то и вся его суть, чтобы разгрузить проц на другие задачи, пока данные передаются.
Но эта задача уже не совсем простая, тут без тредов и их синхронизации не обойтись.
В DS есть команда для тестирования скорости, попробуй:
Именно 2 раза, первый раз она файл создаст и протестирует запись, второй раз, файл уже существует, а значит будет тестироваться чтение.
В RC1 она правда с косячком, но в целом измерению он не мешает. В RC2 я ее подправил и улучшил немного.
А вот с DMA cybdyn верно сказал, сам по себе он скорости не прибавит, а вот если пустить его в параллель записи на флешку, тогда будет толк. А то у тебя простаивает проц пока ждет DMA, а ведь в этом то и вся его суть, чтобы разгрузить проц на другие задачи, пока данные передаются.
Но эта задача уже не совсем простая, тут без тредов и их синхронизации не обойтись.
В DS есть команда для тестирования скорости, попробуй:
Код:
speedtest /sd/file.bin
speedtest /sd/file.binВ RC1 она правда с косячком, но в целом измерению он не мешает. В RC2 я ее подправил и улучшил немного.
14.02.2014, 08:28
(14.02.2014 08:11)megavolt85 писал(а): [ -> ]Как в lua сохранить введённый текст в переменную?
Открой скрипт файл менеджера, там все есть что тебе нужно.
Если вкратце:
PHP код:
local app = DS.GetAppById(THIS_APP_ID);
local res = DS.listGetItemByName(app.elements, "gname-text");
local widget = GUI.AnyToWidget(res.data);
local text = GUI.TextEntryGetText(widget);
print("Image name - " .. text);
Понятное дело что не нужно каждый раз все это дергать, это как правило делается на этапе инициализации приложения, а потом уже манипулируешь только нужными виджетами.
Правда не пойму зачем тебе lua, логику приложения можно так же в модуле и написать.
14.02.2014, 08:38
я консольную утилиту написал, а теперь костыль прикручиваю в виде GUI. 
доберусь до модулей, перепишу код. Мне так проще си изучать
Про тест скорости я в курсе и судя по нему скорость рипа должна быть в 2,5 раза выше
доберусь до модулей, перепишу код. Мне так проще си изучать
SWAT писал(а):В DS есть команда для тестирования скорости
Про тест скорости я в курсе и судя по нему скорость рипа должна быть в 2,5 раза выше
14.02.2014, 14:41
Тебе не переписывать надо будет, а просто дописать недостающий модульный код.
А по поводу теста скорости, покажи результаты плиз.
А по поводу теста скорости, покажи результаты плиз.
14.02.2014, 18:55
Код:
speedtest /sd/test.bin
Test: write
Time: 46178 ms
Speed: 354 Kbps
Size: 16384 Kb
speedtest /sd/test.bin
Test: read
Time: 27010 ms
Speed: 606 Kbps
Size: 16384 Kb15.02.2014, 10:28
Ну результаты как минимум не выдающиеся.
Показывай код свой.
Показывай код свой.
15.02.2014, 14:20
PHP код:
// номер трека, первый сектор, количество секторов,тип диска,путь к файлу
int rip_sec(tn, first, nsec, type, dst_file){
int secbyte, istep ;
int nwritesec = 10 ;
uint8 secbuf[23520];
double result ;
double size_iso, write_iso;
int percent = 0;
int percentlast = 0;
int readi = 0 ;
if (type == 4) {
secbyte = 2048;
}
if (type != 4){
secbyte = 2352;
}
cdrom_set_sector_size (secbyte);
for (istep=0; istep <= nsec; istep += 10) {
if ( istep > nsec ) nwritesec = nsec % 10 ;
while (cdrom_read_sectors(CMD_DMAREAD,secbuf,first+istep,nwritesec) != ERR_OK){
readi++ ;
if (readi > 10 )
{
ds_printf("DS_ERROR: GD-ROM read error\n");
return CMD_ERROR;
}
ds_printf("GD-ROM read error. Attempt %d\n",readi);
}
readi = 0;
if (fwrite(secbuf,secbyte,nwritesec, dst_file) !=nwritesec){
ds_printf("DS_ERROR: Error write to file\n");
return CMD_ERROR;
}
if (istep != 0){
write_iso = (int) (istep*secbyte);
size_iso = (int) (nsec * secbyte);
if ((percent = (int) (write_iso * 100 / size_iso)) != percentlast) {
percentlast = percent;
result = istep*secbyte;
result = result/1024000;
result = ((int)(result*100 + 0.5))/100.0;
ds_printf("%d%% %4.2f MB\n",percent,result);
}
}
return CMD_OK;
}
Вот кусок отвечающий за чтение и запись. Правда он не совсем валидный, в плане того что сектора 2352 не будут писаться
Сижу вникаю как использовать треды.
15.02.2014, 15:44
Для DMA нужно чтобы буфер был в no cache area, иначе есть шанс словить косяка в данных.
Вот кусок из httpd-ack, на который я ориентировался при создании кастомных функций для чтения диска и на которых основан код рипа GD на SD самого автора этого мода:
Как видишь буфер у него гораздо больше. И не нужно его в стек запихивать, будет overflow. Стек не резиновый (всего 64кб на сколько я помню на тред), лучше динамически память выделять в таких случаях.
Я думаю что он не спроста такое количество считывает за раз, попробуй и ты.
Вот кусок из httpd-ack, на который я ориентировался при создании кастомных функций для чтения диска и на которых основан код рипа GD на SD самого автора этого мода:
PHP код:
#define MAX_SECTOR_READ 128
#define SECTOR_BUFFER (2352*(MAX_SECTOR_READ + 1))
#define MMAP_NOCACHE 0x20000000
char *buf, *nocache;
buf = memalign(32, SECTOR_BUFFER);
nocache = (void*)((mem_ptr_t) buf | MMAP_NOCACHE);
...
Как видишь буфер у него гораздо больше. И не нужно его в стек запихивать, будет overflow. Стек не резиновый (всего 64кб на сколько я помню на тред), лучше динамически память выделять в таких случаях.
Я думаю что он не спроста такое количество считывает за раз, попробуй и ты.
15.02.2014, 21:55
Приму к сведению, но без тредов я вижу не обойтись, если хочется выжать максимум. У меня в голове уже крутится одна идейка как это всё организовать
15.02.2014, 23:35
может как вариант с применение прерываний, смотря что проще.
в тредах вроде надо заводить мъютексы или чтото подобное для синхронизации
вообщемто можно проще, отправляем команду читать данные по дма. первый раз ждём флага о завершнии дма.
далее перед тем как писать эти данные на карту, отправляем команду приводу на считывание следующей порции данных. и к мемонту завершения записи первой порции думаю что дма от второй порции уже завершится, проверяем это и опять считываем след порцию c диска, и пишем вторую порцию.... и так в цикле.
т.е. пока пишем готовую порцию - параллельно будет считываться следующая...
и не надо потоков и т.д
дPугой вопрос правильно инициализировать команда чтобы по дма считывалось...
в тредах вроде надо заводить мъютексы или чтото подобное для синхронизации
вообщемто можно проще, отправляем команду читать данные по дма. первый раз ждём флага о завершнии дма.
далее перед тем как писать эти данные на карту, отправляем команду приводу на считывание следующей порции данных. и к мемонту завершения записи первой порции думаю что дма от второй порции уже завершится, проверяем это и опять считываем след порцию c диска, и пишем вторую порцию.... и так в цикле.
т.е. пока пишем готовую порцию - параллельно будет считываться следующая...
и не надо потоков и т.д
дPугой вопрос правильно инициализировать команда чтобы по дма считывалось...
16.02.2014, 00:22
Прерывания не дадут максимальной скорости, а второй вариант я как раз и хочу организовать, только
Цитата:пока пишем готовую порцию - параллельно будет считываться следующая...для этого нужен отдельный поток, иначе программа будет ждать завершения считывания (или я не правильно понимаю смысл одно/много поточных приложений?)
16.02.2014, 00:43
а что треты (или потоки как я понял,)) ) не по прерываниям чтоли переключаются))? , вроде используется таймер? или есть у проца спец возможность переключать?
я выше описал способ - по сути чтение с привода какбы происходит без участия проца в то время пока пишем в карту, и как бы и не нужны ни треты, ни прерывания
а треты - тут палка о двух концах, переключение потоков будет постоянно рвать передачу в карту, ну если там как то с приоритетами поработать может картина измениться... треты применяют в какихнить многозадачных системах, когда разные приложния параллельно запускаются.
я выше описал способ - по сути чтение с привода какбы происходит без участия проца в то время пока пишем в карту, и как бы и не нужны ни треты, ни прерывания
а треты - тут палка о двух концах, переключение потоков будет постоянно рвать передачу в карту, ну если там как то с приоритетами поработать может картина измениться... треты применяют в какихнить многозадачных системах, когда разные приложния параллельно запускаются.
16.02.2014, 01:04
треты это потоки, они не переключаются, а выполняются паралельно, без них не проиграть видеоролик со звуком (в одном потоке выводим картинку в другом звук, а основная программа обрабатывает пользовательский ввод) ни написать игру. рассмотрим на примере игры, в игре должен быть поток для вывода графики, поток для вывода звука, поток для обработки команд пользователя и т.д. допустим у нас стрелялка и мы сделали три выстрела, для каждого летящего патрона программа создаст отдельный поток
16.02.2014, 01:40
ничего там параллельно не выполняется.
заведен таймер, скажем на 1/1000 секунды, на котором висит шедулер потоков, и который крутит их как карусель, один-другой-третий и тд, каждый по чайной ложке кванта времени (1/1000с в нашем примере).
так все ядра операционок пашут, и ессно есть эффектики которые cybdyn описал.
заведен таймер, скажем на 1/1000 секунды, на котором висит шедулер потоков, и который крутит их как карусель, один-другой-третий и тд, каждый по чайной ложке кванта времени (1/1000с в нашем примере).
так все ядра операционок пашут, и ессно есть эффектики которые cybdyn описал.
16.02.2014, 03:20
MetalliC писал(а):ничего там параллельно не выполняется.имелось ввиду в рамках одной программы. вызвав функцию программа будет ожидать завершения работы этой функции, затем продолжит свое выполнение, в случае с потоком ,основная программа выполняется параллельно с программой в созданном потоке, а за тем как проц исполняет код в каждом потоке и с какой периодичностью их переключает нас не волнует, это задача ядра. По поводу глюков при использовании потоков, тут уже всё зависит от того, как реализована много-поточность в ядре. Откройте диспетчер задач и посмотрите сколько там процессов запущенно, условно возьмём что каждый процесс это один поток, но как ни странно и музыка в наушниках играет и торент качается и буквы на форуме читаются, причем всё одновременно и ничего не побилось ,а потоков в диспетчере мы насчитали не один и даже не тридцать
P.S. совсем забыл, предположим что у нас есть устройство способное принимать данные быстрее чем может отдать GD-Rom и есть два диска (CD-Rom и GD-Rom) с одинаковыми по объёму дорожками с данными, при этом GD диск спишется быстрее чем CD. GD-ROM работает в режиме CAV (постоянная угловая скорость) поэтому, чем ближе данные к концу диска, тем выше скорость их чтения. Отсюда вопрос, какая же средняя скорость чтения штамповки, может один мегабит при текущей реализации программы это нормально, а максимум можно будет выжать два мегабита?
16.02.2014, 07:14
К слову о тредах. Я совсем забыл тебе подсказать еще одну оптимизацию.
Дело в том, что в DS видео рендеринг находится в отдельном потоке, поэтому имеет смысл его заблокировать на время записи данных на SD. Или вообще на весь процесс, но тогда все на экране замерзнет конечно.
В KOS контекст для тредов переключается с частотой в 100Hz.
Тебе чтобы реализовать такую асинхронную работу, для начала нужно написать свою функцию для чтения секторов, которая будет работать асинхронно, а не ждать результата. А сам результат будешь отлавливать на прерывании.
Дело в том, что в DS видео рендеринг находится в отдельном потоке, поэтому имеет смысл его заблокировать на время записи данных на SD. Или вообще на весь процесс, но тогда все на экране замерзнет конечно.
PHP код:
LockVideo();
// write to SD
UnLockVideo();
В KOS контекст для тредов переключается с частотой в 100Hz.
Тебе чтобы реализовать такую асинхронную работу, для начала нужно написать свою функцию для чтения секторов, которая будет работать асинхронно, а не ждать результата. А сам результат будешь отлавливать на прерывании.
16.02.2014, 14:41
если треты исполняются на одном проце (ядре) то параллельно тут ничего не работает - а каждый поток исполняется процем в выделенный квант времени - или время до переключения на др. поток.
идея потоков тут сводиться к некой псевдо-параллельности,
есть понятия "приоритетности", не знаю точно есть ли возможно выделить этих квантов больше чем 1 , или как то увеличить время смены, т.е если поток по карте то естесно ему нужно больше времни
так же потоки выполняют полезную функцию арбитража доступа разных процессов к одноу источнику данных. например в игре надо с диска считывть с одного места видео, с другого аудио, в некий момент, надо текст подгрузить, 3д модели обновить. в потоках поэтому можно каждому процессу выделить время чтобы тот прочитал порцию данных и далее передать привод другому потоку. и так по очереди. опять же учитывая приоритеты))) например аудио чтобы работало без пауз
идея потоков тут сводиться к некой псевдо-параллельности,
есть понятия "приоритетности", не знаю точно есть ли возможно выделить этих квантов больше чем 1 , или как то увеличить время смены, т.е если поток по карте то естесно ему нужно больше времни
так же потоки выполняют полезную функцию арбитража доступа разных процессов к одноу источнику данных. например в игре надо с диска считывть с одного места видео, с другого аудио, в некий момент, надо текст подгрузить, 3д модели обновить. в потоках поэтому можно каждому процессу выделить время чтобы тот прочитал порцию данных и далее передать привод другому потоку. и так по очереди. опять же учитывая приоритеты))) например аудио чтобы работало без пауз