вызов функции на С

[megavolt85]

SI{AY писал(а):так что ищите у себя узкие места.

Да тут как бы и искать нечего, я уже раньше писал что SD карта у меня от дядюшки Ляо и четвёртого класса.

[SI{AY]

все карты уже давно от дядюшки ляо. Сколько брал ничем они не отличаются. Уже давно большая часть всего ток там и делается) Так что Вы рано сдаетесь. Если я праивльно прикинул, что скорость Вашего варианта, что скорость утилиты из комплекта DS, примерно одинаковы) Может дело реализации в KOS? у японца то похоже совсем самописаня. Протестите, будет ли результат лучше чем у Вас http://www.theisozone.com/downloads/drea...by-jj1dom/ тогда точно будет видно в карту упирается или в реализацию

[megavolt85]

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 сохранить введённый текст в переменную?

[SWAT]

Да я думаю еще флешка косячит, надо бы другую попробовать. У меня тоже есть флешки, которые работают примерно на такой же скорости.
А вот с DMA cybdyn верно сказал, сам по себе он скорости не прибавит, а вот если пустить его в параллель записи на флешку, тогда будет толк. А то у тебя простаивает проц пока ждет DMA, а ведь в этом то и вся его суть, чтобы разгрузить проц на другие задачи, пока данные передаются.
Но эта задача уже не совсем простая, тут без тредов и их синхронизации не обойтись.

В DS есть команда для тестирования скорости, попробуй:

Код:

speedtest /sd/file.bin
speedtest /sd/file.bin

Именно 2 раза, первый раз она файл создаст и протестирует запись, второй раз, файл уже существует, а значит будет тестироваться чтение.
В RC1 она правда с косячком, но в целом измерению он не мешает. В RC2 я ее подправил и улучшил немного.

[SWAT]

(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, логику приложения можно так же в модуле и написать.

[megavolt85]

я консольную утилиту написал, а теперь костыль прикручиваю в виде GUI.
доберусь до модулей, перепишу код. Мне так проще си изучать

SWAT писал(а):В DS есть команда для тестирования скорости

Про тест скорости я в курсе и судя по нему скорость рипа должна быть в 2,5 раза выше

[SWAT]

Тебе не переписывать надо будет, а просто дописать недостающий модульный код.
А по поводу теста скорости, покажи результаты плиз.

[megavolt85]

Код:

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 Kb

[SWAT]

Ну результаты как минимум не выдающиеся.
Показывай код свой.

[megavolt85]

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 не будут писаться
Сижу вникаю как использовать треды.

[SWAT]

Для DMA нужно чтобы буфер был в no cache area, иначе есть шанс словить косяка в данных.
Вот кусок из 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кб на сколько я помню на тред), лучше динамически память выделять в таких случаях.
Я думаю что он не спроста такое количество считывает за раз, попробуй и ты.

[megavolt85]

Приму к сведению, но без тредов я вижу не обойтись, если хочется выжать максимум. У меня в голове уже крутится одна идейка как это всё организовать

[cybdyn]

может как вариант с применение прерываний, смотря что проще.
в тредах вроде надо заводить мъютексы или чтото подобное для синхронизации

вообщемто можно проще, отправляем команду читать данные по дма. первый раз ждём флага о завершнии дма.
далее перед тем как писать эти данные на карту, отправляем команду приводу на считывание следующей порции данных. и к мемонту завершения записи первой порции думаю что дма от второй порции уже завершится, проверяем это и опять считываем след порцию c диска, и пишем вторую порцию.... и так в цикле.
т.е. пока пишем готовую порцию - параллельно будет считываться следующая...
и не надо потоков и т.д
дPугой вопрос правильно инициализировать команда чтобы по дма считывалось...

[megavolt85]

Прерывания не дадут максимальной скорости, а второй вариант я как раз и хочу организовать, только

Цитата:пока пишем готовую порцию - параллельно будет считываться следующая...

для этого нужен отдельный поток, иначе программа будет ждать завершения считывания (или я не правильно понимаю смысл одно/много поточных приложений?)

[cybdyn]

а что треты (или потоки как я понял,)) ) не по прерываниям чтоли переключаются))? , вроде используется таймер? или есть у проца спец возможность переключать?

