Cortex-M4(F) порт под GCC залит в репозиторий. Опции

[AHTOXA]

Всем привет!

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

Что касаемо скорости. Тестировал на stm32f4discovery, проц STM32F407 Rev A (То есть, не работает ART prefetch), частота 168 МГц.
Итак.

• Если два процесса не использовали FPU, то передача управления осуществляется за 900ns.
• Если один из двух процессов использовал FPU, то передача управления осуществляется за 1.1us.
• Если оба процесса использовали FPU, то передача управления осуществляется за 1.34us.

Красивая картинка:

К порту залиты примеры для STM32F4xx. Кроме стандартных четырёх примеров добавлен пятый - "5-FPU".
Он тестирует неизменность контекстов задач при выполнении действий с плавающей точкой.

Да, кстати. Этот порт подходит без изменений для M4F, M4 и M3. Так что, скорее всего, в дальнейшем развиваться будет именно он.


Забыл написать.
Краткая инструкция по скачиванию.

• Забираемся в папку, в которую мы хотим скачать примеры.
• Даём команду
  svn co https://scmrtos.svn.sourceforge.net/svnroot...F/GCC/STM32F4XX STM32F4XX
• Появляется папка STM32F4XX
• Заходим в неё, даём команду switch.bat (в линуксе - sh switch.sh)
• Всё.

[Pat]

Антон, Спасибо огромное.

[ReAl]

Собственно, новость указана в теме

«Кричат эмбеддеры „Ура!“ и в воздух чипчики бросают».

[spf]

Схемы доступа претерпели изменения, в текущий момент:

• svn checkout svn://svn.code.sf.net/p/scmrtos/code/ и т.д.

Смотреть на странице http://sourceforge.net/p/scmrtos/code/

[AHTOXA]

Добавлю сюда, пожалуй. Вот что я раскопал по поводу смены схемы доступа к svn.
Итак:

