Jump to content

    

VslavX

Свой
  • Content Count

    1083
  • Joined

  • Last visited

Everything posted by VslavX


  1. Цитата(тау @ Jan 29 2013, 11:57) бывает надо 2000 мкф с требуемым током пульсаций (для обеспечения времени наработки) . Угу, именно так. Смотреть понятие "ripple current" - ток пульсаций. У конденсаторов одинаковой емкости ток пульсации обычно тем выше чем выше пороговое напряжение. Если при работе схемы ток превышает допустимое значение, то срок службы конденсатора сокращается.
  2. Цитата(_Vova @ Jan 21 2013, 07:35) преимущественно по конструктивным причинам, возник вопрос: возможно ли разнести PHY (DP83848) и МК (STM32F4xx) на отдельные платы и соединить их шлейфом типа IDC длиной 10-15см ? интерфей RMII, осцилятор возле трансивера. У меня был проект где LPC17xx и KSZ8031 стояли на разных платах. Серийно опциональный модуль с Ethernet одевался на основную плуту сразу мезонином, без шлейфа. В процессе отладки сетевой модуль подключался также на IDC шлейфе примерно 30см, все работало. Но - если нужна будет сертификация на ЭМС - с таким колхозом не проходибельно.
  3. В стандартном USB-профиле принтера ничего сложного нет - посмотрите описание соответствующего класса, там всего десяток страниц. Если есть опыт работы с USB-device то за несколько дней делается (и это проверено практически). Опять таки, если используется стандартный профиль, то статусы все четко прописаны, проблем имитировать быть не должно. Так как разбирать записываемы поток не нужно (тупо пишем в файл), то при наличии готовых стеков девайса и хоста, а также освоенной файловой системы работы тут максимум на две недели.
  4. Цитата(VCO @ Dec 24 2012, 09:07) Отож! Насчёт "шачек или ехать" скажу, что это не к месту было сказано: Как раз поедет со 100%-ной уверенностью тот, кто мусор не будет покупать, а у БУшников может возникнуть проблема не только с работоспособностью, но и с поверкой. А остановка производства или штрафной иск за сорванный заказ может свести в минус всю эту экономию. Отакто! Про производство все понятно - будет нужно, то контора все купит новое. А для домашнего применения/фриланса - б/у вполне допустимо. Вот у меня основная работа (которая приносит основной доход) не сильно интересная в творческом плане - аппаратура простая, и относительно много программирования, а хочется поработать и со скоростными интерфейсами, и FPGA и прочее. Поэтому иногда берусь за фриланс, сложность которого на порядок превышает типовые проекты на основной работе. И тут б/у скоп с гигагерцовой полосой и 10гспс за умеренные деньги как раз в теме - и побаловаться скоростными цепями можно овцы целы, и жена не убьет увидев банковскую выписку волки сыты, и просто приятно поработать с мощным прибором пастуху вечная память.
  5. Цитата(VCO @ Dec 21 2012, 08:39) Именно поэтому привык покупать всё новое, от Ригола до квартиры. Не вопрос, Ригол или квартиру можно позволить новыми купить. Но хороший современный скоп (с параметрами на порядок превышающими Ригол) - он новым как квартира стоит. А посмотреть хоть одним глазком на SAS/SATA-2/3, USB-2/3 или PCIe хочется. Поэтому покупка б/ушного скопа с дискретизацией 8-10гспс и 1-10Мбайт сегментированной памяти по несильно отличающейся от нового Ригола цене - вполне себе вариант. "Вам шашечки или ехать?" ©
  6. FT2232h mini module

    Цитата(Onyks @ Dec 16 2012, 10:16) В итоге, взял другой usb-кабель, подключил модуль к USB порту, запустил FTprog. После сканирования была найдена FT4232Н, отцепил модуль Нужно еще питание на VIO подать - оно запитывает EEPROM в том числе. Документация говорит что нужно ДВА соединения: The FT2232H Mini Module allows configuration with both USB Bus-powered and USB Self-powered designs: USB Bus-powered: 1) Connect VBUS to VCC (CN3, pin 1 to CN3, pin 3). This connection takes the power from the USB bus (VBUS) and connects it to the voltage regulator input on the FT2232H Mini Module. The voltage regulator, in turn, provides V3V3, VPLL and VUSB power inputs to the FT2232H chip. 2) Connect V3V3 to VIO (CN2, pins 1, 3 & 5 to CN2, pins 11 & 21 and CN3, pins 12 & 22). This connection provides the correct 3.3VDC operating voltage for VCCIO on the FT2232H chip.
  7. Цитата(Sergey_Bekrenyov @ Dec 18 2012, 15:03) Этот "косяк" называется 2 чипа подключенных на один контроллер. Два чипа можно подключить же по-разному. Например два 16-битных чипа в двух разных банках (chip-select имею ввиду разные) на 16-битной шине - это уже не соединение типа "точка-точка", потому что на каждой линии данных уже будет три пина. А если из двух 16-разрядных чипов набрать 32-разрядную шину, то на каждой линии данных будет два пина - контроллера и одного из чипов памяти. Это уже точка-точка. К скоростям и выравниваниям чувствительны именно клоки и шины данных, остальные сигналы значительно менее проблемные, к тому же можно обычно применить режим 2T, если все совсем уж плохо. Ну и чисто проблемы Альтеры бывают.
  8. Цитата(juvf @ Dec 15 2012, 08:39) Ну вот не заметили. Вообще в нашей канторе это был первый опыт с DDR. И ни кого рядом, кто уже её щюпал. Моделировали так, что на конце линии есть терминация 50 Ом. Это как? Дорисовали на схеме в HL резистор? Так схему моделировали или реально оттрасированную плату? Цитата(juvf @ Dec 15 2012, 08:39) А как можно было на этапе моделирования понять, что в циклоне3 нет ODT? Немного доки недокурили по работе ддр и про ODT в циклоне3. Так модель пинов в HL подключается. И там выбирается режим работы пина - один из описанных в файле модели. Если нужный режим (с включенным ODT) в списке не найден (поскольку не поддерживается), то это уже был повод задуматься - а шо ж не так. И еще мне странно немного - на коротких линиях (1 дюйм) шина данных в топологии точка-точка должна бы заработать и без терминации. Ну вероятно были бы overshoot/undershoot, но времянка должна быть OK. Есть же примеры успешных проектов, работающих без терминации. Так что весьма вероятно что у Вас на плате еще какие-то косяки есть.
  9. Оси

    Цитата(vshemm @ Dec 11 2012, 21:52) [2] http://arxiv.org/pdf/1211.6185.pdf Спасибо за статью. Очень интересно почитать было, еще буду разбирать-обдумывать методику верификации (кажется там есть новые для меня идеи), потому что использую описанную технологию активных драйверов (думаю ее много кто использует - идея-то "на поверхности") - именно обработка всего доступа к аппаратуре в едином потоке, и единая точка разбора входящих событий, с перекрестной верификацией (при помощи встроенных ASSERT-ов) начального и конечного состояния внутреннего автомата. Это позволяет не парится вообще о синхронизации многопоточного доступа к ресурсам - из кода уходят все эти критические секции, и код становится более быстрым и читаемым. Мейлбоксы как-то не расплодились - использую очереди, часто нативные (встроенные в данные, например в поля буфера сетевых пакетов) и единый семафор/масочное событие для модуля. Причем такой подход отлично работает не только в драйверах. Жаль подобной статьи не попалось ранее - избавило бы от многих мук выбора драйверной модели. Данные про сравнительную производительность немного удивили - утилизация CPU выше (это понятно), но и пропускная способность выше (это странно немного - предполагал что производительность как раз страдает, готовлюсь к кое-какому рефакторингу)
  10. Оси

    Цитата(AlexandrY @ Dec 11 2012, 11:49) Нынче не разберешь из чего они выполняются. Понаставили всяких акселераторов, промежуточных FIFO, кэшей. Хуже того, теперь даже шинные матрицы могут сбоить и объявлять о своих ошибках причем разных. И что с такими ошибками делать? Еще не видел RTOS которые бы что-то с этим делали. В лучшем случае когда все пойдет в разнос удалят задачу. По возможности записать лог и выполнить рестарт - что тут сделаешь кроме BSOD? И такие ошибки - они ведь не от типа софта зависят, линейный монопоточный код с ними тоже что-то был бы вынужден делать? Цитата(AlexandrY @ Dec 11 2012, 11:49) Проще использовать линейный код без переключений контекстов, динамических ссылок и HAL уровня и статический анализаторы кода с трассером и все тотально прошерстить. Проще в плане достижения реальной надежности. Проще-то оно проще. И такой простой подход получается применять пока программы несильно сложнее уровня "Hello, world" пишутся. А потом, по мере усложнения программы начинаешь понимать, что HAL-уровень не просто так появился, и таки суперлуп себя изживает. Вот у нас софт для основной линейки продуктов развивался так: - 1992.. - линейный код, чистый ассемблер x86, примерно 16к кода - 1995.. - линейный код, некоторые протоколы в фоне на прерываниях, все еще ассемблер x86, 32-64К кода - 1996.. - ассемблер частично помирает, фоновые прерывания, 50+ процентов C - 1997.. - первое портирование на другой контроллер (первые Мега103), доля C неудержимо растет - 2000.. - уже есть опыт с Win32, хочется и на встраиваемой платформе такое поиметь, но ресурсов нету, суперлуп становится очень сложным и достаточно глючным, протоколы в фоне на прерываниях тоже плодятся, поддерживать с адекватным качеством становится не совсем просто - 2006.. - появились 32-битники с ресурсами, с ценой которую уже можно иногда позволить, изучается вопрос RTOS, начинается разработка своей вытесняющей платформы. - 2009.. - окончательный перевод всего кода аппаратной поддержки на RTOS. Ассемблер почти умер - десятые доли процента, исключая криптографию, разнообразные успешные порты на различные аппаратные платформы - 2013..?? - перевод основного приложения на платформу RTOS. Ага, суперлуп до сих пор жив в основном коде приложения, но он на сегодня глючит и создает больше проблем чем RTOS-платформа. Это я называю - "загибается". Ну не получается весь этот разросшийся за два десятилетия функционал простым циклом нормально обработать. Сейчас изделие обрабатывает и обращения по разным протоколам, и различную периферию с кучкой протоколов, и оператор бывает с ним работает, и сетевые обращения, и веб-сервер, и по USB-MSD иногда могут данные забирать. И всем этим все еще пытается рулить суперлуп. Не, оно-то все крутится в "фоне", в своих задачах, но суперлуп с трудом уже может хотя бы просто адекватно рулить всем этим через свои убогие монопоточные интерфейсы. В-общем, на сегодня я рассматриваю RTOS просто как не самый плохой способ модульной организации проекта. Не то чтобы очень уж хотелось ее применять, но жизнь (разрастание и повышающаяся сложность проектов) заставляет как-то организовываться. ИМХО, единственный относительно серьезный минус вытесняющей RTOS - она просит некоторые ресурсы - и память кода для размещения, и оперативную память для стеков. Все остальное вполне решаемо. Ну да, квалификация от системного/встраиваемого программиста требуется немного повыше чем для линейного "Hello, world", но не запредельная, да и расти профессионально всегда приятно. Проблема надежности у меня решается жестко - 10-15 процентов кода это ASSERT-ы. И надо сказать последние года три сработки ASSERT-ов меня вообще не беспокоят. Ну и байка напоследок - благодаря RTOS я познакомился со своей будущей женой Была некоторая физическая лаборатория, где сидела милая девочка-аспирантка и снимала параметры с экспериментальной установки. Лаборатория имела кое-какое финансирование, и прикупила одну из первых в университете IBM AT/286. Сначала девочка просто щелкала тумблерами на установке и вносила параметры в файл. Потом лаборатория прикупила нановольтметр с интерфейсом КОП (ака IEEE-488/GP-IB), и еще кое- какие КОП-онизированные приборы, ну и тут нарисовался я - молодой и красивый , с опытом разработки контроллера КОП для шины МПИ. Контроллер успешно был переработан для шины ISA, и написалась программа, которая сама щелкала тумблерами, снимала все параметры и писала в файл. Девочка была симпатичной, а тут еще и первая увиданная АТ-ишка с VGA-мониторчиком, и Wolf3D как раз появился. Ну глупо же было на целый рабочий день запускать экспериментальную программу (ну да, MS-DOS, и экспериментальный цикл непрерывный, с заливкой гелия и азота) и терять внимание девочки, и еще тратить время диковинного компьютера с цветным монитором. Поэтому был написан такой себе резидентный вытесняющий двухзадачный планировщик. Програмка вставала резидентно, и меряла себе там в фоне по-необходимости. Написана она была достаточно просто на Паскале, писалась моей будущей женой и ее коллегами, грузить их всякими системными тонкостями было неприлично, пришлось "брать удар на себя" - все хитрости делал именно планировшик, помнится он даже контекст FPU переключал. Ну и AT/286 освобождалась для запуска Wolf3D - это был отличный повод наведываться в ту лабораторию. В-общем, первый опыт применения RTOS у меня достаточно успешный - девочка вышла за меня замуж и защитила диссертацию. Так что RTOS-ы не столь уж опасны (хотя.. как посмотреть ).
  11. Цитата(iosifk @ Dec 10 2012, 14:55) 3. Фрискейл имеет ARM, но там 10/100... У фрискейла есть микросхемы с GМАС. но это довольно дорого... Если не ARM, то у Фрискейла есть вполне бюджетные MPC83xx - цена младших начинается от $9.5 в партиях 100 штук. И GMAC там неплохой - с TCP-offload и прочими плюшками.
  12. Оси

    Цитата(AlexandrY @ Dec 10 2012, 08:47) Скажем реальная ситуация. Промышленный агрегат тестируется на 10000 циклов рабочего хода более месяца. И всего за это время обнаруживается два сбоя, скажем непредвиденных остановки. Вы что, броситесь искать причину такого глюка? Отмените все испытания, начнете их заново? В реальной ситуации испытания, конечно, продолжатся (если разработчик не хочет потерять работу). Но, как появиться время/силы/возможности со сбоем надо будет разбираться. Мало-мальски сложный софт - он модульный. Причины модульности вполне прозаические: - снижается общая сложность проекта, до O*N, вместо O в степени. Отдельную часть проще разработать и поддерживать. - повторное использование кода в разных проектах. Модули надо разрабатывать по возможности универсальными, с четко прописанными интерфейсами, тогда их можно повторно использовать. Поэтому - если в проекте подозревается глюк, то его надо искать. С большой вероятностью глюк в универсальном модуле, если его не локализовать, то он будет расползаться по другим проектам. В-общем, проекты становятся все сложнее и сложнее, функций и кода становится на порядок-другой больше, все это надо структурировать тем или иным образом. ИМХО, структурные части желательно делать максимально независимыми, и поскольку при своем выполнении все эти модули требуют банально процессорного времени, то нужен механизм его распределения и тут (RT)OS-и неплохо себя показывают.
  13. ИМХО, можно взять практически любой одноядерный микропроцессор со встроенным Gigabit Ethernet MAC с частотой от 800МГц, и по TCP вполне реально отдать 60Мбайт/сек. Но не на Линуксе, скорее всего. У меня был проект на MPC8347@533MHz, получалось забирать с PСI 32@66MHz 250Мбайт/сек и медленно и печально отдавать примерно 50Мбайт/сек по TCP через гигабитный эзернет (ну там еще резервы оставались, с Джумбо-пакетами на wire-speed вышло бы), но это все с самописным софтом. Сейчас контроллеры попродвинутей есть - и частота больше, и MACи умеют TCP-offload делать, думаю можно что-то подобрать, может даже издержки Линукса вытянуть.
  14. У Вас стоит задача именно драйвер написать? Если просто подключить устройство к компьютеру с Windows то лучше воспользоваться одним из готовых классов. Если ни один из USB-классов не подходит, то можно пользовать WinUSB. Или реализовать сетевое подключение по RNDIS. Потому что чем "дальше в лес, тем толще партизаны" сложнее писать свои драйвера. Под Windows 8 уже поставить свои без цифровой подписи совсем сложно стало.
  15. Цитата(MrYuran @ Nov 26 2012, 12:12) Зависит от того, что вы делаете в прерываниях. Может оказаться, что и маловато. Для прерываний у Cortex-M3 есть свой отдельный стек, поэтому нет смысла резервировать место в стеках всех задач для обработчиков прерываний. У меня для задачи IDLE используется стек в 32 слова (128 байт), реально использовано 17 (для сохранения контекста). Это для TNKernel, не думаю что для FreeRTOS нужно принципиально больше (разве что они выполняют какие-то дополнительные вызовы фоновых функций в Idle, у меня же там тупо "wfi" и больше ничего)
  16. LPC vs STM32 cortex-M3

    Цитата(SasaVitebsk @ Nov 22 2012, 21:20) разработчики в него поверили, и готовы потратить значительное время... Это значит, что они признали, что этот продукт надолго ... В него стоит вкладываться. ИМХО, вкладываться надо не в конкретный продукт, а в повторное использование своего кода - нарабатывать кубики "софтового конструктора". Тогда будет почти все равно какой контроллер использовать. Например, в TCP/IP стеке, архитектурно-зависимая часть общая для, допустим, Cortex-M3, занимает менее 0,1 процента. Контроллерно-зависимая часть, допустим, для STM32F2xx занимает 2-3 процента. Аналогично для стека USB-device. Для USB-host цифры еще более незначительные. Поэтому при выборе контроллера LPC vs STM уже можно себе позволить посматривать на другие критерии, у меня основной - цена. STM32 на сегодня один из самых недорогих ARM7xxx/Cortex-M3. По сведениям наших снабженцев LPC17/23 значительно проигрывает (говорим про партии 10-20К штук). Ну а все остальные факторы уже вторичны (после 20 лет разработки столько всякого насмотришься) - документация, примеры, качество имеющегося софта.
  17. LPC vs STM32 cortex-M3

    Цитата(Flexz @ Nov 22 2012, 20:26) Плохой пример, SCSI_SenseCode не использует переменную lun плохой код - да, но еще не баг Согласен, не использует. Но все равно достаточно коряво и этот весь код к "многолуновому" варианту привести будет достаточно тяжко (а я как раз многолуновый пишу). А тут какая прелесть: CODEconst int8_t STORAGE_Inquirydata[] = {//36 /* LUN 0 */ 0x00, 0x80, 0x02, 0x02, (USBD_STD_INQUIRY_LENGTH - 5), 0x00, 0x00, 0x00, 'S', 'T', 'M', ' ', ' ', ' ', ' ', ' ', /* Manufacturer : 8 bytes */ 'P', 'r', 'o', 'd', 'u', 't', ' ', ' ', /* Product : 16 Bytes */ ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', '0', '.', '0' ,'1', /* Version : 4 Bytes */ }; Там разве не USBD_STD_INQUIRY_LENGTH - 4 должно быть согласно SCSI стандарта? А "Produt" - это новая торговая марка от STM? Оно вроде как и не фатально (работает же как-то), но достаточно неопрятно. Еще во многих местах смешивает уровни SCSI и BOT, например нужно phase error для BOT генерить, а оно ILLEGAL_REQUEST в sense data валит. Вот и получается, народ "мимодумно бросает апельсин в воду" (с) и потом начинаются крики - "процессор - фуфло, USB - очень ненадежный интерфейс".
  18. LPC vs STM32 cortex-M3

    Цитата(Max_Shaman @ Nov 22 2012, 15:15) привело к тому что я по сей день кроме блока GPIO пока ничего не использовал. Использовать программную поддержку эстеэмовского местного "Страуструпа" извините тоже не вариант, ничего универсального не бывает, банальные примеры Там не просто "труп страуса", там достаточно хорошо забагованный труп. Пишу сейчас свой MSD для UDEV (универсальный, ессно, от архитектуры не зависит - пойдет на любом процессоре). Подглядываю в файлы примера от STM, вот весьма милый кусочек: CODE if ((USBD_GetRxCount (pdev ,MSC_OUT_EP) != BOT_CBW_LENGTH) || (MSC_BOT_cbw.dSignature != BOT_CBW_SIGNATURE)|| (MSC_BOT_cbw.bLUN > 1) || (MSC_BOT_cbw.bCBLength < 1) || (MSC_BOT_cbw.bCBLength > 16)) { SCSI_SenseCode(MSC_BOT_cbw.bLUN, ILLEGAL_REQUEST, INVALID_CDB); MSC_BOT_Status = BOT_STATE_ERROR; MSC_BOT_Abort(pdev); } Проверяет поле MSC_BOT_cbw.bLUN, и если оно неверное то тут же использует его как аргумент SCSI_SenseCode() для записи статуса . И похожих косячков есть еще. Код взят из свежей "STM32F105/7xx, STM32F2xx and STM32F4xx USB Device Library".
  19. stm32f407 SPI обнаружил косяк

    Цитата(KnightIgor @ Nov 17 2012, 00:37) Поддерживаю. Для полнодуплексного (даже если только передача нужна) SPI завершение передачи нужно проверять по... RXNE (и забыть о TXE или BSY, т.к. STM32F не поддерживает аппаратное формирование SS в режиме мастера!). Тогда будет абсолютная уверенность, что байт ушел, а следующий его не затрет по пути: ведь пока байт выдвигается по MOSI, входящий байт вдвигается по MISO тем же тактовым сигналом. Это означает, что флаг RXNE все равно возникнет, пусть позже TXE, зато наверняка после последнего такта. Нужно помнить чистить RXNE путем чтения DR перед записью туда: Делал я так. Побочный эффект - обмен не непрерывный, между байтами пропуски получаются. При тактовой 15МГц, еле на 1МБайт/сек выходило. Пришлось сделать такой вариант: CODE IO_CALL_TYPE DWORD IO_CALL_OPTION io_at45_read(void) { PSTM_SPI pspi = _AT_SPI_; // // В целях сохранения быстродействия не производим проверку // синхроресурса в функциях самого нижнего уровня // // IO_ASSERT( at45_mutex.holder == tn_curr_run_task, "AT45 synch failure"); // for(;;) { DWORD stat; // // Значительно более быстрый вариант - ждать TXE и немедленно // запускать новый цикл на SPI если буфер передатчика готов // Иначе контроллер делает паузы между символами. Чтобы не // потерять принимаемый символ при вытеснении потока, запуск // осуществляем при запрещенных прерываниях // stat = pspi->sSPI_SR; if (stat & bSPI_TXE) { DWORD lock, ret; lock = hal_lock_interrupt(); pspi->sSPI_DR = 0xFF; for(;;) { // // Ждем завершения предыдущего цикла // и забираем принятые данные по готовности // if (stat & bSPI_RXNE) { ret = pspi->sSPI_DR; break; } stat = pspi->sSPI_SR; } hal_unlock_interrupt(lock); return ret & 0xFF; } } } Скорость выросла раза в 1.5, DMA не пробовал - не очень подходт для задачи.
  20. stm32f407 SPI обнаружил косяк

    Цитата(SasaVitebsk @ Nov 16 2012, 12:45) После записи в регистр DR необходимо выждать задержку до проверки флага BSY в регистре SR. Имхо, не BSY нужно проверять, а TXE. А SPI на STM32 кажется и правда слегка шизанутый, обмен стартует с задержкой после записи в DR если в текущий момент еще ничего не передавалось. Есть у меня подозрение что это схема аппаратного руления CS не до конца отключена и паузы вставляет.
  21. запрягаем хлопцы кони...

    Цитата(klen @ Nov 15 2012, 10:48) а мож у фпу есть какаюнибудь скрытая секретная шинка по которой сохраняется ... Маловероятно - FPU в ядре сидит, а внешние шины ядра документированы. Даже если оно теоретически ходит одновременно по S-bus и D-bus или даже "секретной шине", то это лишено смысла - замыкается-то оно все равно на один и тот же блок RAM (в котором стек сидит), будет арбитраж, выиграша никакого. Цитата(klen @ Nov 15 2012, 10:48) не нупые же в ARM инженеры сидят, экономить тут не начем было.. Ну как бы не тупые, для однопоточного приложения и совместного использования FPU в обработчиках прерываний вроде бы неплохо оно все заточено. И совместимость с кодом для М3 отличная, наверное это за главный критерий приняли. Но вот с вытесняющей RTOS не все так гладко, что и удивляет - использование RTOS для чипов подобного класса на сегодня мейнстрим, имхо.
  22. запрягаем хлопцы кони...

    Цитата(AHTOXA @ Nov 13 2012, 11:24) Пусть задача сбрасывает CONTROL.FPCA, если надобность в FPU отпала Ну да, бит можно сбросить, вариант. Цитата(AHTOXA @ Nov 13 2012, 11:24) Я всё равно не понял, как работает описанный вами механизм. Вот скажем, задачи 1 и 10 используют FPU, а задачи 2-9 - нет. После переключения с 1й на вторую задачу плавучий контекст не сохраняется, так? Потом при переключении со 2й на 3-ю, 3-4...4-9 - тоже не сохраняется. А при переключении с 9й на десятую надо сохранить. Как переключатель узнает, куда надо сохранять этот контекст? Заводится одна общесистемная переменная типа ptcb_fpu_context, которая указывает на TCB задачи, конекст FPU которой в данный момент загружен в физические регистры FPU. Когда эта задача вытесняется, то сохраняются только РОНы, и FPU запрещается, например битами в CPACR. Для новой вбрасываемой задачи загружаются только ее РОНы, FPU не трогается. Если новая задача не трогает FPU и потом возвращается к старой задаче - отлично, надо только разрешить снова FPU, а содержимое его регистров там и осталось нужное. А если эта новая задача (или еще более новая N-ая, которая ее вытеснит) начнет использовать FPU, то возникнет исключение UsageFault, обработчик посмотрит что ptask_fpu_context не соответствует tcb_current_task, сохранит регистры FPU согласно ptask_fpu_context, загрузит новый контекст из tcb_current_task, назначит новое значение ptask_fpu_context (задача-владелец FPU ведь поменялась), разрешит FPU в CPACR и продолжит исполнение с корректным контекстом FPU. Таким образом, фактически FPU-контекст переключается только при его совместном одновременном использовании несколькими задачами, и только тогда когда это реально нужно, а не тупо при каждом переключении задачи. Такой механизм реализован в x86 и в PowerPC, например. А для Cortex-M4F нужно вот CPACR руками рулить.
  23. запрягаем хлопцы кони...

    Цитата(AHTOXA @ Nov 13 2012, 09:46) а во-вторых наверное можно CONTROL.FPCA сбросить вручную, если уж известно, что не собирается дальше пользоваться Общесистемному переключателю контекста намерения задачи известны быть не могут. Это только сама задача знает, и нормальных средств запустить переключатель по требованию (как в x86 по исключению использования FPU с неактуальным контекстом) нету. Приходится гонять регистры s0-s31 всегда, при каждом переключении контекста. Цитата(AHTOXA @ Nov 13 2012, 09:46) Можно глянуть во FreeRtos. Глянул, все печально, как я и предполагал. Если процесс использовал FPU то при вытеснении s16-s31 сохраняются "ручками", вызывая неявное "ленивое" сохранение s0-s15. Если новый процесс использует FPU - то ему вгружают явно s16-s31 и неявно s0-s15 при выходе из исключения PendSV. Работать-то будет, но некрасиво и затратно.
  24. запрягаем хлопцы кони...

    Цитата(Allregia @ Nov 13 2012, 00:10) Програма без ОС, в основной программе тоже кое-где есть float, хотя и довольно редко. Нужно ли предпринимать какие-то шаги, для сохранения контекста FPU в прерываниях, или Keil с этим самостоятельно разберется и можно не переживать? Если без ОС, то должно нормально работать - для совместного использования FPU в обработчиках прерываний особых телодвижений от компилятора вроде не требуется.
  25. запрягаем хлопцы кони...

    Цитата(AHTOXA @ Nov 12 2012, 15:39) Вот специальная статья от ARM про это . Разочарование сплошное. Проблема давно изящно решена, например, в i80386-ом - при переключении контекста меняется содержимое только РОН-ов, FPU не трогается и взводится специальный флажок. Если в новом контексте начинает использоваться FPU и этот спецфлажок установлен, то генерируется исключение, обработчик которого выполнит отложенную смену контекста FPU - сохранит старый и загрузит новый. А тут - при переключении контекста задачи RTOS старшие регистры s16-s31 нужно сохранить ручками в любом случае, даже если задача последний раз пользовалась FPU полчаса назад и может больше и не собирается дальше пользоваться. И новый контекст не грузится автоматически при попытке использования - значит изволь для новой задачи его также ручками загрузить. Флажки-то в Cortex-M4F есть, но аппаратный способ смены контекста FPU "не доделан", а программного "по требованию", я так понял нету. ИМХО, на сегодняшний день такое решение для смены контекста FPU немного диковато, и не видится способа как эту "Lazy stacking feature" красиво встроить в переключатель контекста в RTOS. Или чего-то не так понял? Upd: ну слегка корявый способ нашелся - при переключении контекста запрещать использование FPU через биты 11/10 в CPACR. Тогда при попытке использования FPU в новом контексте вылезет исключение UsageFault и можно будет ситуацию разрулить. Но при этом использование "Lazy stacking feature" все равно сомнительно.