Jump to content

    

VslavX

Свой
  • Content Count

    1046
  • Joined

  • Last visited

Posts posted by VslavX


  1. ИМХО, самое правильное - сделать составное устройство MSD + HID. И кнопку опрашивать через HID.

    Еще можно сделать просто MSD и такие варианты опроса кнопки:

    - через Vendor команды USB (вероятно прийдется драйвер писать)

    - через Vendor команды SCSI (вероятно подойдет библиготека ASPI)

     

  2. у вас пример MEM2MCI. Покажите плз еще обратно.

    //
    // Запрещаем и подготавливаем канал 1 модуля GP DMA
    //
    DMA_CH1_CFG	= 0;
    DMA_INT_TC_CLR	= bDMA_TC_INT1;
    DMA_INT_ERR_CLR = bDMA_ERR_INT1;
    DMA_CH1_SRC	= (DWORD)&MCI_FIFO[0];
    DMA_CH1_DEST	= (DWORD)buf;
    DMA_CH1_LLI	= NULL;
    DMA_CH1_CTRL	= IO_SDMMC_BLOCK_SIZE/sizeof(DWORD)	// число не байтов
    		| bDMA_SBSIZE_8				// а трансферов
    		| bDMA_DBSIZE_8				// на стороне источника
    		| bDMA_SWIDTH_32
    		| bDMA_DWIDTH_32
    		| bDMA_DI	
    		| bDMA_I;
    

    Там то же самое. Причем работают как варианты с одиночным сектором, так и с непрерывным чтением.

     

    Специально сейчас после окончания транзакции распечатал DMA_CH1_CTRL - в поле счетчика светится 0, все данные корректно переданы в буфер. А то я уже сомневаться начал - с 1788 еще прикладники плотно не работали, может там ошибка. Но вроде нет, все нормально. Этот же код успешно работает на 2368/88.

  3. в памяти, куда был настроен DMA вижу весь свой сектор но кроме 32байт, и они лежат в фифо MCI

    и не понимаю почему они не забираются DMA

    Не сталкивался с таким, у меня на LPC1788 все работает, DMA настраиваю так:

    MCI_DATA_CTRL = 0;
    //
    // Запрещаем и подготавливаем канал 1 модуля GP DMA
    //
    DMA_CH1_CFG	= 0;
    DMA_INT_TC_CLR	= bDMA_TC_INT1;
    DMA_INT_ERR_CLR = bDMA_ERR_INT1;
    
    DMA_CH1_SRC	= (DWORD)buf;
    DMA_CH1_DEST	= (DWORD)&MCI_FIFO[0];
    DMA_CH1_LLI	= NULL;
    DMA_CH1_CTRL	= IO_SDMMC_BLOCK_SIZE/sizeof(DWORD)	// число не байтов
    		| bDMA_SBSIZE_8	// а трансферов
    		| bDMA_DBSIZE_8	// на стороне источника
    		| bDMA_SWIDTH_32
    		| bDMA_DWIDTH_32
    		| bDMA_SI	
    		| bDMA_I;
    

     

  4. Возможно они уже не выпускаются. Насчет signal integrity: получается, что TQFP корпус проца для signal integrity не помеха, а вот TSSOP корпус самой памяти - помеха. Я в этих вопросах плаваю, но "терзают смутные сомнения".

    А что, Вам известно много процессоров в TQFP с DDR контроллером? Я знаю только один - iMX233. А контроллеры/процесcоры с DDR2 в TQFP мне вообще не попадались. Навскидку - у планарных корпусов больше вариативность паразитных параметров пинов (и сами эти параметры хуже) и значительнее перекрестные помехи. На частотах DDR2 это уже начинает играть заметную роль.

    PS. Чтобы не оффтопить - вероятно у меня будет проект на F429. Как ирония - скорее всего в BGA :). Ждем соответствующий Дискавери.

  5. У ProMOS были такие. Кингстон тоже был, точно помню модуль DDR2 кинстоновский с TSOP чипами. А так - фиг его знает :)

    Маловероятно это. Корпус TSSOP уже не очень хорошо удовлетворяет требованиям signal integrity для DDR2, которые по стандарту работают от 200МГц.

    По крайней мере, мне DDR2 найти в TSSOP не удалось.

  6. с другими шинами SDRAM, когда у конкурентов есть DDRAM?

    Э-э-э-э... Я что-то пропустил? Это у кого есть флеш внутри + DDR SDRAM контроллер?

     

  7. Забавно..., конкурировать с китайцами по цене. :biggrin:

    Самое забавное бывает что конкурируем именно с понтоватыми китайцами, которые радостно BGA налепили :biggrin:.

    У них производство дешевое - думают что схемотехнику и софт можно не вылизывать. Ну-ну.

     

     

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

    Невысокие частоты это отнюдь не панацея. Низкоскоростные DDR чипы купить уже достаточно сложно, все больше DDR-400+ попадаются, с сответствующими скоростями нарастания. И "звенят" они отлично, данные не всегда "успокаиваются" и попадают в приемное окно даже на "низкой" частоте. Тут, правда, еще очень многое от контроллера памяти зависит, по какому принципу построен. Ну и если памяти всего один чип, и все линии точка-точка - то да, можно "проскочить". А потом заказчик захочет DIMM и тут - опа, сюрприз :biggrin:.

    Это элементарная операция.

    Операция элементарная, только платы на заводе все равно с контролем заказывать надо. "А фоторужье он денег стоит" (с).

    В моей области приходится конкурировать в том числе с китайцами, цена очень критична. Поэтому для меня применить BGA в проекте из основной линейки при наличии достаточной TQFP альтернативы значит банально понтануться. Ага, за свои деньги.

  9. Ну и самое главное К70 BGA

    Да, K70 - это уже другой класс. BGA + DDR, это минимум 4-х слойка PCB, с 5-ым классом точности, да еще контроль импеданса желателен.

    А вот STM32F4xx и LPC1778/88 в TQFP с SDR при желании можно поднять на дешевой 2-х слойке (S3C44BOX я практически поднимал на 2-х слоях).

     

    По потреблению я не помню, Самсунг 2410@266 + SDR SDRAM@133 кушали достаточно скромно.

     

  10. Ну да, хочется 133 :), ну хотябы 100

    У близкого старичка-конкурента LPC1778/88 частота SDRAM_CLK до 80 МГц. Но при этом ядро работает до 120 МГц, и частота SDRAM от нее производная. Получаются частоты SDRAM/CPU или 80/80, или 60/120. А у F429 ядро до 180МГц, получится нормально - 84 МГц SDRAM и 168 МГц CPU.

    А вообще да, маловата частота. Древний Самсунг S3C2410A на 130 нм давал 133МГц на SDR SDRAM. А тут вроде 90 нм и всего 84.

  11. Не могли ли бы вы поделиться проектом? У меня, к сожалению сделать это не получилось.

    Порт "официальной" ветки и пример под stm32f4xx готовы, к сожалению, под IAR/GCC. Также внесена часть моих оптимизаций - которые вносятся без глубокого хирургического вмешательства. Осталось написать "сопроводиловку" и еще немного потестировать (там аж 8 вариантов компиляции нарисовалось) - и будет открыто.

  12. Очень интересно. Только я не понял, как читать осциллограммы:)

    Сейчас я убегаю, поэтому - по быстрому - фрагмент тестового кода:

     

    #define TST_CONTEXT_STACK_SIZE  128
    
    volatile BOOL tst_context_exit;
    BYTE use_fpu;
    
    void tst_context_task_func(void *param)
    {
       PTN_SEM sem;
    
       //
       // tst_printf("\r\nTest task started...\f");
       //
       sem = (PTN_SEM) param;
       for(;;)
       {
    #ifdef _TEST_CONTEXT_PIN_2
           IO_PORT_CLR(_TEST_CONTEXT_PIN_2);
    #endif
           tn_sem_acquire (sem, TN_WAIT_INFINITE);
    #ifdef _TEST_CONTEXT_PIN_1
           IO_PORT_CLR(_TEST_CONTEXT_PIN_1);
    #endif
           if (tst_context_exit)
           {
               //
               // tst_printf("\r\nTest task completed...\f");
               //
               tn_task_exit(0, 0);
           }
    #if TN_SUPPORT_FPU
           if (use_fpu & 2)
           {
               fpu_touch();
           }
    #endif
       }
    }
    
    void io_test_context(void)
    {
       TN_SEM  test_switch_sem;
       TN_TCB  test_task_clear;
       PVOID   test_task_stack[TST_CONTEXT_STACK_SIZE];
       DWORD   lock;
    
       tst_printf("\r\nContext switch test...\f");
       tst_context_exit = FALSE;
    
       lock = hal_lock_interrupt();
       {
    #ifdef _TEST_CONTEXT_PIN_1
    #if HAL_IO_SET_MODE
           IO_SET_MODE(_TEST_CONTEXT_PIN_1);
    #else
           IO_PORT(_TEST_CONTEXT_PIN_1)->sFIO_DIR |= IO_MASK(_TEST_CONTEXT_PIN_1);
    #endif
    #endif
    #ifdef _TEST_CONTEXT_PIN_2
    #if HAL_IO_SET_MODE
           IO_SET_MODE(_TEST_CONTEXT_PIN_2);
    #else
           IO_PORT(_TEST_CONTEXT_PIN_2)->sFIO_DIR |= IO_MASK(_TEST_CONTEXT_PIN_2);
    #endif
    #endif
       }
       hal_unlock_interrupt(lock);
    
       tn_sem_create (&test_switch_sem, 1, 1);
       tn_task_create(
                   (TN_TCB*)&test_task_clear,
                   tst_context_task_func,
                   IO_PRIMARY_PRIORITY-4,
                   &(test_task_stack[TST_CONTEXT_STACK_SIZE-1]),
                   TST_CONTEXT_STACK_SIZE,
                   (PVOID)&test_switch_sem,
                   TN_TASK_START_ON_CREATION);
    
       for(;;)
       {
           tn_task_sleep(MS_TO_TICKS(1));
    #ifdef _TEST_CONTEXT_PIN_1
           IO_PORT_SET(_TEST_CONTEXT_PIN_1);
    #endif
           tn_sem_signal(&test_switch_sem);
    #ifdef _TEST_CONTEXT_PIN_2
           IO_PORT_SET(_TEST_CONTEXT_PIN_2);
    #endif
           if (tst_inkey() == 27)
           {
               tst_printf("\r\nStopping test task...\f");
               while(test_task_clear.task_state != TSK_STATE_DORMANT)
               {
                   tst_context_exit = TRUE;
                   tn_sem_signal(&test_switch_sem);
                   tn_task_sleep(MS_TO_TICKS(10));
               }
               tn_task_delete((TN_TCB*)&test_task_clear);
               tn_sem_delete(&test_switch_sem);
               tst_printf("\r\nTest completed...\f");
               return;
           }
    
    #if TN_SUPPORT_FPU
           if (use_fpu & 1)
           {
               fpu_touch();
           }
    #endif
       }
    }
    

     

    Вечером продолжу тестирование и буду уже смотреть официальную ветку, там тоже есть что обсудить.

    P.S. А префетч я отключал чтобы по-честному соревноваться с Вашими тестами scmRTOS - у Вас там ревизия проца старая :)

    P.P.S. Картинки уже устарели - есть круче :)

     

  13. Реализовал оба метода переключения контекста.

    Метод 1: использование автоматического "ленивого" сохранения контекста FPU в стеке, полностью аналогичен коду порта scmRTOS

    Метод 2: метод переключения контекста по требованию. Имеется системная переменная - указатель на TCB задачи, контекст которой загружен в данный момент в регистры FPU. При переключении задачи эта переменная сравнивается с TCB загружаемой задачи. При совпадении доступ к FPU разрешается через биты регистра CPACR, иначе доступ запрещен. Когда текущая задача, не владеющая контекстом FPU пытается выполнить плавучую операцию - происходит исключение, сохраняющее регистры FPU в TCB задачи-владельца, и загружающее нужный контекст текущей задачи.

    Предварительно потестировал оба метода.

    Для начала картинка GCC<->IAR без поддержки FPU

    post-10038-1361476238_thumb.png

    Мой взгляд, разницы принципиальной нет.

     

    Теперь картинка сравнения разных методов, для компилятора GCC.

    post-10038-1361476285_thumb.png

    FPU1 - метод 1

    FPU2 - метод 2

    none - ни одна из двух тестовых задач не обращается к FPU

    Task1 - только первая тестовая задач обращается к FPU

    Task2 - только вторая тестовая задач обращается к FPU

    Task12 - первая и вторая тестовая задачи обращаются к FPU

     

    Для метода 1 следует помнить, что FPCA бит в регистре CONTROL является sticky - то есть если задача хотя бы раз (возможно в далеком прошлом) обратилась к FPU и теперь про него вообще забыла - крайняя левая картинка уже использоваться не будет - работает одна из правых. С явным сбросом FPCA могут быть проблемы, так как компилятор может неявно использовать FPU даже в отсутствие операций с float/double.

     

    Для метода 2 есть недостаток - не поддерживается FPU в прерываниях/исключениях. В связи с этим для гарантии код операционной системы следует компилировать с оцпией -mfloat-abi=soft. А приложение и математические библиотеки с опцией softfp. Иначе оно не будет линковаться. На ассемблер разумеется никаких ограничений.

     

    Еще немного потестирую и буду прикручивать к официальной версии 2.6. Кстати, там видно что пооптимизировать, предложу модификации.

     

    Update: еще покрутил ассемблерный листинг - для метода 2 времянки еще улучшились немного. На крайней правой нижней картинке теперь общее время 3.73мкс. Можно еще уменьшить за счет удаления всяких проверок (типа не пришло ли исключение из режима обработчика), но это уже может сказаться на надежности.

     

    Update 2: у меня тут префетч из флеша в тесте выключался оказывается, почему то заметно влияло только на самую нижнуюю правую картинку - итого полное время 3,30 мкс для метода 2.

     

    Update 3: тестирование прошло удачно, обновил картинку с цифрами. Префетч включен

    post-10038-1361527578_thumb.png

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

    Основной анализ проделан в статье ARM на которую Вы уже давали ссылку. Там же оба подхода довольно подробно рассмотрены. Из дополнительных минусов второго ("переключение по требованию") я вижу невозможность (хотя, скорее громоздкость и неудобство) использования FPU в обработчиках прерываний/исключений. Зато снижается оверхед при переключении контекста и interrupt latency.

     

    Сценарий первый: ...

    ...

    Сценарий второй ...

    С анализом сценариев у меня туго :). На данный момент у меня такого рода задачи, что я вообще не понимаю зачем нужен FPU. Будучи студентом в университете приходилось заниматься численным моделированием плазмы. На Фортране-IV. На СМ-4. Предметом гордости было наличие блока FIS. Потом кафедра купила СМ-1420 с полноценным FPP - радости было. Но сейчас таких задач у меня нет - скрипач FPU не нужен. Поэтому мне сложно сказать какой сценарий более частый и предпочтительный, и планирую реализовать оба подхода, с выбором по флагу компиляции. Второй сценарий сделаю несколько упрощенным - для начала не буду заморачиваться с пулом, просто буду хранить контекст в TCB.

     

    Если кто-то реально использует (или только планирует использовать) FPU в своих приложениях - то было бы интересно узнать какой типовой способ использования в разрезе RTOS - сколько задач используют FPU, есть ли использование FPU в обработчиках прерываний и прочее.

     

    (если конечно все задачи вызовут tn_end_fpu()).

    ИМХО такая функция полезна при обоих подходах. Если пользователя заботит быстродействие то ему надо предоставить возможность такой настройки.

     

    Update:

    Вот такое "понравилось":

     

    "GNUC C compiler (gcc)

    If a program is compiled with the FPU option, gcc might make use of the floating-point registers

    if register pressure is high, and running low on available registers for data processing. In some

    cases, the memory copy might also utilize floating-point registers to hold data"

     

    Соглашение ABI при наличии FPU разрешает его почти произвольное использование - даже если нет работы с данными типа float/double, регистры FPU все равно могут использоваться компилятором, хотя бы в качестве быстрого хранилища переменных. Поэтому весь код обработчиков прерываний (включая системные функции типа tn_sem_isignal()) нужно компилировать с -mfloat-abi=soft. И библиотеки тоже с такой опцией. И, соответственно, приложение - иначе несовместимость линковки (хотя, проверю линковку "soft" и "softfp", есть шанс). И кому такое надо - вообще не моги пользовать FPU? Получается что второй подход для систем с отдельной линковкой приложения. Разрешить использование FPU в обработчиках можно, но для этого надо для каждого сделать отдельную функцию-переходник в котором явно запрещается FPU - чтобы FPU-код в обработчике вызвал исключение. И такой переходник скушает почти весь выигрыш в быстродействии :(

     

    Из компиляторов пока только Keil можно заставить не использовать FPU для "неплавучих" целей. GCC и IAR таких флажков не имеют.

  15. По теме переключения контекста FPU по требованию (по исключению) тоже хотелось бы услышать мнение All. После обдумывания мне кажется что хранить контекст FPU в стеке уже нельзя - иначе его будет невозможно восстановить по требованию (задача выполняется уже при произвольном стеке, и тут ей понадобился FPU - а стек-то уже тю-тю). Поэтому предлагается хранить контекст в блоке задчаи - TN_TCB. Но тут минус что контекст FPU большой - от 128 байт, и не каждая задача использует FPU - не всем оно надо. Поэтому предлагается завести пул блоков, для сохранения контекста. Когда задача начинает юзать FPU ей оттуда выделяется блок (ссылка храниться в TCB) и далее она пользуется блоком. При завершении задачи - блок возвращается. Таким образом пользователь может определить пул нужного размера - по числу задач работающих с FPU. Поддержку FPU в обработчиках прерываний/исключений думаю не реализовывать - код усложняется, скорость падает.

     

    P.S. А чем бы float/double на консоль выводить, а то мой самописный printf не поддерживает %f, %e, %a - наверное, пришло время добавить эту поддержку. Посмотрел реализации glibc - так там еще длинную арифметику надо. uglibc тоже не радужно. Может кто-то присоветует относительно более простое решение?

     

    Update: разобрался я с FPSCR, он автоматически в стеке сохраняется. При моем методе надо будет делать руками, главное - не забыть :)

     

  16. А вот с этим: arm-none-eabi кто нибудь, работал?

    Именно Линуксовая версия интересует? Я тестировал в этом топике версию с того же launchpad.net, но под Cygwin. Вроде же разницы на генерируемом выходном файле быть не должно?

     

  17. Выполнил черновой перенос существующего кода порта для Cortex-M3 (в который буду добавлять код для M4F) под GCC.Погонял тестовый код на Discovery STM32F4xx под IAR 5.41, IAR 6.40, GCC CodeSourcery (4.7.2 менторовский релиз 63) и упомянутый в этой ветке GNU Tools for ARM Embedded Processors.

     

    По компактности сгенерированного кода (в порядке от меньшего к боьшему размеру)

    - IAR 5.x - 11632

    - IAR 6.x - 13344

    - GCC CS - 13344

    - Toolchain - 14816

     

    По быстродействию (переключение контекста / Dhrystone, не особо показательно, разница маленькая):

    - IAR 6.x (0.920 мкс) - 246502 DS

    - IAR 5.x (1.080 мкс) - 246850 DS

    - GCC CS (1.040 мкс) - 250490 DS

    - Toolchain (1.080 мкс) - 250936 DS

     

    Тест Dhrystone гонял, но он тоже не показателен - примерно 250000 у всех, +/- пару процентов. При модификации кода показатели меняются (видимо смещается как-то оно во флешке и начинает играть акселератор).

     

    Исходники компилируются обоими компиляторами GCC - CS/Toolchain, никаких уcловных веток между ними нет. Но мне пока CodeSourcery нравится больше - документация получше, код покомпактнее. И вроде бы поддерживает LTO, но ключики -flto компилятору и линкеру на результирующий файл влияния не оказали. Toolchain на -flto варнингует.

     

    В-общем, следующий шаг - уже буду собственно плавучку прикручивать, тут CodeSourcery в бесплатной редакции Lite может подбросить фокусов - вроде там были искусственные ограничения на hard-FPU. Буду разбираться дальше.

  18. Благодарю за инициативу! Надеюсь, что это не сильно будет Вас напрягать. Вы написали, что планируете прикрутить порт к оф релизу. Насколько я знаю, у Вас есть и собственные наработки для TNKernel(доделки, переделки оф релиза). Можно узнать в чем они заключаются, какие достоинства(недостатки) и, если возможно, посмотреть на исходники Вашей модификации.

    Увы, но руководство пока против чтобы открывать полные исходники модификации. В субботу спрашивал (есть желание на SourceForge выложить улучшения и разные порты - ожидается для NIOS, и, возможно, для MIPS), но снова получил прямой запрет :(.

    Архитектурно отличается несильно - удалена таймерная задача (жалко дважды переключать контекст на каждый системный тик) - обработка перенесена в прерывание, с периодическим разрешением прерываний (чтобы не страдал реал-тайм), принципально выброшена часть "стремных" функций типа tn_task_terminate(). Оптимизирован (по аппаратуре вычислется вложенность) счетчик вложения прерываний, нет флагов запрета переключения контекста, часть функций работы со списками CDLL сделана макросами. Есть точный и грубый профайлеры, монитор системных объектов, синхронизированная отладка по JTAG/COM. Оптимизация по мьютексам вроде уже включена в v2.6. Возможно кое-что из остального тоже - я автору тексты отсылал. Посмотрю последний официальный релиз и если какие изменения я смогу быстро и прозрачно прикрутить к официальной ветке - выложу.

     

    P.S. Сейчас больно слезаю с IAR-а (имел глупость написать несовместимые хидеры с использованием фичи @ физический адрес). Потому как нет безглючной версии IAR для Cortex-M4 (все IAR 6.xx с какими-либо выбрыками), перехожу на CodeSourcery GCC. Заодно будут вкусняшки типа LTO и C++ 11-ый (это прикладникам).

     

     

  19. Вот помню в Borland-овской документации было написано, в каких регистрах что возвращается (тогда ещё не

    ...

    кроме честного слова за free software пока ничего не могу ответить...

    GCC следует стандартным соглашениям для архитектуры ARM, поэтому документацию надо смотреть на архитектуру. Упомянутый документ, раздел 5 "THE BASE PROCEDURE CALL STANDARD", там все подробно расписано - и про основные регистры, и про регистры FPU и про флаги.

     

     

  20. Не все регистры сохраняются. А с остальными (R4..R11) как быть - как обеспечить их сохранение? В gcc.

    Их сохранение должна обеспечить сама вызываемая процедура. То есть - если процедуре надо использовать какой-либо из регистров R4-R11, то она его сама предварительно сохраняет, пользует и потом восстанавливает. Регистры R0-R3 процедура может использовать на свое усмотрение, их сохранять от процедуры не требуется.

    Итого - произошло прерывание/исключение - флаги, R0-R3 и прочие сохранились, а остальные регистры R4-R11 вызванная процедура сама не разрушит.

    Кстати, это не только к GCC относится, но и ко всем компиляторам, которые следуют APCS - "Procedure Call Standard for the ARM® Architecture" - документ есть на сайте ARM.

     

     

  21. Update: Новые времена - новые контроллеры - новые времянки.

    На STM32F207 @ 120 MHz/3 waitstate - время переключения контекста 1.280 uS

    На STM32F407 @ 168 MHz/5 waitstate, ART prefetch ON, no FPU - время переключения контекста 0.904 uS

    Таки контроллеры становятся быстрее и быстрее :)

     

  22. Вячеслав предлагает более advanced решение, так что, IMHO, было бы лучше, если бы порт написал он..

    ОК, я постараюсь найти немножко времени чтобы сделать порт для STM32F4xx, особо он мне "прямо сейчас" не нужен, но тема мне просто интересная. Этапы я вижу тут такие:

    1. "освоить" STM32F4xx, написать плагин к своему отладчику-программатору, дополнить хидеры (на основе F2xx) и прочее

    2. сделать собственно порт в привычной наработанной среде

    3. "прикрутить" порт к официальному релизу (под GCC наверное)

    4. Потестить это все с "плавучкой" в многопоточке

    "Вечерами" тут работы на неделю-другую, постараюсь выкроить время.

     

    Update: сегодня получилось поработать - пункт 1 почти выполнен. Теперь умею читать-писать по JTAG процессоры F405/407/415/417/427/437 (ессно, проверил 407 только). Порт для Cortex-M3 спокойно завелся на STM32F407 (пока без FPU). Более того, на старте пошла та же самая бинарная прошивка что и на STM32F207. Поднял частоту до 168МГц (со 120 для F2xx), поигрался с временем переключение контекста (940 нс @168MHz ART prefetch выключен (имитация ревизии А), и 900нс при включенном prefecth ("полноценная" ревизия Z).

     

     

  23. У меня вопрос к разработчику ОС Юрию и всем, кто допиливал ось под себя(VslavX и т.д.), озвученный в названии темы. Будет ли такой порт? Планирую работать с STM32f4.

    Планируется ли дальнейшее развитие TNKernel?

    Если не предполагается использование FPU, то, имхо, должен подойти существующий порт от Cortex-М3.

    У меня на полке лежит нераспечатанный Discovery STM32F4 - никак руки не дойдут попробовать (работы всякой многовато). Очень надеюсь в ближайшее время таки до кита добраться и сделать порт с "честным многозадачным" использованием FPU - тут тема недалеко пробегала с интересной идейкой по переключению контекста FPU "по требованию". Мне будет несложно пропатчить основную ветку ОС самому (сделать и выложить пробный проект на упомянутый Discovery) или поделиться наработками с автором. Вопрос только - когда...