1. Сменился путь svn, был: http://scmrtos.svn.sourceforge.net/svnroot/scmrtos/ , стал: http://svn.code.sf.net/p/scmrtos/code/)
2. Доступ по https теперь требует авторизации.
3. Анонимный read-only доступ остался только по http (http://svn.code.sf.net/p/scmrtos/code/trunk) и svn (svn://svn.code.sf.net/p/scmrtos/code/trunk).
4. Новый адрес веб-интерфейса к svn: http://sourceforge.net/p/scmrtos/code/
   К сожалению, если забраться там поглубже, то в ссылке появляется номер ревизии: http://sourceforge.net/p/scmrtos/code/563/tree/trunk/ .
   Путём невероятного напряжения умственных сил я догадался, как получить ссылку на HEAD. Надо заменить номер ревизии на слово HEAD: http://sourceforge.net/p/scmrtos/code/HEAD/tree/trunk/

Таким образом, пример из моего первого сообщения теперь будет выглядеть так:

Код

svn co http://svn.code.sf.net/p/scmrtos/code/trunk/Samples/CortexM4F/GCC/STM32F4XX STM32F4XX

[mdmitry]

Добавлю сюда, пожалуй. Вот что я раскопал по поводу смены схемы доступа к svn.

Вопрос: как в новой версии получить архив какой-либо части (trunk и др.) или всего дерева, включая старые версии?
Раньше были значки для формирования нужного архива.

Эта ссылка http://svn.code.sf.net/p/scmrtos/code/ у меня не работает (404 Not Found). Остальные дают результат.

[AHTOXA]

Вопрос: как в новой версии получить архив какой-либо части (trunk и др.) или всего дерева, включая старые версии?
Раньше были значки для формирования нужного архива.

Никак, в новой версии этого нет. Либо посчитали, что это не нужно, либо просто не успели приделать.
Пока что можно пользоваться старой версией, думаю что она какое-то время ещё будет доступна. А потом может и к новой прикрутят.

Эта ссылка http://svn.code.sf.net/p/scmrtos/code/ у меня не работает (404 Not Found). Остальные дают результат.

Хм. У меня работает. Может быть это были временные трудности?
(В любом случае, эта ссылка не для браузера, а для svn-клиента, браузером там практически нечего делать)

[сарматъ]

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

[AHTOXA]

Конечно делали
Пример 5-FPU как раз этим и занимается.
Там две задачи постоянно проверяют неизменность своего контекста (контексты изначально различаются), а третья - вычисляет число Пи.

[сарматъ]

Конечно делали
Пример 5-FPU как раз этим и занимается.
Там две задачи постоянно проверяют неизменность своего контекста (контексты изначально различаются), а третья - вычисляет число Пи.

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

а где можно почитать как проекты на с без оси адаптировать под csmrtos?

обязательно ли все делать на с++ или можно подключать старые модули на с?

и существуют ли где либо ссылки по прикручиванию к этой оси какой либо виртуальной машины пи-кода?

[AHTOXA]

я не разбираюсь в асм потому не могу понять что происходит во втором и третьем потоке,

Там сначала обычные регистры заполняются разными значениями, потом эти значения копируются в плавучие регистры, а потом в цикле производится сравнение их значений. Если выявляется несовпадение - начинает моргать светодиод.
А почему у вас возникли сомнения в неизменности контекста?

а где можно почитать как проекты на с без оси адаптировать под csmrtos?

Почитайте для начала Руководство пользователя. Это поможет понять, как вообще устроены программы с использованием scmRTOS.

обязательно ли все делать на с++ или можно подключать старые модули на с?
и существуют ли где либо ссылки по прикручиванию к этой оси какой либо виртуальной машины пи-кода?

Модули на си подключать можно.
Насчёт пи-кода - не припоминаю. Знаю только, что к ардуине прикручивали.

[сарматъ]

Там сначала обычные регистры заполняются разными значениями, потом эти значения копируются в плавучие регистры, а потом в цикле производится сравнение их значений. Если выявляется несовпадение - начинает моргать светодиод.
А почему у вас возникли сомнения в неизменности контекста?

Почитайте для начала Руководство пользователя. Это поможет понять, как вообще устроены программы с использованием scmRTOS.
Модули на си подключать можно.
Насчёт пи-кода - не припоминаю. Знаю только, что к ардуине прикручивали.

сомнений конкретно относительно scmrtos как таковых нет, но изучая разные сайты нашел обсуждения относительно pawn, что в некотоых случаях он работает некорректно, соответственно если буду использовать scmRTOS то хотелось бы быть уверенным в ней на все 100%

спасибо за ответы, посмотрю ваши ссылки

[сарматъ]

Там сначала обычные регистры заполняются разными значениями, потом эти значения копируются в плавучие регистры, а потом в цикле производится сравнение их значений. Если выявляется несовпадение - начинает моргать светодиод.
А почему у вас возникли сомнения в неизменности контекста?

добрый день,задачка стала увеличиваться, увеличил размер памяти под стек заморгал светодиод, контекст нарушается?

[AHTOXA]

Может быть. Хотя я довольно интенсивно использую порт в нескольких проектах, и ни разу с таким не сталкивался.
Какой у вас был размер стека, и какой стал? Может быть всё равно не хватает?
И убедитесь, что у вас самая свежая версия оси, я там что-то исправлял вроде.

[сарматъ]

Может быть. Хотя я довольно интенсивно использую порт в нескольких проектах, и ни разу с таким не сталкивался.
Какой у вас был размер стека, и какой стал? Может быть всё равно не хватает?
И убедитесь, что у вас самая свежая версия оси, я там что-то исправлял вроде.

за основу взят ваш пример

typedef OS::process<OS::pr0, 4000> TProc0;
typedef OS::process<OS::pr1, 1000> TProc1;
typedef OS::process<OS::pr2, 4000> TProc2;
typedef OS::process<OS::pr3, 306> TProc3;--- так не работает

typedef OS::process<OS::pr0, 4000> TProc0;
typedef OS::process<OS::pr1, 1000> TProc1;
typedef OS::process<OS::pr2, 4000> TProc2;
typedef OS::process<OS::pr3, 303> TProc3;--- так работает

при величине стека третьей задачи больше 303 начинает моргать светодиод

TProc3 Proc3;

template <>
OS_PROCESS void TProc3::exec()
{
test_context(0x87654321);--- ваша функция на ассембл
}


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

Сообщение отредактировал сарматъ - Aug 12 2013, 08:55

[AHTOXA]

Увеличивать стек конкретно этой задачи нет смысла, 300 байт ей за глаза (200 байт на контекст, плюс сама задача кладёт максимум 4 регистра на стек).
На всякий случай задавайте размер стека кратно 4, а лучше - кратно 8.
Посмотрите на общее потребление памяти, попробуйте на время сократить какой-нибудь большой массив.
Возможно, на стек этой задачи наползает куча.
Поэкспериментировать сам смогу нескоро, я сейчас в отпуске, не до этого совсем

[сарматъ]

Увеличивать стек конкретно этой задачи нет смысла, 300 байт ей за глаза (200 байт на контекст, плюс сама задача кладёт максимум 4 регистра на стек).
На всякий случай задавайте размер стека кратно 4, а лучше - кратно 8.
Посмотрите на общее потребление памяти, попробуйте на время сократить какой-нибудь большой массив.
Возможно, на стек этой задачи наползает куча.
Поэкспериментировать сам смогу нескоро, я сейчас в отпуске, не до этого совсем

это понятно что ей 300 байт хватает, как раз не понятно отчего при увеличении стека она заваливается, стек делал разным с шагом единица в пределах 300-310, ни 304, ни 306 ни 308 ни 310 не улучшают ситуацию

по памяти:

--- building 5-FPU. defines: -DSTM32F4XX -DVER_MAJOR=0 -DVER_MINOR=1 -DHSE_VALUE=8000000
text data bss dec hex filename
38408 2164 51304 91876 166e4 ./exe/5-FPU.elf
Errors: none

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

жаль что не сможете попробовать повторить в ближайшее время - очень сильно на это надеялся

хорошего отдыха

зы проверил про кучу дело явно не в ней - изменил одну задачку на

template <>
OS_PROCESS void TProc1::exec()
{
test_context(0x87654312);
}

поведение в двух этих задачах совершенно одинаковое ломаются контексты при увеличении стека свыше 303 байт

Сообщение отредактировал сарматъ - Aug 12 2013, 11:42

[AHTOXA]

Я имел в виду, что не смогу добраться до своих серъёзных рабочих проектов, чтоб посмотреть там. (Хотя думаю, что я бы заметил порчу контекста )
А тестовый пример на F4discovery - я прогнал, с разными стеками, всё работает нормально, контекст не портится.
Вы как-то проигнорировали мою реплику про самую свежую версию оси. У вас точно она? Потому что в каком-то (пред-)предпоследнем варианте было такое, там было неверно сделано выравнивание стека. Вроде бы я это исправил до создания этого топика, но всё же проверьте на всякий случай.
Ну и с кучей - попробуйте временно отключить динамическое распределение памяти, чтоб уж точно знать, что это не она.
То есть, попробуйте постепенно возвращаться к примеру 5-FPU, пока всё снова не заработает. Или наоборот, потихоньку добавляйте к примеру свой функционал, пока не сломается.

[сарматъ]

версия os 4.0

динамически память вообще не выделяется

сейчас попробую на чистом вашем примере сделать то же самое увеличение стека

сделал: вырезал весь свой функционал все равно светодиодик моргает... а где можно скачать самую последнюю вашу версию порта и ос?

Сообщение отредактировал сарматъ - Aug 12 2013, 15:39

[AHTOXA]

Вот тут: ссылка. Там можно нажать на "Download Snapshot".

[сарматъ]

вот распределение памяти в чистой вашей задаче

text data bss dec hex filename
2576 0 2644 5220 1464 ./exe/5-FPU.elf


размер стека

//
typedef OS::process<OS::pr0, 300> TProc1;
typedef OS::process<OS::pr1, 300> TProc2;
typedef OS::process<OS::pr2, 1000> TProc3;
typedef OS::process<OS::pr3, 300> TProc4;

моргает оранжевый светодиод

[AHTOXA]

Что с осью, у вас была свежая версия?
У меня с такими размерами стека мигает зелёный!
Распределение памяти чуть другое (я компилировал сборкой от klen-а):

Код

   text       data        bss        dec        hex    filename
   2592          0       2644       5236       1474    ./exe/5-FPU.elf

Что у вас за компилятор?

[сарматъ]

копмилятор gcc-arm-none-eabi-4_6-2012q2

*************************************************
GNU Tools for ARM Embedded Processors
- June 2012
*************************************************

This release includes the following items:
* Bare metal EABI pre-built binaries for running on a Windows host
* Bare metal EABI pre-built binaries for running on a Linux host
* Source code package (together with build scripts and instructions to setup
build environment), composed of:
* gcc : ARM/embedded-4_6-branch revision 188521
http://gcc.gnu.org/svn/gcc/branches/ARM/embedded-4_6-branch/

* binutils : 2.21 with mainline backports
git://sourceware.org/git/binutils.git

* newlib : 1.19 with mainline backports
ftp://sources.redhat.com/pub/newlib/newlib-1.19.0.tar.gz

* gdb : 7.3.1 with mainline backports, without target sim support
git://sourceware.org/git/gdb.git

* cloog-ppl 0.15.11 :
ftp://gcc.gnu.org/pub/gcc/infrastructure/...-0.15.11.tar.gz

* expat 2.0.1 :
http://space.dl.sourceforge.net/project/ex...at-2.0.1.tar.gz

* gmp 4.3.2 : ftp://gcc.gnu.org/pub/gcc/infrastructure/gmp-4.3.2.tar.bz2

* libelf 0.8.13 : http://www.mr511.de/software/libelf-0.8.13.tar.gz

* libiconv 1.11.1 :
http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.11.1.tar.gz

* mpc 0.8.1 : ftp://gcc.gnu.org/pub/gcc/infrastructure/mpc-0.8.1.tar.gz

* mpfr 2.4.2 : ftp://gcc.gnu.org/pub/gcc/infrastructure/mpfr-2.4.2.tar.bz2

* ppl 0.11 : ftp://gcc.gnu.org/pub/gcc/infrastructure/ppl-0.11.tar.gz

* zlib 1.2.5 with makefile patch :
http://sourceforge.net/projects/libpng/fil...ar.bz2/download

* ncurses 5.9 :
http://ftp.gnu.org/pub/gnu/ncurses/ncurses-5.9.tar.gz

а что за сборка от klen-а?

относительно версии оси... она была 4.0 какой именно ее вариант сказать не могу - я просто на ее место переписал из новой ссылки..

может все дело в .ld файле? он из примера для евентфлаг

и да зеленый тоже моргает но с ним и моргает оранжевый... может в тестовой задаче test_context(0x87654321); у меня что то другое?

//
typedef OS::process<OS::pr0, 300> TProc1;
typedef OS::process<OS::pr1, 300> TProc2;
typedef OS::process<OS::pr2, 300> TProc3;
typedef OS::process<OS::pr3, 300> TProc4;

text data bss dec hex filename
2576 0 1944 4520 11a8 ./exe/5-FPU.elf
Errors: none

а при таком стеке что с памятью?

величина стека влияет только на bss он уменьшился ровно на 700 байт... вроде как и положено.. может оптимизация на что то влияет? у меня остался старый маке файл сменю его сейчас и еще раз попробую

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

в итоге работает с нормальным сохранением контекста только со значением оптимизации

# compile options
OPTIMIZE = -O1(s)

Сообщение отредактировал сарматъ - Aug 13 2013, 05:56

[AHTOXA]

Творится что-то невероятное
Давайте сделаем чистый эксперимент, по шагам. Я проделаю, опишу шаги, а вы повторите. Итак...

• Идём на https://launchpad.net/gcc-arm-embedded, качаем компилятор. Я скачал gcc-arm-none-eabi-4_7-2013q2-20130614-linux.tar.bz2.
• Устанавливаем его, убеждаемся, что он доступен:
  
  Код
  $ arm-none-eabi-gcc --version
  arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.7.4 20130613 (release) [ARM/embedded-4_7-branch revision 200083]
  Copyright (C) 2012 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE
• Создаём папку test, заходим в неё.
• Качаем примеры:
  
  Код
  svn checkout http://svn.code.sf.net/p/scmrtos/code/trunk/Samples/CortexM4F/GCC/STM32F4XX STM32F4XX
• заходим в папку STM32F4XX;
• запускаем switch.bat (под линуксом - switch.sh)
  Всё, теперь у нас есть самые свежие примеры с самой свежей осью.
• Теперь компилируем пример №5. Заходим в папку 5-FPU и командуем make.
• И наконец, заливаем пример в плату. Я для этого набираю make program, но это не суть.
  Моргает зелёный светодиод.
• Меняем стек процесса TProc3 на 1000, компилируем, заливаем. Моргает зелёный светодиод! Красный не подаёт признаков жизни.

[сарматъ]

сейчас установил как раз этот тулчейн, устанавливаю эклипс новый - старый с этим тулчейном не работает а без эклипса заливать в платку не умею

[сарматъ]

результат сборки со стеком 300

text data bss dec hex filename
2616 0 1944 4560 11d0 ./exe/5-FPU.elf
Errors: none

стек 1000

text data bss dec hex filename
2616 0 2644 5260 148c ./exe/5-FPU.elf
Errors: none

скоро научусь заливать в платку посмотрю на результаты

интересно... тулчейн версии 4.6 оптимизировал по размеру сильнее чем 4.7...

залил на платку все заработало, спасибо за помощь, заодно спасибо и за драйвер в нокии дисплейчику - давно в инете находил по моему за вашим авторством для AVRок

Сообщение отредактировал сарматъ - Aug 13 2013, 20:58

[AHTOXA]

Уф-ф
Я думаю, что причина всё-таки в том, что в заглавном посте топика ссылка устарела. Она указывает на старый репозиторий, который перестал обновляться уже давно.
Поэтому просьба к модераторам: исправьте пожалуйста в заглавном посте топика строчку
"svn co https://scmrtos.svn.sourceforge.net/svnroot...F/GCC/STM32F4XX STM32F4XX"
на

Код

svn co http://svn.code.sf.net/p/scmrtos/code/trunk/Samples/CortexM4F/GCC/STM32F4XX STM32F4XX

(желательно в теге "code", чтобы движок форума не сделал ссылку).

[IgorKossak]

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

[сарматъ]

а как грамотно подключить в .ld использование 16к рам под езернет? и в примерах под chibi os есть вариант .ld файла для использования дополнительных 64к под стек ( вкачестве информации - вдруг кому пригодится)

и еще в порядке пожелания: в том старом примере файл определений регистров содержал меньшее количество перифирии чем есть у процессора (я про файлик stm32f4xx.h) подскажите что надо изменить в стандартном stm-овском файле чтобы можно было бы пользоваться им совместно с scmrtos? (в прошлый раз я просто добавил в ваш вариант несколько определений регистров для usart но хочется использовать родной stm-овский файл)

ну и малоли кому пригодится тоже: связка
gcc-arm-none-eabi-4_7-2013q2
eclipse 4.3 kepler
openocd 0.6.1
вместе чудно уживаются и приемлемо работают

Сообщение отредактировал сарматъ - Aug 14 2013, 08:14

[AHTOXA]

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

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

а как грамотно подключить в .ld использование 16к рам под езернет?

Ну вот как пример (для батарейной памяти). Объявляем новую область памяти (BATTRAM):

Код

MEMORY
{
    RAM (xrw)   : ORIGIN = 0x20000000, LENGTH =  112K       /* Main RAM (can be accessed by DMA) */
    FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 1024K       /* Flash */
    BATTRAM (rw): ORIGIN = 0x40024000, LENGTH =    4K       /* Battery backed RAM */
}

, далее говорим, что все данные из секции .battram должны помещаться в эту область:

Код

    /* battery backed RAM data (if applicable) */
    .battram :
    {
        . = ALIGN(4);
        _start_of_batt_ram = .;
        *(.battram)
        *(.battram.*)
        _end_of_batt_ram = .;
    } > BATTRAM

и затем в коде помещаем нужные переменные в секцию .battram:

Код

nvBuffer[128]  __attribute__((__section__(".battram")));

Теперь буфер nvBuffer будет расположен в батареечной памяти.

и еще в порядке пожелания: в том старом примере файл определений регистров содержал меньшее количество перифирии чем есть у процессора (я про файлик stm32f4xx.h) подскажите что надо изменить в стандартном stm-овском файле чтобы можно было бы пользоваться им совместно с scmrtos?

Во-первых, файл stm32f4xx.h не используется собственно осью, только примерами.
А во-вторых, это и есть стандартный stm-овский файл (он у меня был расположен в "Libraries/CMSIS/ST/STM32F4xx/Include").
В общем, если есть другой, более полный файл, просто используйте его, и всё.

[сарматъ]

и затем в коде помещаем нужные переменные в секцию .battram:

Код

nvBuffer[128]  __attribute__((__section__(".battram")));

Теперь буфер nvBuffer будет расположен в батареечной памяти.

огромное спасибо!!

Во-первых, файл stm32f4xx.h не используется собственно осью, только примерами.
А во-вторых, это и есть стандартный stm-овский файл (он у меня был расположен в "Libraries/CMSIS/ST/STM32F4xx/Include").
В общем, если есть другой, более полный файл, просто используйте его, и всё.

все заработало

в версии stm32f4xx.h 2013 года учитываются разные контр и соотв существует два разных дефайна
STM32F427X и STM32F40XX, соотв чтобы с этим файлом корректно работала ось необходимо
- в майк файле добавить SUBCHIP = STM32F40XX, изменить DEFS = -D$(CHIP) на DEFS = -D$(SUBCHIP)
- в pin.h #if (defined STM32F2XX) || (defined STM32F4XX) заменить на
#if (defined STM32F2XX) || (defined STM32F4XX) || (defined STM32F40XX) || (defined STM32F427X)

больше в файлах оси я не нашел вхождений константы STM32F4XX, вопрос: их действительно бальше нет или я просто не нашел?

Сообщение отредактировал сарматъ - Aug 15 2013, 18:35

[AHTOXA]

в версии stm32f4xx.h 2013 года учитываются разные контр и соотв существует два разных дефайна
STM32F427X и STM32F40XX

Я не видел этого вашего ответа, и поэтому решил-таки сделать пример с использованием ST-lib.
Сейчас собрался его запостить, а у вас уже всё решилось
Но. В только что мной скачанной версии stm32f4xx.h (11-January-2013) уже есть три дефайна:

Код

#if !defined (STM32F4XX) && !defined (STM32F40XX) && !defined (STM32F427X)

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

больше в файлах оси я не нашел вхождений константы STM32F4XX, вопрос: их действительно бальше нет или я просто не нашел?

Действительно нет. Ось использует для определения архитектуры M3-M4/M4F дефайн __SOFTFP__, остальное ей неважно.
Ладно, всё равно выложу пример, раз уж сделал. Может кому-ннибудь пригодится
Вот:  6_ST_libs.zip ( 459.93 килобайт ) Кол-во скачиваний: 108

[сарматъ]

Но. В только что мной скачанной версии stm32f4xx.h (11-January-2013) уже есть три дефайна:

Код

#if !defined (STM32F4XX) && !defined (STM32F40XX) && !defined (STM32F427X)

они пошутили на самом деле если использовать STM32F4XX то не будет определено перывание FPU, поэтому надо использовать либо STM32F40XX либо STM32F427X (на сколько я разобрался в stm32f4xx.h)

кстати как интересно то в сисинит...

#if (!defined __SOFTFP__)
SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2)); // set CP10 and CP11 to all ones.
#endif

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

