TNKernel, пара вопросов автору Опции

[DASM]

Неудобно писать в личку, надеюсь коллеги меня простят. Юрий, хочу выразить благодарность за TNKernel, недавно начал пользовать, очень удобно, все нравится. Но возникли пара вопросов.. Первый такой - в tn_event_clear маской задается именно флаги которые НЕ надо очищать. Это вызвано какими-то особыми соображениями или это кажется нелогичным только мне ?
А второй такой. Очень удобно для синхронизации двух потоков использовать tn_queue_send/receive. Часто параметр data_ptr просто не нужен. Однако если send позволяет использовать NULL, то receive - нет. По-моему тоже нелогично. Или я не прав ? Конечно, все это можно поправить "для себя"... но я пока особого опыта работы со встроенными операционками не имею, только с виндой немного, поэтому и спрашиваю. Заранее спасибо !

[Alex B._]

хоть и не автор, но отвечу

>> Первый такой - в tn_event_clear маской задается именно флаги
>> которые НЕ надо очищать. Это вызвано какими-то особыми
>> соображениями или это кажется нелогичным только мне ?

я думаю особых соображений там нет:

Код

TN_RETVAL tnec_event_clear (TN_EVENT_S *evf, TN_UWORD pattern)
{
    /* ...код... */

    tn_disable_interrupt();

    evf->pattern &= pattern;    /* Clear event pattern */

    tn_enable_interrupt();
    return TERR_NO_ERR;
}

мне это вобщем тоже показалось нелогичным, но когда портировал на PIC24, просто решил не менять API
По поводу очередей - в принципе тоже реализуемо - закомментировть проверку указателя на NULL в tn_queue_receive() и dque_fifo_read() и соответственно не сохранять указатель из FIFO по указателю в NULL.

Дмитрий сам же наверное уже все посмотрел =) Вот честно, по времени больше думал, стоит ли так сильно коцать исходники, чем собственно портировал. Решил что стоит =) http://www.pic24.ru/tnkernel.htm

[spf]

Вот честно, по времени больше думал, стоит ли так сильно коцать исходники, чем собственно портировал. Решил что стоит =)

ИМХО:
Это не порт, а отдельная ветка, причем не совместимая по структуре и API -- эксклюзив, можно и имя поменять --TNKernel-PIC24
- если что-то будет изменено в настоящем ядре TNKernel -- придется ветку снова перепахивать руками
- если в системе есть что-то не на PIC24(а на ARM), то придется сопровождать ДВЕ операционки... да и не будет никто такого делать, зачем такая операционка, которая на каждое семейство имеет самостоятельную реализацию...

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

[zltigo]

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

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