Колибри для встроенных систем?

Using Kolibri in embedded systems
  • не, ну это понятно, что строем все ходить не будут :)
    но, по-крайней мере, сказать, что "предпочтительней именно так-то" - неплохо было бы

    В общем, выкладываю commit - смотрите на стилистику. А переделать - мне и не лень
    Наверняка ошибки-то не все выкосил...

    2serge: извини, stdcall не получается как-то... взгляни на коды - ну криво он там сидеть будет
  • Да кстати этот пост тоже нах!
    Last edited by Mario on Tue Apr 07, 2009 4:45 pm, edited 2 times in total.
  • Основные мотивы: разборки с целью понимания происходящяго
    Попутно: оптимизация кодов по принципу: "если нет разницы, то зачем платить больше" (ну, собственно, и снял около 1К из 2-2.5)
    Естественно, проводилось устранение мелких и не значительных багов (например: "32-битное переполнение" на таймауте ожиданий, и при определении момента для "next_usage_update")
    Поскольку, возникли проблемы с "правильным ожиданием" event-ов, пришлось попутно "изобрести" эту технологию правильного ожидания

    На что, кстати говоря, и призываю коллег обратить внимание: ф-я Wait_events_ex из event.inc предназначена (собственно, она для этого и задумана) для замены всех call change_task в цикле. Да хоть бы и в том же wait_mutex...

    P.S. shed на предмет RT еще не правил. Это не сложно, НО, в моем понимании, для этого мне следует предварительно и серьезно разобраться с технологией прерываний и исключений.
    Чем и занимаюсь...

    P.P.S. Да вот, забыл... Изменения в checkidle не связаны логически с рефракторингом event.inc+shed.inc
    Они возникли как бы мимоходом, и сделаны "с листа". И впервые были предложены здесь

    P.P.P.S. Еще одна вещь...
    Да, все это писалось по принципу: "если нет разницы, то зачем платить больше"
    Т.е., если в коды и закралась бага, то ее устранение восстанавливает функциональную эквивалентность с предыдущими версиями, и проблем с совместимостью быть просто не должно
    Кроме одного момента :!:
    Последовательность приема событий в f10 / f11 / f23 - изменена на обратную
    Здесь, теоретически, возможны проблемы с совместимостью.
    Мне такие вещи пока не попадались...
    НО :idea: если у коллег возникнут непонятки с приемом событий в некой проге, то - от этого ли они возникли, можно легко проверить, вернув прямой порядок приема событий ((это достигается элементарной заменой bsr на bsf в event.inc#line=422))
    И потом уже думать, чего делать дальше... Больно уж не правильным мне представляется "прямой порядок". :(
    Опять же, события с "автосбросом" должны БЫ приниматься с более высоким приоритетом, чем требующие для этого сброса неких иных не тривиальных действий.
    Для IRQ я это обязательно сделаю, но чуток по-позже... И нечто похожее на систему обрисуется: старшие биты маски - с автосбросом (они же и принимаются в первую очередь), младшие (которых сегодня 3) - нет, и требуют специальных мероприятий для сброса.
    К этому моменту можно будет и sysfuncr.txt дополнить соответствующим образом...
  • Народ, выручайте...
    Не понимаю :!:
    А тестовый пример для проверки правильности показаний show_error_parameters при debug_exception и отсутствии самого отладчика - как-то сразу в голову и не приходит...
    Вот: debug.inc#line=438

    Code: Select all

    ; not debuggee => say error and terminate
            add     esp, 0x20+4 ; <----- ??????
            mov     [error_interrupt], 1
            call    show_error_parameters
    
    Мне здесь, главное - знать степень своей тупости.
    Если же я таки прав, и это просто бага, то вопрос - снят. Сам поправлю...
    Все одно, это дело надо объединять с совершенно аналогичным в sys32.inc
  • Нах этот пост!
    Last edited by Mario on Tue Apr 07, 2009 4:42 pm, edited 1 time in total.
  • Четверка не напрягает, она понятна: есть pushd - есть 4-ка, нет (что легко достижимо) - нету и 4-ки
    Напрягает именно 20-ка (в смысле 32), и именно в сравнениии с sys32.inc

    Пока подозреваю, что это бага, на которую в здравом уме наступить крайне затруднительно....
  • И этот нах!
    Last edited by Mario on Tue Apr 07, 2009 4:43 pm, edited 1 time in total.
  • А этот сам Бог велел нах!
    Last edited by Mario on Tue Apr 07, 2009 4:43 pm, edited 1 time in total.
  • Вьюноша, позволю себе открыть Вам великую тайну.

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

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

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

    Ну например...
    Сейчас два хука исключений вынесены в одно понятное и, как мне кажется, правильное место.
    Можно было бы обсудить расширения этих хуков на другие типы исключений - 0, 3, 4, 5...
    И как это сделать, чтобы не иметь проблем с совместимостью...
    Вот это была бы помощь
    А вовсе не вещание с броневичка прописных истин с видом Великого Гуру :wink:
  • Начиная с #1055 перестал работать звук в Doom. Жалуется на event code = 0 a должно быть 0xFF000001. И событие сигнализируется только один раз.
  • serge, поподробнее пожалуйста
    event code, это EVENT.code, или что-то другое :?:
    Если это, то зона узкая, будем внимательно сравнивать кода на предмет эквивалентности......

    И еще, я пока вообще плохо себе представляю как работет dosbox (речь о нем ???), средства v86 вроде никуда и не экспортируется....
    А в v86 тоже есть одна заморочка, связанная с вызовом do_change_task... Типа было не правильно, осталось не правильно (но чуток по-другому), да и вообще, само использование do_change_task кем ни попадя - уже само по себе не правильно...

    serge, расскажите все что знаете, что-бы хоть определиться с направлением раскопок
  • Я про портированный Дум. Исходники на свн а на фтп готовый exe-шник. Тестить удобно в VirualBox с драйвером sb16.

    Это код

    Code: Select all

    typedef struct
    {
      unsigned int  code;
      unsigned int  sender;
      unsigned int  stream;
      unsigned int  offset;
      unsigned int  size;
      unsigned int  unused;
    }SND_EVENT;
    
    SND_EVENT evnt;
    
            GetNotify(&evnt);  // 68.14
            
            if(evnt.code != 0xFF000001)
            {
                printf("invalid event code %d\n\r", evnt.code);
                continue;
            }
    
            if(evnt.stream != hBuff)
            {
                printf("invalid stream %x hBuff= %x\n\r",
                        evnt.stream, hBuff);
                continue;
            }; 
  • serge, ты меня совсем запутал :)

    Ей богу, я никогда не играл в Doom (ну случилась такая беда), и даже не знаю ДОС-вская это фича, или виндячая.
    Чисто для интереса - что такое портированный, кем портированный....

    Далее, ищу, что же такое sb16
    Нахожу у тебя, в Kolibri_pe
    Обнаруживаю, что экспортные имена ядра "немного другие"
    А ведь я, честно-благородно, поискал в репозитории использование имен create_event, raise_event, wait_event, destroy_event, clear_event, send_event - и не найдя, успокоился.
    И воспользовался твоим советом про "второе счастье", меняя интерфейс под себя.
    Ну типа подумал, что это дело For Further Features

    Пытаюсь искать "правильные" имена в твоей папке Driver
    В sb16.asm - не нахожу, но нахожу в infinity.asm, и mixer.asm
    Ну да, интерфейсы для CreateEvent и RaiseEvent - не состыкованы
    Ощущение такое, что CreateEvent и со старым (до меня) не очень стыкуется...

    Дальше, я не очень понимаю, как это дело с интерферировало с "штатными кодами".
    Тут я упустил какой-то момент. Колелги, растолкуйте мне этот механизм, пожалуйста...

    Да, и еще один момент... Я же увеличил длину поля code.
    Может это неправильно :?:
    serge, ведь в приведенном Вами коде уже возможен криминал (запись ЗА пределы SND_EVENT)
    Ну давайте подумаем, как надо делать правильно....
    А пофиксить под договоренность - минутное дело
  • Galkov wrote:Дальше, я не очень понимаю, как это дело с интерферировало с "штатными кодами"
    Все, доехало... Во балбес :wink:
    Плохой моя охотник, однако :)
  • Who is online

    Users browsing this forum: No registered users and 8 guests