#if (__FPU_PRESENT == 1) && (__FPU_USED == 1)
SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2)); /* set CP10 and CP11 Full Access */
#endif

да.. и видимо так же правильнее было бы откорректировать ос_таргет_сипипи - для CM3 если не определена эмуляция плавающей точки порт будет работать как для процессоров с аппаратной плавающей арифметикой

как понимаю __VFP_FP__ и __SOFTFP__ устанавливаются компилятором в зависимости от вот этой строчки майк файла FPU= -mfpu=fpv4-sp-d16 -mfloat-abi=hard, правильно? а далее __FPU_PRESENT и __FPU_USED устанавливаются соотв в stm32xx.h и core_cm4.h и далее ими уже пользуются все остальные модули программы, так?

Сообщение отредактировал сарматъ - Aug 16 2013, 11:38

[AHTOXA]

они пошутили на самом деле если использовать STM32F4XX то не будет определено перывание FPU, поэтому надо использовать либо STM32F40XX либо STM32F427X (на сколько я разобрался в stm32f4xx.h)

Наверное да, STM32F4XX - это общий дефайн для семейства, а STM32F40XX и STM32F427X - это варианты исполнения.
Прерывание FPU есть в обоих вариантах, так что можно просто перенести его в общую часть:

Код

  CRYP_IRQn                   = 79,     /*!< CRYP crypto global interrupt                                      */
  HASH_RNG_IRQn               = 80,      /*!< Hash and Rng global interrupt                                     */
  FPU_IRQn                    = 81      /*!< FPU global interrupt                                              */