я выше описал способ - по сути чтение с привода какбы происходит без участия проца в то время пока пишем в карту, и как бы и не нужны ни треты, ни прерывания
а треты - тут палка о двух концах, переключение потоков будет постоянно рвать передачу в карту, ну если там как то с приоритетами поработать может картина измениться... треты применяют в какихнить многозадачных системах, когда разные приложния параллельно запускаются.

[megavolt85]

треты это потоки, они не переключаются, а выполняются паралельно, без них не проиграть видеоролик со звуком (в одном потоке выводим картинку в другом звук, а основная программа обрабатывает пользовательский ввод) ни написать игру. рассмотрим на примере игры, в игре должен быть поток для вывода графики, поток для вывода звука, поток для обработки команд пользователя и т.д. допустим у нас стрелялка и мы сделали три выстрела, для каждого летящего патрона программа создаст отдельный поток

[MetalliC]

ничего там параллельно не выполняется.
заведен таймер, скажем на 1/1000 секунды, на котором висит шедулер потоков, и который крутит их как карусель, один-другой-третий и тд, каждый по чайной ложке кванта времени (1/1000с в нашем примере).
так все ядра операционок пашут, и ессно есть эффектики которые cybdyn описал.

[megavolt85]

MetalliC писал(а):ничего там параллельно не выполняется.

имелось ввиду в рамках одной программы. вызвав функцию программа будет ожидать завершения работы этой функции, затем продолжит свое выполнение, в случае с потоком ,основная программа выполняется параллельно с программой в созданном потоке, а за тем как проц исполняет код в каждом потоке и с какой периодичностью их переключает нас не волнует, это задача ядра. По поводу глюков при использовании потоков, тут уже всё зависит от того, как реализована много-поточность в ядре. Откройте диспетчер задач и посмотрите сколько там процессов запущенно, условно возьмём что каждый процесс это один поток, но как ни странно и музыка в наушниках играет и торент качается и буквы на форуме читаются, причем всё одновременно и ничего не побилось ,а потоков в диспетчере мы насчитали не один и даже не тридцать

P.S. совсем забыл, предположим что у нас есть устройство способное принимать данные быстрее чем может отдать GD-Rom и есть два диска (CD-Rom и GD-Rom) с одинаковыми по объёму дорожками с данными, при этом GD диск спишется быстрее чем CD. GD-ROM работает в режиме CAV (постоянная угловая скорость) поэтому, чем ближе данные к концу диска, тем выше скорость их чтения. Отсюда вопрос, какая же средняя скорость чтения штамповки, может один мегабит при текущей реализации программы это нормально, а максимум можно будет выжать два мегабита?

[SWAT]

К слову о тредах. Я совсем забыл тебе подсказать еще одну оптимизацию.
Дело в том, что в DS видео рендеринг находится в отдельном потоке, поэтому имеет смысл его заблокировать на время записи данных на SD. Или вообще на весь процесс, но тогда все на экране замерзнет конечно.

PHP код:

LockVideo();
// write to SD
UnLockVideo(); 


В KOS контекст для тредов переключается с частотой в 100Hz.
Тебе чтобы реализовать такую асинхронную работу, для начала нужно написать свою функцию для чтения секторов, которая будет работать асинхронно, а не ждать результата. А сам результат будешь отлавливать на прерывании.

[cybdyn]

если треты исполняются на одном проце (ядре) то параллельно тут ничего не работает - а каждый поток исполняется процем в выделенный квант времени - или время до переключения на др. поток.
идея потоков тут сводиться к некой псевдо-параллельности,
есть понятия "приоритетности", не знаю точно есть ли возможно выделить этих квантов больше чем 1 , или как то увеличить время смены, т.е если поток по карте то естесно ему нужно больше времни

так же потоки выполняют полезную функцию арбитража доступа разных процессов к одноу источнику данных. например в игре надо с диска считывть с одного места видео, с другого аудио, в некий момент, надо текст подгрузить, 3д модели обновить. в потоках поэтому можно каждому процессу выделить время чтобы тот прочитал порцию данных и далее передать привод другому потоку. и так по очереди. опять же учитывая приоритеты))) например аудио чтобы работало без пауз