#ifdef STM32F427X
  ,
  UART7_IRQn                  = 82,     /*!< UART7 global interrupt                                            */

кстати как интересно то в сисинит...

#if (!defined __SOFTFP__)
SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2)); // set CP10 and CP11 to all ones.
#endif

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

#if (__FPU_PRESENT == 1) && (__FPU_USED == 1)
SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2)); /* set CP10 and CP11 Full Access */
#endif

sysinit.cpp - это просто пример, это не часть порта/оси. Поэтому он не претендует на универсальность. Он сделан просто для примера. К тому же, __SOFTFP__ - это дефайн компилятора, а __FPU_PRESENT и __FPU_USED - это дефайны из ST-шной библиотеки, а она в примерах не использовалась.

да.. и видимо так же правильнее было бы откорректировать ос_таргет_сипипи - для CM3 если не определена эмуляция плавающей точки порт будет работать как для процессоров с аппаратной плавающей арифметикой

Не, там всё нормально. Вот тут я выяснял самый подходящий дефайн. Получилось, что это __SOFTFP__. (__VFP_FP__ определён во всех четырёх случаях, так что его проверять нет смысла.)

как понимаю __VFP_FP__ и __SOFTFP__ устанавливаются компилятором в зависимости от вот этой строчки майк файла FPU= -mfpu=fpv4-sp-d16 -mfloat-abi=hard, правильно? а далее __FPU_PRESENT и __FPU_USED устанавливаются соотв в stm32xx.h и core_cm4.h и далее ими уже пользуются все остальные модули программы, так?

Я не особо разбираюсь в ST-шных либах. По-моему, там жёстко задаётся __FPU_PRESENT = 1, а __FPU_USED устанавливается в зависимости от __VFP_FP__ и __SOFTFP__.
Кстати, поэтому варианты

Код

#if (!defined __SOFTFP__)

и

Код

#if (__FPU_PRESENT == 1) && (__FPU_USED == 1)

идентичны

[сарматъ]

короче сломал себе голову и сделал проще, вот так в мейкфайле


CHIP = STM32F4XX
HSE_VALUE = 8000000

ifeq ($(CHIP),STM32F4XX)
MCU = cortex-m4
FPU = -mfpu=fpv4-sp-d16 -mfloat-abi=hard
#FPU = -mfpu=fpv4-sp-d16 -mfloat-abi=softfp
DEFS = -DSTM32F40XX
else
MCU = cortex-m3
DEFS = -D$(CHIP)
DEFS += -DST_M___3__2_C__M_3__SOFTFP__
endif

# compiler defines
DEFS += -DVER_MAJOR=$(VER_MAJOR)

ну и в порте заменил __SOFTFP__ на ST_M___3__2_C__M_3__SOFTFP__

Сообщение отредактировал сарматъ - Aug 17 2013, 13:53

[AHTOXA]

ну и в порте заменил __SOFTFP__ на ST_M___3__2_C__M_3__SOFTFP__

А зачем?

[сарматъ]

А зачем?

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

[AHTOXA]

Компилятор ставит дефайн __SOFTFP__ в двух случаях:

• -mcpu=cortex-m3
• -mcpu=cortex-m4

То есть, в случае M3 и M4 без сопроцессора. В этих случаях порт использует контекст M3.
В случае наличия сопроцессора (два варинта):

• -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=hard
• -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp

используется контекст с плавучкой.
То есть, мы полностью управляем поведением порта: хотим M3 - определяем -mcpu=cortex-m3, хотим M4 без плавучки - определяем -mcpu=cortex-m4. Нужна плавучка - -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi={hard|softfp}.
Ну а если всё же хочется определить именно M3, то для этого у компилятора есть специальный дефайн: __ARM_ARCH_7M__
(для M4: __ARM_ARCH_7EM__).

[сарматъ]

а как кстати определить адрес функции во флеше?

[Сергей Борщ]

Что вы подразумеваете под "определить"? Если узнать адрес - в программе достаточно присвоить имя функции соответствующему указателю, а человеку нужно найти эту функцию в .map или дизассемблированном листинге. Если же вы имели ввиду "задать конкретный адрес для функции" - то надо в скрипте линкера описать секцию по нужному адресу и разместить фукцию в эту секцию при помощи __attribute__((section("имя секции"))

[сарматъ]

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

то есть надо вначале компилировать биос и смотреть его мап файл потом прикладную программу и ее мап файл смотреть?

[Сергей Борщ]

я имею ввиду написание загрузчика-биоса отдельно от прикладной программы

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

[сарматъ]

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

[сарматъ]

восстановил задачку, все работает

очень приятное впечатление и от оси и от порта, спасибо разработчикам

[Сергей Борщ]

потом вызывает функции из прикладной программы, которые в свою очередь могут вызывать функции из биоса

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

CODE

// boot_cross.h
struct bootloader_cross_table
{
    uint8_t HW_version;
    void (* func1)();
    uint8_t (* func2)();
    uint32_t (* func3)(uint32_t param);
};

// bootloader.cpp
#include    "boot_cross.h"
__attribute__((section(".text.boot.cross_table")))
bootloader_cross_table Cross_table =
{
    1,
    boot_func_1,
    boot_func_2,
    boot_func_3,
};

// application.cpp
#include    "../bootloader/boot_cross.h"
extern bootloader_cross_table Bootloader;   // а в скрипте линкера добавить PROVIDE(Bootloader = абсолютный адрес);
                                            // или же в командной строке линковки добавить -Wl,--defsym,Bootloader=адрес

void test()
{
    printf("Hardware version: %d", Bootloader.HW_version);
    
    Bootloader.func1();
    uint32_t Data = Bootloader.func3(12345);
}

[сарматъ]

еще раз спасибо, буду осмысливать

[arm-user]

Добрый день.

Пользуюсь SCM под LPC17xx продолжительное время, но сама операционка для меня как черный ящик.
Подскажите, насколько реально сделать порт под LPC43xx ?
Степень сложности ?

[Сергей Борщ]

Степень сложности ?

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

[arm-user]

Как вижу, там внутри Cortex-M4 и Cortex-M0. Степень сложности равна нулю ...

Спасибо, подбодрили. Будем пробовать.

[сарматъ]

добрый день, подскажите а ТMutex.lock() запрещает прерывания или только блокирует переключение задач и запрет прерываний нужно делать отдельно?

[Сергей Борщ]

подскажите а ТMutex.lock() запрещает прерывания или только блокирует переключение задач и запрет прерываний нужно делать отдельно?

Он не делает ни того ни другого. Он просто переводит этот TMutex в такое состояние, что задача, выполняющая следующий lock() будет поставлена на ожидание до тех пор, пока первая не сделает unlock(). Это описано в документации, с примерами.

[сарматъ]

а вот эта функция
static __INLINE void __disable_irq() { __ASM volatile ("cpsid i"); }
запретит переключение задач?

[AHTOXA]

Да, запретит.
Но удобнее для этого пользоваться TCritSect:

Код

void foo(){
    TCritSect cs;
    ... // всё отсюда до выхода из функции будет выполняться при запрещённых прерываниях.
}

[сарматъ]

спасибо, сейчас почитаю что это

вот что нашел http://embedders.org/blog/teap0t/miro-same...u.html?page=0,7 кому интересно, позже будут вопросы в связи с прочитанным, там в седьмой статье описывается как грамотно запрещать прерывания в арм7 - как понимаю для порта на кортекс это актуально (хотя могу и ошибаться)

[mdmitry]

А не проще ли почитать документацию на scmRTOS отсюда?

[сарматъ]

наверное проще и этот файл у меня открыт, вот только вхождений "критическая секция" в нем 2 штуки
SYS_TIMER_CRIT_SECT - 3 штуки, или куда именно предлагаете глазом упереться?

ах 2.3.3. вот сюда;-)

Сообщение отредактировал сарматъ - Aug 28 2013, 12:14

[mdmitry]

наверное проще и этот файл у меня открыт, вот только вхождений "критическая секция" в нем 2 штуки
SYS_TIMER_CRIT_SECT - 3 штуки, или куда именно предлагаете глазом упереться?

Так ведь есть же исходные тексты. Файл OS_Target.h в помощь и AHTOXA код привел.

[сарматъ]

мдмитрий и опять вы правы

антоха, снова я уперся в незнание асемблера, я правильно понимаю, что конструктор этого класса запоминает были ли запрещены прерывания на момент его вызова, а в момент вызова деструктора прерывания остаются запрещенными если на момент вызова конструктора они были запрещены?

еще раз перечитал 2.3.3. вроде именно это там и написано(смущающийся колобок)

новый вопрос, антоха, а в функции PendSVC_ISR() не происходит сохранения состояния статуса разрешения\запрещения прерываний до их запрещения?

Сообщение отредактировал сарматъ - Aug 28 2013, 12:48

[AHTOXA]

а в функции PendSVC_ISR() не происходит сохранения состояния статуса разрешения\запрещения прерываний до их запрещения?

Нет, потому что PendSVC_ISR() - это прерывание, и оно может выполниться только при разрешённых прерываниях

[сарматъ]

аааааа.... вот как раз по поводу этого я ссылку выше и приводил

там касаемо ситуации возникновения прерывания во время выполнения инструкции запрещения прерывания

то есть выполняется где либо инструкция запрещения прерывания и во времяя этого возникает прерывание PendSVC_ISR() оно исполняется и разрешает прерывания и вываливается обратно в место где прерывания должны быть запрещены но по факту с разрешенными прерываниями

или я что то путаю?

вот еще одна ссылка http://infocenter.arm.com/help/index.jsp?t....faqs/3677.html

Сообщение отредактировал сарматъ - Aug 28 2013, 15:20

[AHTOXA]

Ссылки про ARM7TDMI, это не то. У Кортексов всё это сделано значительно прямее.

[сарматъ]

дааа.... пока все это далеко от моего понимания, потому нашел временную альтернативу запрету прерываний, может кому пригодится http://we.easyelectronics.ru/STM32/atomarn...-cortex-m3.html

и да вопрос: будет ли конструкция
uint32_t oldValue, newValue;
do
{
oldValue = __LDREXW(ptr);
newValue = oldValue + value;
}while(__STREXW(newValue, ptr));
корректно работать с ОС?

Сообщение отредактировал сарматъ - Aug 28 2013, 20:38

[AHTOXA]

А чего там понимать? Вы читали не про тот контроллер В Cortex-M4, если инструкция запрета прерываний прошла, то прерывание не возникнет.
Конструкция работать будет, без проблем.
Есть ещё GCC Atomic-Builtins, делают то же самое, но несколько более универсальны. Вроде бы (точно не помню) тоже используют LDREX/STREX.

[сарматъ]

а если подобные конструкции будут в паралельных задачах они друг друга путать не будут?


и все же полностью без запрета прерываний не получается,

В Cortex-M4, если инструкция запрета прерываний прошла, то прерывание не возникнет.

где об этом можно прочитать? у меня макетка неделю работала потом повисла - ищу все потенциальные места где могло это произойти

Сообщение отредактировал сарматъ - Aug 29 2013, 06:36

[AHTOXA]

а если подобные конструкции будут в паралельных задачах они друг друга путать не будут?

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

где об этом можно прочитать?

Вот тут. Более развёрнутое объяснение от Joseph Yiu (отсюда) :

On some processors, the disable interrupt function might take sometime to take effect. This is because the masking is done via control register accesses through the bus. (there could be wait state on the bus and the write operation could be buffered, and the interrupt controller might need a cycle to update to the new setting).

On Cortex-M3, the interrupt mask registers are inside the processors (e.g. FAULTMASK, PRIMASK). As soon as PRIMASK/FAULTMASK/BASEPRI is set, the effect come immediately. So if you set the PRIMASK and the interrupt arrived at the same time, the interrupt will have to wait until the mask is cleared. To do this, the interrupt mask registers are accessible by CPS, MSR and MRS instructions only

Короче, виснет не из-за этого.

[сарматъ]

#define disable_interrupts() __asm__ __volatile__ ("cpsid i\n cpsid i")

если так сделать ось не сломается?

или так надо? #define disable_interrupts() __asm__ __volatile__ ("cpsid i\n"" cpsid i")

Сообщение отредактировал сарматъ - Aug 30 2013, 21:53

[AHTOXA]

Варианты равнозначны. Ось не сломается.
Но два раза - маловато, лучше три, для верности

[сарматъ]

[сарматъ]

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

[AHTOXA]

Прерывание с тем же приоритетом, что и текущее -- ждёт завершения текущего прерывания.
Советую почитать хорошую книжку про кортекс-м3.

[сарматъ]

спасибо

[сарматъ]

а в порте для см4 обработка прерываний происходит как на рис 7.17 из этой книжки?

[AHTOXA]

Нет. У нас прерывание системного таймера имеет самый низкий приоритет в системе, и не может прервать никакое другое прерывание.
То же касается и прерывания PendSV.

[сарматъ]

а что более ресурсоемко TEventFlag.wait() или sleep()?

[Сергей Борщ]

а что более ресурсоемко TEventFlag.wait() или sleep()?

Вот интересно, а что мешает заглянуть в исходники ОСи?

[сарматъ]

отсутствие необходимой квалификации как минимум

[Сергей Борщ]

отсутствие необходимой квалификации как минимум

Сравнить текст двух функций? В одной четыре строки кода, во второй - десять. Даже не смешно.

[сарматъ]

во первых я не ставил целью кого то рассмешить

во вторых, как я понимаю вы являетесь одним из разработчиков системы?, в таком случае спешу вам сообщить, что ваше описание системы, вероятно, имеет смыл доработать, в частности самый конец пункта 3.2.7
"В связи с этим, в большинстве случаев не возникает необходимости размещать код обработки событий на уровне прерываний даже при наличии такого аппаратного контроллера, а использовать прерывания только как источники событий, поместив их обработку на уровень процессов. Это рекомендуемый стиль построения программы." по крайней мере нуждается в существенных оговорках, рекомендуемый вами стиль построения программы при частоте поступления прерываний 10кГц дает потерю обработки около 50% событий, при размещении же обработчика целиком в теле прерывания потери составляют около 10%

[сарматъ]

измерил время выполнения sleep и wait таким образом

volatile uint32_t hgth;
hgth=DWT_CYCCNT;
sleep(10);
res_table.uregs[55]=DWT_CYCCNT-hgth;

volatile uint32_t hgth;
hgth=DWT_CYCCNT;
OneSecFlag.wait();
res_table.uregs[56]=DWT_CYCCNT-hgth;

получилось в первом случае 41000 тактов, во втором - 31000...

антоха это действительно эти функции выполнятся такое время или у меня что-то не так в программе?

кто-либо измерял аналогичные задержки в фриртос или иных системах?

похоже я что то не то измеряю

Сообщение отредактировал сарматъ - Sep 4 2013, 08:27

[AHTOXA]

рекомендуемый вами стиль построения программы при частоте поступления прерываний 10кГц дает потерю обработки около 50% событий, при размещении же обработчика целиком в теле прерывания потери составляют около 10%

Я думаю, что здесь проблема не в стиле, а в программе Я на 72МГц STM32F103 спокойно декодирую 100КГц манчестер. С потерями 0% событий. А тут у вас 168МГц и 10КГц. Это совсем небольшая нагрузка.

измерил время выполнения sleep и wait таким образом

Функция sleep() приостанавливает выполнение потока на заданное число тиков системного таймера. То есть, если таймер тикает раз в миллисекунду, то sleep(10) будет длиться от 9 до 10 мс. При частоте 168МГц это будет 168000*[9..10] тиков DWT. Ваши же числа совсем маленькие для 10 мс. С какой частотой у вас тикает системный таймер? С какой частотой взводится OneSecFlag?

[сарматъ]

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

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

Сообщение отредактировал сарматъ - Sep 4 2013, 08:49

[AHTOXA]

а в вашей задачке на 100кгц сложная логика обработки событий?

В прерывании - минимальная обработка, вычисляю длительность принятого импульса и кладу его в буфер (OS::channel).
А собственно анализ - достаточно сложный, но он выполняется в отдельном процессе. Собственно, всё сделано в точности так, как рекомендует документация

[сарматъ]

а приоритет этого процесса наивысший? и этот обработчик вызывается 100 раз за мс?
у меня было так

template <>
OS_PROCESS void TProc5::exec()
{
Eth_Slave();
}


OS::TEventFlag RxFlag;

OS_PROCESS void Eth_Slave(void){
for(;;){
RxFlag.wait();
for(;(DMARxDescToGet->Status&ETH_DMARxDesc_OWN) == (uint32_t)RESET;){
формирование отклика на прерывание - 5us;
}
}
}

extern "C" void ETH_IRQHandler(void)
{
ETH_DMAClearITPendingBit(ETH_DMA_IT_R | ETH_DMA_IT_T);
RxFlag.signal_isr();
}

вообще возможность послать сигнал в процесс из прерывания оч красива

Сообщение отредактировал сарматъ - Sep 4 2013, 11:16

[AHTOXA]

а приоритет этого процесса наивысший? и этот обработчик вызывается 100 раз за мс?

Нет, приоритет средний. Были более приоритетные задачи. И вызываться(просыпаться) он мог реже, чем 100 раз за мс. События копятся в очереди, и обрабатываются асинхронно, когда есть для этого время.

extern "C" void ETH_IRQHandler(void)
{
ETH_DMAClearITPendingBit(ETH_DMA_IT_R | ETH_DMA_IT_T);
RxFlag.signal_isr();
}

У вас не хватает обязательной строчки в начале обработчика прерывания:

Код

    OS::TISRW ISRW;

[Сергей Борщ]

Вы забыли:
а) тег [ code ]
б) в начале обработчика прерывания завести объект типа TISRW. Поэтому реальная перепланировка и получение сигнала у вас происходили при вызове перепланировки из какого либо процесса (при вызове функции какого-либо сервиса ОС) или же после прерывания ситемного таймера. Видимо поэтому часть сигналов и была потеряна.

[сарматъ]

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

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

почитал про OS::channel да создатели молодцы очень красивая система

Сообщение отредактировал сарматъ - Sep 4 2013, 19:33

[сарматъ]

антоха а в планах не стоит для ф417 контроллера порт сделать? это тот который с периферией для aes

[AHTOXA]

А какая разница с точки зрения порта?

[сарматъ]

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

Сообщение отредактировал сарматъ - Sep 19 2013, 09:54