Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: STM32F103x
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
Страницы: 1, 2, 3, 4, 5, 6
KRS
Цитата(zltigo @ Apr 17 2010, 21:51) *
И у NXP среди их Corteх-M3 замены тем-же LPC2378-2468-2478 тоже нет sad.gif. Так что про "хлам" явно рано.

NXP в прошлом году на конференции обещал что будет и замена LPC2478 в виде Cortex-M3. Причем 120 MHZ. А т.к. там узкое место интерфейс к SDRAM, то прирост частоты в больше чем 1,5 раза даст хороший выйгрышь! Но похоже это будет не скоро sad.gif
klen
я хламом назвал "седмой' по стравению с кортексом. даже если точнее не конкретные контроллеры а архитектуры. меня в кортексе единственно только автоматическое сохранение контекста в прерываниях бесить, а так все дубово-прямолинейно что мне очень нравится.

закрыл 2 проъекта - сделать демку для платки с lpc2478 и stm32f107 в котрых работает сеть, я прикрутил freertos, uIP. но для кортекса както это быстро произошло и просто, а lpc мне моск высосал хорошо.

есть мнение что у ST аналога 2478 в ядре m3 не будет

я лично не понимаю целевую нишу 2478 - на дохлого рыцаря нацепили латы которые он поднять не может.

щас дали мне модуль на omap3530 - вот это уже может видео тянуть.. разбираюсь - пока впечатляет.
KRS
Цитата(klen @ Apr 18 2010, 00:33) *
щас дали мне модуль на omap3530 - вот это уже может видео тянуть.. разбираюсь - пока впечатляет.

Cortex-A8, с точки зрения программиста (системного) гораздо ближе к ARM7, чем к Cortex-M3.
zltigo
Цитата(klen @ Apr 17 2010, 23:33) *
закрыл 2 проъекта - сделать демку для платки с lpc2478 и stm32f107 в котрых работает сеть, я прикрутил freertos, uIP. но для кортекса както это быстро произошло и просто, а lpc мне моск высосал хорошо.

Мягко говоря бред, оценивать архитектуры по скорости сляпывания демок из интернетовского хлама sad.gif.


Цитата(klen @ Apr 17 2010, 23:33) *
я лично не понимаю целевую нишу 2478 - на дохлого рыцаря нацепили латы которые он поднять не может.

Что-бы было. Не всем кино крутить. Интересны на самом деле альтернативы не 2478, а 2468 и 2378.



Цитата(KRS @ Apr 18 2010, 00:11) *
Cortex-A8, с точки зрения программиста (системного) гораздо ближе к ARM7, чем к Cortex-M3.

Угу. А это типа OAMP smile.gif http://www.nvidia.com/object/tegra_250.html
SBE
Цитата(klen @ Apr 18 2010, 00:33) *
меня в кортексе единственно только автоматическое сохранение контекста в прерываниях бесить, а так все дубово-прямолинейно что мне очень нравится.

Любопытно, чем сохранение контекста не удобно?
zltigo
Цитата(SBE @ Apr 20 2010, 09:42) *
Любопытно, чем сохранение контекста не удобно?

Удобно, когда надо и не удобно, когда не надо. Не удобно, когда сохранение, вместо переключения банка регистров,как было у старичка ARM7. Ну упрощенная штука Cortex-M3, подогнанная под некую "самую массовую" практику использования и за счет упрощения поддающаяся разгону - хотите попугаев, они есть у нас. Тот-же контролер прерывания внесли в ядро, сделали за счет этого проще и быстрее, добавили (точнее в результате упрощения получили на халяву) мечту бездумных программеров - вложенные прерывания , но в результате все стало больше похоже на "ешьте, что дают".
SBE
Цитата(zltigo @ Apr 20 2010, 12:14) *
Удобно, когда надо и не удобно, когда не надо. Не удобно, когда сохранение, вместо переключения банка регистров,как было у старичка ARM7. Ну упрощенная штука Cortex-M3, подогнанная под некую "самую массовую" практику использования и за счет упрощения поддающаяся разгону - хотите попугаев, они есть у нас. Тот-же контролер прерывания внесли в ядро, сделали за счет этого проще и быстрее, добавили (точнее в результате упрощения получили на халяву) мечту бездумных программеров - вложенные прерывения , но в результате все стало больше похоже на "ешьте, что дают".


Уход от банка регистров при переключении это плата за вложенные прерывания. И если переключение контекста при этом происходит не медленнее чем на ARM7, то что потеряли? А вложенные прерывания с гибкой настройкой ИМХО немалая ценность, без этого рассуждения об латентности это про малоинтересный случай с одним прерыванием.
M3 не упрощенная (много в ней частей проще чем в ARM7?), а получше заточенная под встроенные применения архитектура (в отличие от ARM7, в котором совсем об этом не думали, а начали применять что было).
Контроллер прерывания в ядре помимо скорости, дает еще стандартизацию модели прерывания, тоже плюсик на пути к "стандарту де факто" для ядра МК.
zltigo
Цитата(SBE @ Apr 20 2010, 13:49) *
Уход от банка регистров при переключении это плата за вложенные прерывания.

Спасибо, а можно было не платить? Нельзя? Мне жаль sad.gif
Цитата
А вложенные прерывания с гибкой настройкой ИМХО немалая ценность

Для лобового программирования в стиле Super Loop c кучей длиннющих обработчиков прерываний - несомненно! А можно я так не буду делать?
Цитата
Много в ней частей проще чем в ARM7?

На мой взгляд все.
Цитата
, а получше заточенная под встроенные применения архитектура

Нет заточенная, а упрощенная, что не одно и тоже.
Цитата
Контроллер прерывания в ядре помимо скорости, дает еще стандартизацию модели прерывания, тоже плюсик на пути к "стандарту де факто" для ядра МК.

С точки зрения, унификации - несомненно, но опять "ешьте, что дают" - другого контролера прерываний, например, более быстрого с банками в обмен на пресловутую вложенность, на M3 не будет.
SBE
Цитата(zltigo @ Apr 20 2010, 16:07) *
Спасибо, а можно было не платить? Нельзя? Мне жаль sad.gif

Для лобового программирования в стиле Super Loop c кучей длиннющих обработчиков прерываний - несомненно! А можно я так не буду делать?

На мой взгляд все.

Нет заточенная, а упрощенная, что не одно и тоже.

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

А вы знаете как с банками и вложенные? Причем с банками то по факту в ARM7 вход в прерывание не быстрее, так где платим? smile.gif
Про стиль, SuperLoop и т.п. скромно промолчу. Ключевое слово "длиннющий", вопрос масштаба, который в это понятие вкладывается, и в конечном счете времени реакции в системе со многими прерываниями разного приоритета (добро пожаловать в реальный мир smile.gif ). NVIC позволяет этот масштаб перевести в другой порядок, чем в ARM7 (ну по крайней мере когда прерываний больше 2-х) .

Про упрощение дискуссия конечно субъективная, но "все" как-то слишком категорично. Особенно, если "ничего" более правильный ответ.
zltigo
Цитата(SBE @ Apr 20 2010, 15:45) *
А вы знаете как с банками и вложенные?

И знать не хочу smile.gif. Но тем не менее ручками push/pop получается немногим хуже автоматического сервиса. Короче делается просто.
Цитата
Причем с банками то по факту в ARM7 вход в прерывание не быстрее, так где платим? smile.gif

Львинную долю тактов ARM7 гипотетически съедает могущая попасться длиннющая в 20 тактов команда групповой пересылки всех регистров.
Ее в принципе, можно не использовать. Чистые потери контроллера прерываний для FIQ 7 тактов за это мы получаем 5 регистров, а не всего пару на автомате запушированных. Затем в M3 из прерывания нужно не только войти но и выйти. Это ЕЩЕ 12 тактов. При этом мы за эти такты, повторяю, получаем всего пару регистров общего назначения, а не как у FIQ пять. Давайте еще добавим для корректнго сравнения push и pop банкированных регистров. Кто сказал "быстрее"?
Что получаем? Несколько тактов в Corteх-M3 за счет того, что контроллер в ядре, естественно, экономится. Длинные, команды похерили. Все, в остальном на push/pop в тактах проигрыш. По времени подняв частоту под два раза в результате более получаем терпимые времена. Потенциальное ускорение от внесение контроллера в ядро С ЛИХВОЙ ушло в качестве платы за упрощение контроллера.
Цитата
Про стиль, SuperLoop и т.п. скромно промолчу. Ключевое слово "длиннющий", вопрос масштаба, который в это понятие вкладывается, и в конечном счете времени реакции в системе со многими прерываниями разного приоритета (добро пожаловать в реальный мир smile.gif ).

Меня всегда умиляла замена понятия время реакции понятием количество тактов до выполнения первой команды обработчика прерывания. Толку от того, что я быстро ввалюсь в обработчик, а потом начну пушировать регистры мало. Толку от того, что я быстро ввалившись в обработчик НО НЕ УСПЕВ ВЫДАТЬ ОТВЕТНОЕ ВОЗДЕЙСТВИЕ буду прерван вложенным прерыванием на фиг знает какое время, ВООБЩЕ НИКАКОГО. Какое такое, говорите "время реакции"? "Добро пожаловать в реальный мир",.....? Это Вам следует прежде всего задуматься о реальном мире, а не о своем представлении о нем. Я в реальном мире живу с середины 80x, и все мнимые радости вложенных прерываний познал еще в зеленом возрасте на Intel 8080/86/88, где они организованы были так-же просто, как и ныне в новейше-простейшем M3.
Цитата
Про упрощение дискуссия конечно субъективная,...

В минимальнейшей степени.
klen
Цитата(zltigo @ Apr 20 2010, 18:23) *
.. в реальном мире живу с середины 80x, и все мнимые радости вложенных прерываний познал еще в зеленом возрасте на Intel 8080/86/88


середина 80х - это гдето так 75год, а выпустили 8080 в апрель 1974. Это че ? они доступны в СССР'е были сразу? и лет Вам было 15. Ну наверно меется девяностые (80-89гг), я так думаю.

zltigo прав - иногда можно так организовать обработку прерывания что ничего особо и не сохранять в стек - просто флаг поставить а остальное - уже отложенная обработка прерывания, вот тут мненя и бесит - ну че мешало сделать механизм отменяющий автоматическое сохраниеие - НИЧЕ НЕДЕЛАТЬ ВСЕГДА ПРОЩЕ ЧЕМ ЧТОТО ДЕЛАТЬ. как то привык на асме сам решать что пушить а что нет wink.gif чуство что ты на собаччем поводке. а в остально мне нравится кортекс. Вот собираюсь pic32 (ключевое слово mips m4k) пробывать - должна ж гденить на свете быть правда ..... тока опять окажется ядро гуд - переферия шит, или наоборот иди все фулл шит wink.gif

тяжела жизнь землянина - много альтератив, и все г... и эз него нада лепить каменный цветок
zltigo
Цитата(klen @ Apr 20 2010, 17:27) *
середина 80х - это гдето так 75год,

Что?!!! Что за арифметика? Середина 80x это ПОСЛЕ восьмидесятого, перед 90-ым. Итого, это 85, а не 75. Работать начал с ними в 84.
aaarrr
Цитата(zltigo @ Apr 20 2010, 18:23) *
...При этом мы за эти такты, повторяю, получаем всего пару регистров общего назначения, а не как у FIQ пять.

Почему пару, если получаем те же пять штук: R0-R3 + R12?
zltigo
Цитата(aaarrr @ Apr 20 2010, 17:49) *
Почему пару, если получаем те же пять штук: R0-R3 + R12?

Виноват sad.gif. Не твердо усвоил sad.gif. Практики пока нет sad.gif.
vallav
Цитата(zltigo @ Apr 20 2010, 18:23) *
И знать не хочу smile.gif. Но тем не менее ручками push/pop получается немногим хуже автоматического сервиса. Короче делается просто.

Львинную долю тактов ARM7 гипотетически съедает могущая попасться длиннющая в 20 тактов команда групповой пересылки всех регистров.
Ее в принципе, можно не использовать. Потенциальное ускорение от внесение контроллера в ядро С ЛИХВОЙ ушло в качестве платы за упрощение контроллера.


Извините, а какая связь между упрощением контроллера и тем, что в кортексе запихивают автоматом в стек 5 регистров общего назначения?
Кстати, непонятно зачем нужно целых 12-5=7 тактов, чтобы запихнуть в стек адрес возврата и состояние процессора.
Идеал в этом смысле был ADIшный ADSP218x. У него, чтобы перейти от синхронного запроса прерывания к обработчику, требовался всего 1 такт.


Цитата(zltigo @ Apr 20 2010, 18:23) *
Меня всегда умиляла замена понятия время реакции понятием количество тактов до выполнения первой команды обработчика прерывания. Толку от того, что я быстро ввалюсь в обработчик, а потом начну пушировать регистры мало.


Так это - так называемые преимущества RISC архитектуры.
Которая совершенно не годится для контроллеров и давно устарела для байтовых мельниц.
В том же ADSP в этом толк есть - в нем через такт после запроса от таймера может начать исполняться команда обработчика, дергающая внешнюю
ногу, которая не нужны регистры. Для простого обработчика может вообще не потребоваться ни одного регистра.
SBE
Цитата(zltigo @ Apr 20 2010, 18:23) *
Львинную долю тактов ARM7 гипотетически съедает могущая попасться длиннющая команда групповой пересылки всех регистров.
Ее в принципе, можно не использовать.
А за оставшиеся такты мы получаем чистый банк регистров в том числе и общего назначения, а не всего несколько на автомате запушированных. Затем в M3 из прерывания нужно не только войти но и выйти. Это ЕЩЕ 12 тактов. При этом мы за эти такты, повторяю, получаем всего несколько регистров общего назначения, а не целый банк.
Что получаем? Несколько тактов в Corteх-M3 за счет того, что контроллер в ядре, естественно, экономится. Длинные, команды похерили. Все, в остальном в тактах проигрыш. По времени подняв частоту под два раза в результате более получаем терпимые времена. Потенциальное ускорение от внесение контроллера в ядро С ЛИХВОЙ ушло в качестве платы за упрощение контроллера.

Вот-вот, поэтому групповую пересылку и отключают, что совсем не идет на пользу производительности из-за часто используемых операций сохранения/извлечения контекста. В Кортексе к длинным командам еще деление добавилось.
Не все так печально если нужен полный контекст, оставшиеся 8 регистров догружаются LDM. В тактах в сумме не хуже получается чем в ARM7 с учетом LDM/STM и входа-выхода. Выход из IRQ в ARM7 тоже не бесплатный.
Весело в ARM7 будет только для единственного прерывания на FIRQ без LDM/STM.

Правда ваша, что потенциально в M3 могло быть еще быстрее при сохранения банков, но ценой все же не столько усложнения, а вложенности (и "длинных" команд). ИМХО оно того стоило.

Цитата
Меня всегда умиляла замена понятия время реакции понятием количество тактов до выполнения первой команды обработчика прерывания. Толку от того, что я быстро ввалюсь в обработчик, а потом начну пушировать регистры мало. Толку от того, что я быстро ввалившись в обработчик НО НЕ УСПЕВ ВЫДАТЬ ОТВЕТНОЕ ВОЗДЕЙСТВИЕ буду прерван вложенным прерыванием на фиг знает какое время, ВООБЩЕ НИКАКОГО. Какое такое, говорите "время реакции"? "Добро пожаловать в реальный мир",.....? Это Вам следует прежде всего задуматься о реальном мире, а не о своем представлении о нем. Я в реальном мире живу с середины 80x, и все мнимые радости вложенных прерываний познал еще в зеленом возрасте на Intel 8080/86/88, где они организованы были так-же просто, как и ныне в новейше-простейшем M3.

Не обижайтесь, мы с вами примерно одно время в "реальном мире" smile.gif , наверняка много каких архитектура попробовали с прекрасных времен К580. Извините, не понравилась категоричность.

Вы правы, что не надо упрощать понятие реакция. Только речь про разделение времени между многими прерываниями, когда появляется понятие "приоритет". Понятно, что когда много, кто-то да НЕ УСПЕЕТ ВЫДАТЬ ОТВЕТНОЕ ВОЗДЕЙСТВИЕ. В случае если нет вытеснения, более приоритетное прерывание опять же будет ждать "фиг знает какое время", пока закончится текущий обработчик. В ARM7 всегда будет "задвинуто" прерывание пришедший позднее, а М3 можно сделать, что задержано будет менее приоритетное (а можно и не делать, есть выбор, причем можно изменять стратегию по ходу). ИМХО гораздо более гибче и правильнее. И предсказуемее латентность прерывания, которое уже не будет ограничиваться самым медленным обработчиком.

Справедливости ради, если приоритета прерывания только 2, ARM7 с раздельнм FIRQ/IRQ будет не хуже.

Оно, конечно, что кошернее разделять время по приоритетам на уровне IST RTOS, только времена реакции будут совсем другими.
zltigo
Цитата(vallav @ Apr 20 2010, 17:56) *
В том же ADSP в этом толк есть - в нем через такт после запроса от таймера может начать исполняться команда обработчика, дергающая внешнюю
ногу, которая не нужны регистры. Для простого обработчика может вообще не потребоваться ни одного регистра.

Не первый раз несете эту и не только эту ахинею sad.gif. Я даже не поленюсь сделать copy-paste из ADSP-218x DSP Hardware Referencel
Код
Interrupt Latency
For the timer, IRQx, and SPORT interrupts, latency is at least three full
cycles from the time when an interrupt occurs to the time when the first
instruction of the service routine is executed. This latency is shown in
Figure3-2. Two cycles are required to synchronize the interrupt inter-
nally, assuming that setup and hold times are met (for the IRQx input
pins).

Итого не менее 3x, до 4x тактов, но там дальше и дополнение есть:
Код
Since interrupts are only serviced on instruction boundaries, before execu-
tion continues, the instruction(s) executed during these two cycles must
be fully completed, including any extra cycles inserted due to Bus
Request/Bus Grant or memory wait states.

Посему и более 4x тактов. Финиш.


Цитата(SBE @ Apr 20 2010, 19:13) *
Оно, конечно, что кошернее разделять время по приоритетам на уровне IST RTOS, только времена реакции будут совсем другими.

Времена реакции будут такими, какими НАДО. То, на что надо рекордно низкое время будет делаться в обработчике прерывания, причем без вложенности. Что-то помедленнее будет делаться в обработчике прерывания без вложенности и продолжаться далее в системе. То, что по ограниченности понимания тупо суется в длинный обработчик прерывания для которого разрешена вложенность и в результате этого НИ О КАКОМ детерминированном времени и говорить не приходится, будет делаться на уровне системы с гарантированными ею приоритетами и временами. В этом случае время затраченное на переключение контекста вполне сравнимо с небольшим обработчиком прерывания, который так или иначе будет прерывать текущий обработчик и ТОЖЕ должен заботится о сохранении контекста.
Dron_Gus
Который раз слышу заявление авторитетных людей, что в прерывании должен только флаг взводиться, все остальное - вне. Тогда на кой вообще использовать прерывания, а потом полить флаг? На мой скромный взгляд (в реальном мире я с 1985, а в эмбедед с 2000ых), таких идеальных случаев с флагами не бывает, поэтому всегда нужен "простор" в виде свободных регистров.

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

З.Ы. ни в коем случае не нарываюсь на холивар, просто интересуюсь.
zltigo
Цитата(Dron_Gus @ Apr 20 2010, 19:28) *
Который раз слышу заявление авторитетных людей, что в прерывании должен только флаг взводиться, все остальное - вне.
Тогда на кой вообще использовать прерывания, а потом полить флаг?

С операционными системами, Вы помнится знакомы. Посему вызывает интерес, почему поминается некий вырожденный случай с флагом? В обработчике прерывания может вызываться и планировщик. В последствии в зависимости от желания или сразу по выходу из обработчика, либо по отдаче/отборе управления от текущей задачи будет произведено переключение задач.
SasaVitebsk
Цитата(vallav @ Apr 20 2010, 18:56) *
Так это - так называемые преимущества RISC архитектуры.
Которая совершенно не годится для контроллеров и давно устарела для байтовых мельниц.

Договорились. smile.gif
А можно узнать что не устарело?

А я считаю, что RISС архитектура очень удачная. И плата за упрощение - достойная, а результат упрощения (скорость) оправдывается. В данном случае я не про cortex, а вообще.

Да и длинные обработчики - тоже имеют право на существование. Давайте исходить из того, что подходов к решению разных задач может быть много. Иначе надо объявить всех, кто продумал приоритеты, разработал и использует - идиотами. Но это большая группа людей. Как минимум надо задуматься об этом.
Dron_Gus
Цитата(zltigo @ Apr 20 2010, 21:39) *
С операционными системами, Вы помнится знакомы. Посему вызывает интерес, почему поминается некий вырожденный случай с флагом? В обработчике прерывания может вызываться и планировщик. В последствии в зависимости от желания или сразу по выходу из обработчика, либо по отдаче/отборе управления от текущей задачи будет произведено переключение задач.

Да, знаком.
Я в том смысле, что любой вызов сервисов ОС требует некоторого "простора" в плане регистров. Т.е. с этой точки зрения сокрушаться по поводу невозможности отключить автоматическое сохранение контекста не имеет смысла. Даже если сразу после выхода из прерывания произойдет смена контекста, на эту смену все равно тратиться какое-то значительное (в масштабах входа/выхода из прерывания) время. Т.е. используя сервисы ОС быстрой реакции не получить и скорость входа/выхода в прерывание тут принципиальной роли не играет.
Значит, если нужна быстрая реакция, часть логики должна находиться в самом обработчике прерывания. И опять же нужен "простор" в виде свободных регистров.
Идеально простые случаи, обычно, решаются с помощью различных модулей МК (таймеры, ДМА и т.д.).
Поэтому я не вижу смысла в "голых" прерываниях, без свободных регистров.

ИМХО. smile.gif
SBE
Цитата(zltigo @ Apr 20 2010, 21:27) *
Времена реакции будут такими, какими НАДО. То, на что надо рекордно низкое время будет делаться в обработчике прерывания, причем без вложенности. Что-то помедленнее будет делаться в обработчике прерывания без вложенности и продолжаться далее в системе. То, что по ограниченности понимания тупо суется в длинный обработчик прерывания для которого разрешена вложенность и в результате этого НИ О КАКОМ детерминированном времени и говорить не приходится, будет делаться на уровне системы с гарантированными ею приоритетами и временами. В этом случае время затраченное на переключение контекста вполне сравнимо с небольшим обработчиком прерывания, который так или иначе будет прерывать текущий обработчик и ТОЖЕ должен заботится о сохранении контекста.

Вы все сводите к понятиям короткий/длинный обработчик и считаете все прерывания равноценными. Нет темы для обсуждения когда прерывания равноприоритетны и самый длинный обработчик достаточно "короткий" с точки зрения блокировки для всех прочих прерываний. А если не так?
Да, в потоке обработки прерывания приоритеты разрулятся, но что ни говорите, там переключение контекста и время входа совсем другого порядка, чем при аппаратном входе в прерывание. Говорите о детерминированном времени, но только для ПЕРВОГО пришедшего прерывания, и теряете детерминированность для наиболее ПРИОРИТЕТНОГО (или априори считаете наиболее приоритетным первое пришедшее, что имеет право быть, но только как частный случай).
Оцените сколько занимает в ваших системах на ARM7 блокировка прерываний самым длинным из обработчиков, какими бы короткими они не были. Сколько занимает вход в поток обработки прерывания в вытесняюшей RTOS. Сколько в целом дополнительно ресурсов производительности скушает поток обработки, запущенный единственно с целью минимизировать блокировку прерываний ISR. И сравните с 12 тактов вытеснения прерывания в Cortex.

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

В общем, попробуйте, может и вам понравиться. smile.gif Мне понравилось, конечно далеко не для всех задач актуально, но бывает очень хорошо ложиться.



Цитата(klen @ Apr 20 2010, 19:27) *
середина 80х - это гдето так 75год, а выпустили 8080 в апрель 1974. Это че ? они доступны в СССР'е были сразу? и лет Вам было 15. Ну наверно меется девяностые (80-89гг), я так думаю.

Помню, на любительском уровне К580ИК80 появилось в 80г, журнал Радио, МИКРО-80 или как-то так. Знать быстро тогда слизали, был еще порох...

Цитата
- ну че мешало сделать механизм отменяющий автоматическое сохраниеие - НИЧЕ НЕДЕЛАТЬ ВСЕГДА ПРОЩЕ ЧЕМ ЧТОТО ДЕЛАТЬ.

Можно погадать, что полагали, что совсем без РОН в RISС архитектуре в обработчике делать нечего, хоть что-то надо пушить. Может быть учитывали, что деление 12 тактов и не прерывается вроде, т.е. 12 тактов латентности уже будет.
Может было нужно иметь унифицированый набор для Tail-chaining.
И точно задавались благой целью иметь обработчики прерывания в виде обычной С-шной функции без всяких спец.директив. Соотвественно и контекст должен быть при вызове функции обычный.
vallav
Цитата(zltigo @ Apr 20 2010, 21:27) *
Не первый раз несете эту и не только эту ахинею sad.gif. Я даже не поленюсь сделать copy-paste из ADSP-218x DSP Hardware Referencel
Код
Interrupt Latency
For the timer, IRQx, and SPORT interrupts, latency is at least three full
cycles from the time when an interrupt occurs to the time when the first
instruction of the service routine is executed. This latency is shown in
Figure3-2. Two cycles are required to synchronize the interrupt inter-
nally, assuming that setup and hold times are met (for the IRQx input
pins).

Итого не менее 3x, до 4x тактов, но там дальше и дополнение есть:
Код
Since interrupts are only serviced on instruction boundaries, before execu-
tion continues, the instruction(s) executed during these two cycles must
be fully completed, including any extra cycles inserted due to Bus
Request/Bus Grant or memory wait states.

Посему и более 4x тактов. Финиш.


И чего Вы такой нервный?
Ну ошибся я, это ( один такт латентности ) для более ранних моделей.
"For the timer interrupt of the ADSP-2101, ADSP-2105, ADSP-2115, ADSP-2111 and
ADSP-21msp50 processors the latency from when the interrupt occurs to when the first
instructions of the service routine is executed is only one cycle"
На картинке - первая команда обработчика ( которая не обязательно команда пернехода )
выполняется через цикл после того цикла, в котором обнуляется таймер.

Для асинхронных прерываний написано так, как Вы процитировали.
Но на рисунке первая комманда обработчика выполняется через два цикла после того цикла,
в котором обнуляется значение на входном пине.

Почему в ADSP-2181 для таймера вместо одного цикла три - для меня загадка.
Может в описании ошибка?
И тогда получается, что ахинею несете Вы...



Цитата(SasaVitebsk @ Apr 20 2010, 22:32) *
А можно узнать что не устарело?

А я считаю, что RISС архитектура очень удачная. И плата за упрощение - достойная, а результат упрощения (скорость) оправдывается. В данном случае я не про cortex, а вообще.


Что для контроллеров не устарело?
На мой взгляд - идеальным контроллером был ADSP-2XXX от ADI.
Предельно малая латентность прерываний, переходы по значению на внешнем пине, комманды изменения значения на внешнем
пине, не использующие регистры, циклы с нулевой затратой на обслуживание. А самое для меня вкусное - программная пересылка
слова на внешних пинах в циклический буфер в ОЗО со скоростью один такт на слово.

А в RISC - в именно удача? То, что они сейчас по скорости в три раза меньше CISC?
Или в том, что все контроллерные операции в них требует от двух до трех комманд?
Единственное достоинство RISC на текущий момент - чипы дешевые.


Цитата(SasaVitebsk @ Apr 20 2010, 22:32) *
Да и длинные обработчики - тоже имеют право на существование. Давайте исходить из того, что подходов к решению разных задач может быть много. Иначе надо объявить всех, кто продумал приоритеты, разработал и использует - идиотами. Но это большая группа людей. Как минимум надо задуматься об этом.


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



Цитата(SBE @ Apr 21 2010, 03:43) *
Можно погадать, что полагали, что совсем без РОН в RISС архитектуре в обработчике делать нечего, хоть что-то надо пушить.


Меня в свое время заинтересовало, чего путного может сделать обработчик прерываний в кортексе не портя
регистров. Нашел! Вывести процессор из ожидания прерывания. Или даже этого не может?
А если серьезно - можно один и ли пару регистров зарезервировать и держать в них нужные для обработчиков адреса.
zltigo
Цитата(SBE @ Apr 21 2010, 01:43) *
Вы все сводите к понятиям короткий/длинный обработчик и считаете все прерывания равноценными.

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

Есть.
Цитата
..и самый длинный обработчик достаточно "короткий" с точки зрения блокировки для всех прочих прерываний. А если не так?

Если это "не так", то значит при написании оного Вы продолжаете мыслить исходя из того, что системы нет, есть только прерывания.
Цитата
там переключение контекста и время входа совсем другого порядка, чем при аппаратном входе в прерывание.

Другого порядка? Для толстого обработчика прерывания и для переключения задачи так или иначе нужно сохранить/восстановить все регистры. Для шедулера, естественно, кроме этого нужно сохранять/восстаноаливать и дополнительно с TCB, но он никак не на порядок больше пула регистров и в минималистичном варианте буквально несколько слов. Дальше время работы планировщика. В маленьких осях оно более,чем скромное. Откуда "другой порядок"? Для действительно неприоритетных(потом очередь дойдет),или наоборот приоритетных обработчиков(все срочное в прерывании сделали), не вызывающих непосредственного переключения задач вообще вызывается только шедулер.
Цитата
Говорите о детерминированном времени, но только для ПЕРВОГО пришедшего прерывания, и теряете детерминированность
для наиболее ПРИОРИТЕТНОГО (или априори считаете наиболее приоритетным первое пришедшее, что имеет право быть, но только как частный случай).

Ни в коем разе. Детерминированность совершенно не означает волшебное и мгновенное исполнение для всех. Детерминированность 2ms, это такая-же детерминированность, как и детерминированность 2us. Именно Вы навешивая гирлянды вложенных обработчиков обеспечиваете (точнее пытаетесь обеспечить, если не прервут) максимально быструю реакцию на последнее прерывание. Только зачем-то поминаете слово детерминированность, хотя ни ее ни быстрой реакции у Вас нет ни для кого, кроме одного единственного обработчика у которого вложенные прерывания запрещены. Один. Только один обработчик. Для ARM7 на котором работает система таким экстремально приоритетным и экстремально быстрым обработчиком является FIQ.
Цитата
В общем, попробуйте, может и вам понравиться. smile.gif Мне понравилось, конечно далеко не для всех задач актуально, но бывает очень хорошо ложиться.

Какими словами Вам еще объяснить, что все, то я уже давно "попробовал" и УЖЕ так не делаю в проектах отличающихся по сложности от "контроллера светодиода".


Цитата(vallav @ Apr 21 2010, 08:03) *
Почему в ADSP-2181 для таймера вместо одного цикла три - для меня загадка.
Может в описании ошибка?
И тогда получается, что ахинею несете Вы...

Не три, а не менее трех. Да. Да. Немедленно сообщите об ошибке а AD. Пусть наконец исправят :E.
SasaVitebsk
Цитата(vallav @ Apr 21 2010, 09:03) *
Конечно имеют. Но не за счет того, что при этом нереализуемы короткие обработчики с малой латентностью.
А вот при чем тут приоритеты - мне не понятно.

Да приоритеты тут притом ...
... Делать короткие обработчики с равным приоритетом, пусть даже суперкороткие, всё равно, как уже отметили, латентность будет определятся по формуле "реакция камня + самый длинный обработчик". И тут выигрыша нет практически никакого.
Я так понимаю, что весь шум из-за того что были IRQ и FIQ. Причём FIQ мог прерывать IRQ безболезненно и с минимальными затратами. Таким образом можно было сделать 1 прерывание высокого приоритета с малой латентностью. И я этим пользовался. Как правило, для МК 1 прерывание более высокого уровня достаточно для решения большинства задач. Intel это понял ещё при разработке x51.

А можно узнать какие CISC процы "в несколько раз" быстрее выполняют команды? А то как то на слуху, что некоторые CISC процы в своём составе давно имеют RISC ядро.
zltigo
Цитата(SasaVitebsk @ Apr 21 2010, 08:53) *
Как правило, для МК 1 прерывание более высокого уровня достаточно для решения большинства задач.

Это не "правило". Это жестокая реальность которую не обойти, даже если очень хочется. Самый-самый может быть только один. Совсем один. Если его кто-то прерывает, то он не самый-самый. Организация вложенных прерываний это и есть обходой маневр для создания этого единственного самого-самого главного. На ARM7 таким самым главным был реализованный в железе FIQ. В M3 упростили и сделали по простейшей схеме, как в начале микропроцессорной эры.
vallav
Цитата(zltigo @ Apr 21 2010, 10:47) *
Не три, а не менее трех. Да. Да. Немедленно сообщите об ошибке а AD. Пусть наконец исправят :E.


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

Кстати, а что Вас так тянет немедленно сообщать в AD об ошибках?

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


Цитата(SasaVitebsk @ Apr 21 2010, 10:53) *
А можно узнать какие CISC процы "в несколько раз" быстрее выполняют команды? А то как то на слуху, что некоторые CISC процы в своём составе давно имеют RISC ядро.


Вы не знаете ни одного CISC проца с тактовой выше трех гигов?
А что у него внутри - сложно у него внутри.
Вам чистый RISC на шесть гигов тактовой часто встречается?
На три гига?
Сколько команд нужно ( не считая спасения регистров ) чтобы в кортексе обработчик прерывания дернул внешнюю ногу?
Я знаю контроллер, в котором - одна и регистры не нужны. Но это естественно не RISC.
klen
Цитата(vallav @ Apr 21 2010, 11:17) *
Вы цитату, которую я привел - прочли?
Я знаю контроллер, в котором - одна и регистры не нужны. Но это естественно не RISC.


а RISC обязан быть load-modify-store машиной (спрашиваю потому что я просто не знаю)?, если нет то какая разница, если будет инструкция сразу пишушая на шину результат операции то ногу дергать в прерывании без использования регистров одной инструкцией сможет и RISC. Меня академически вычислительной технике никто не учил, самому интересно было поэтому не силен, но по моему мнению глядя устройство управления процессора (УУ) нельзя сказать что оо есть - где граница между комплексным набором инструкций и уменьшеной, да плюс еще некоторые оригиналы транслируют cisc инструкции во внутренний риск формат - а это что за архитектура..
msalov
Цитата(klen @ Apr 21 2010, 10:40) *
а RISC обязан быть load-modify-store машиной (спрашиваю потому что я просто не знаю)?
Не обязан. Пример MSP430
SasaVitebsk
Цитата(klen @ Apr 21 2010, 10:40) *
... да плюс еще некоторые оригиналы транслируют cisc инструкции во внутренний риск формат - а это что за архитектура..

Так о том и речь. Начиная с PII, по-моему, CISC уже не является CISC в оригинале. Там всунуто RISC ядро исполняющее микрокод. Аналогично поступил и DEC. Это самое яркое доказательство. Именно поэтому потом добавляются команды и прочее...

Цитата(zltigo @ Apr 21 2010, 10:09) *
Это не "правило". Это жестокая реальность которую не обойти, даже если очень хочется. Самый-самый может быть только один. Совсем один. Если его кто-то прерывает, то он не самый-самый. Организация вложенных прерываний это и есть обходой маневр для создания этого единственного самого-самого главного. На ARM7 таким самым главным был реализованный в железе FIQ. В M3 упростили и сделали по простейшей схеме, как в начале микропроцессорной эры.

Ну, после начала МП эры, много воды утекло. Прижился, и стал нормой вариант где "один - самый главный" - не правило. Разработано много вариантов. Чем плохо - если бы уровней былобы 3, к примеру? Но у ARM7 этого не было. То есть назвать его идеалом, по этому показателю, тоже сложно.
Ну а если не идеал, то здесь можно рассматривать как соотношение отходов от идеала. Поменяли один вариант на другой. Вот и всё.

Просто получилось что для вас, это ухудшение. Ну а тем, кому необходимо было 3 уровня приоритетов - до лампочки. Было не очень - стало не лучше. Некоторым, которые работают с 2 и более уровнями, но высокоприоритетных прерываний у них больше одного, - им стало лучше. Или, как минимум, не хуже. Простой размен.
vallav
Цитата(klen @ Apr 21 2010, 11:40) *
да плюс еще некоторые оригиналы транслируют cisc инструкции во внутренний риск формат - а это что за архитектура..


Ага. И, чтобы CISC инструкции выполнялись за такт на частоте 3 гига, внутренний RISC у них работает на тактовой в 9 гиг.
А плавающее умножение ( оно тоже за такт делается ) делает внутренний RISC на частоте...

Умер RISC. Тогда, когда основным ограничением тактовой частоты стала не задержка в сложной логике а задержка в передаче
сигнала с одного края чипа на другой.
Так что похоже наблюдаемый оживлеж в ARM контроллерах - это предсмертные судорги.
Которыми, конечно, не грех воспользоваться...
zltigo
Цитата(SasaVitebsk @ Apr 21 2010, 12:42) *
Ну, после начала МП эры, много воды утекло.

Вы совсем не поняли, о чем я писал. Или я совсем не понимаю, о чем Вы пишите sad.gif
Цитата
Прижился, и стал нормой вариант где "один - самый главный" - не правило. Разработано много вариантов.

Да, многоядерные системы с числом ядер равным числу источников прерываний. Искать по слову Paralax http://www.parallax.com/
Цитата
Просто получилось что для вас, это ухудшение. Ну а тем, кому необходимо было 3 уровня приоритетов - до лампочки.

Да причем тут вообще приоритеты - хоть два, хоть 2222. В конце концов ядро захватить может только ОДИН, совсем один и всем прочим собьет всю их "детерминированность" нафиг. На одноядерном контроллере только один единственный обработчик может быть главным. Посему максимально-полезное число уровней всего два sad.gif. Главный имеющий право на ядро всегда и сразу, когда захочет и прочие. Как уже прочие будут делить ядро между собой - культурненько, через операционку, или грубо и тупо через вложенные прерывания по праву сильного/первого/последнего никому кто слабее/раньше/позднее не гарантируя НИЧЕГО, дело второе. Какой выбор считаю предпочтительным я, Вы наверное, поняли smile.gif
SasaVitebsk
2 zltigo. Я абсолютно понимаю о чём вы пишете и писали. Но пытаюсь быть объективным, а не однобоким.

Пример (условный):
Есть 10 обработчиков прерываний.
INT нужна латентность минимальная. Обработчик занимает 30мкс.
4 прерывания PWM. Нужна реакция 50мкс. Занимает 2мс.
Остальные прерывания допустимы в пределах 10мс.
Если бы у контроллера были бы 3 уровня, то я бы присвоил для INT - найвысший, для PWM - средний, для остальных - найнизший.

Вопрос - как это сделать в ARM7?

Я просто пишу, что есть ограничения и у ARM7 и у Cortex. У одного больше у другого меньше, но какая разница? Все имеют ограничения и с ними придётся считаться.
zltigo
Цитата(SasaVitebsk @ Apr 21 2010, 20:10) *
4 прерывания PWM. Нужна реакция 50мкс. Занимает 2мс.

На этом можно и закончить - обработчик с реакцией в 50us не может занимать времени в 40 раз больше. Он должен закончить работу за те-же 30-50us выдав ту самую "реакцию". Остальное должно делаться за время 2000us или более(до следущего прерывания) за пределами обработчика.
Цитата
Я просто пишу, что есть ограничения и у ARM7 и у Cortex. У одного больше у другого меньше, но какая разница?

И для меня - никакой. Порядок реакции один и тот-же, а вложенность образовавшаяся у M3 мне нужна только, как возможная замена FIQ.
Corteх-M3, ака LM3S6xxx, надеюсь, вскоре использовать. По причине Ethernet PHY.
_Макс
Экспериментирую с GPIO и обнаружил, что GPIOB_ODR инициализируется вовсе не 0x0000, как написано в даташите, а значением 16. Откуда оно, ума не приложу.
sonycman
Цитата(_Макс @ Apr 22 2010, 13:13) *
Экспериментирую с GPIO и обнаружил, что GPIOB_ODR инициализируется вовсе не 0x0000, как написано в даташите, а значением 16. Откуда оно, ума не приложу.

Как откуда? А про JTAG забыли? На STM пины житага отнюдь не выделенные, а висят прямо на портах GPIO.
В данном случае - это подтяжка (пуллап) линии JTRST.

Можно отключить житаг через ремап, тогда этими пинами можно будет пользоваться в своё усмотрение.
_Макс
Цитата(sonycman @ Apr 22 2010, 21:10) *
В данном случае - это подтяжка (пуллап) линии JTRST.

Вы правы.
Karim
Позвольте вопрос по Z состоянию пина без подтяжек. У AVR с этим бардак. А про STM32F103x написано:
Ilkg Input leakage current (5) VSS ≤VIN ≤VDD Standard I/Os ±1 μA
5. Leakage could be higher than max. if negative current is injected on adjacent pins.
( Из STM32F103x6 STM32F103x8 STM32F103xB Performance line Preliminary Data)
Имеется ли информация по реальным утечкам в плюс и минус питания, или может он тоже генерит изнутри наружу?
В одном проекте контроллер с чистым Z попиново очень помог бы.
Спасибо.
sonycman
Цитата(Karim @ Apr 23 2010, 12:32) *
В одном проекте контроллер с чистым Z попиново очень помог бы.
Спасибо.

А как понять "с чистым Z"?
Совсем без тока утечки, или с постоянным током?
Karim
Как обычно- симметрично половины питания, другими словами утечка из пина в минус идентична утечке из плюса в пин, чтоб вольтметр подключенный к фиксированной половине питания и пину в Z состоянии показал 0 вольт. Т.е. честное ВЫСОКОИМПЕДАНСНОЕ.
Вроде про LPC1111 так как надо. но перед железномягкими телодвижениями в сторону новой платформы хотелось услышать мнение специалиста.
Нажмите для просмотра прикрепленного файла
zltigo
Цитата(Karim @ Apr 23 2010, 16:59) *
..хотелось услышать мнение специалиста.

Рассчитывая на определенность в поведении токов утечек Вы твердо стоите на пути изобретния дерьма. Вне зависимости от платформы.
Karim
Спасибо.
Другие мнения есть?
Кто проверял STM32F103x по Z состоянию, будте добры, отпишитесь.
Serj78
Отлаживаю проект "в железе" на STM32F103VИ (100пин корпус)

После первого включения проконтролировал общий ток, получил 110ма и успокоился, т.к есть еще 6 датчиков и они что-то жрут, а старая конструкция на 2-х мегах жрала на 15ма больше...

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

И сейчас дошло - ОН ВСЕ ВРЕМЯ РАБОТАЛ НА 144 МГц!! (кварц на отладочной плате был 8 Мгц, в живом железе на 16 Мгц, а множитель в PLL я переставить забыл. 07.gif )
Ivan Kuznetzov
привет всем! тоже занялся проблемой SDIO на STM32F103VE.
1) Mass Storage работает хорошо, но только с картами емкостью до 8 Гб включительно. при 16 Гб карте получаю "Устройство УСБ не опознано" Может кто пробовал с 16Гб ? rolleyes.gif
2) FatFs тоже работает - но тут прикол еще хлеще - пожоду переполнение адресации при выполнении Disk_read. Выражается следующим образом: карта на 8Гб почти полностью заполнена, записывю на нее еще один файлик с ПК. Вставляю карту в проект, в проекте тупо поблочное копирование этого файлика в другой. Прогнал. карту снова в пк. В скопированном файлике содержимое другого файла!

В обоих проектах использую stm32_eval_sdio_sd.c из стандартного набора библиотек
anpaza
Цитата(Ivan Kuznetzov @ Oct 2 2010, 17:29) *
привет всем! тоже занялся проблемой SDIO на STM32F103VE.
1) Mass Storage работает хорошо, но только с картами емкостью до 8 Гб включительно. при 16 Гб карте получаю "Устройство УСБ не опознано" Может кто пробовал с 16Гб ? rolleyes.gif

SD карточки до 4Гб используют один протокол, свыше 4Гб - другой.
Возможно, с этим как-то связано. Почему у Вас граница на 8ми - не знаю.
drifterrr
Цитата(KRS @ Mar 11 2008, 16:38) *
Все еще мучаю STM32F103. Пока чип работает хорошо.
Кстати у него очень удобная реализация CAN - 2 fifo (что мне удобнее чем куча mailbox) и много довольно гибких фильтров.
И еще тут обнаружил что APB1 (на ней и CAN висит ) работает (по даташиту) максимум на 36 Mhz, т.к. я на это внимания не обратил у меня APB1 и CAN на ней работают на полной скорости 72 Mhz ( глюков не было), но скорость я конечно все равно понижу до 36.

Добрый день. Подскажите, пожалуйста, кто разобрался, как поменять пины, на которые выводится кан интерфейс? Мне нужно сделать это по ходу программы. То есть я подключил два Кан трансивера: на пины а11а12 и на в8в9. Стартую без ремапа, работаю с А. Затем делаю ремап и работаю с Б. А дальше сделать ремап с Б на А не выходит. Это вообще возможно?
x893
конечно возможно
drifterrr
Цитата(x893 @ Jun 4 2017, 12:45) *
конечно возможно

В таком случае прошу помощи в поиске ошибок. Вероятно, в библиотеке. Прошу прощения, что код из среды ардуино.
CODE
#include <HardwareCAN.h>
//#include "changes.h"
/*
*
*/

#define T_DELAY 10
// Instanciation of CAN interface
HardwareCAN canBus(CAN1_BASE);
CanMsg msg;

void CAN_a_33_Setup(void)
{
CAN_STATUS Stat;
canBus.map(CAN_GPIO_PA11_PA12);
Stat = canBus.begin(CAN_SPEED_33, CAN_MODE_NORMAL);
canBus.filter(0, 0, 0);
canBus.set_irq_mode();
Stat = canBus.status();
if (Stat != CAN_OK)
{digitalWrite(PC13, LOW);
delay(10000);}
// /* Your own error processing here */ ; // Initialization failed
// delay(T_DELAY);
}

void CAN_b_95_Setup(void)
{
canBus.map(CAN_GPIO_PB8_PB9);
Stat = canBus.begin(CAN_SPEED_95, CAN_MODE_NORMAL);
canBus.filter(0, 0, 0);
canBus.set_irq_mode();
Stat = canBus.status();
if (Stat != CAN_OK)
{digitalWrite(PC13, LOW);
delay(10000);}
// /* Your own error processing here */; // Initialization failed
// delay(T_DELAY);
}


CAN_TX_MBX CANsend(CanMsg *pmsg)
{
CAN_TX_MBX mbx;

do
{
mbx = canBus.send(pmsg);
#ifdef USE_MULTITASK
vTaskDelay( 1 ); // Infinite loops are not multitasking-friendly
#endif
}
while(mbx == CAN_TX_NO_MBX); // Waiting outbound frames will eventually be sent, unless there is a CAN bus failure.
return mbx;
}

// Send message
// Prepare and send a frame containing some value
void SendCANmessage(long id=0x001, byte dlength=8, byte d0=0x00, byte d1=0x00, byte d2=0x00, byte d3=0x00, byte d4=0x00, byte d5=0x00, byte d6=0x00, byte d7=0x00)
{
// Initialize the message structure
// A CAN structure includes the following fields:
msg.IDE = CAN_ID_STD; // Indicates a standard identifier; CAN_ID_EXT would mean this frame uses an extended identifier
msg.RTR = CAN_RTR_DATA; // Indicated this is a data frame, as opposed to a remote frame (would then be CAN_RTR_REMOTE)
msg.ID = id; // Identifier of the frame : 0-2047 (0-0x3ff) for standard idenfiers; 0-0x1fffffff for extended identifiers
msg.DLC = dlength; // Number of data bytes to follow

// Prepare frame : send something
msg.Data[0] = d0;
msg.Data[1] = d1;
msg.Data[2] = d2;
msg.Data[3] = d3;
msg.Data[4] = d4;
msg.Data[5] = d5;
msg.Data[6] = d6;
msg.Data[7] = d7;

digitalWrite(PC13, LOW); // turn the onboard LED on
CANsend(&msg); // Send this frame
digitalWrite(PC13, HIGH); // turn the LED off
delay(T_DELAY);
}


// The application program starts here
byte msgD0 = 0x00;
void setup() { // Initialize the CAN module and prepare the message structures.
pinMode(PC13, OUTPUT);
digitalWrite(PC13, HIGH);
delay(10);
digitalWrite(PC13, LOW);
delay(1000);
digitalWrite(PC13, HIGH);
delay(1000);

}

void loop() {
CAN_a_33_Setup();
delay(T_DELAY);
SendCANmessage(0x100,1,msgD0);
delay(T_DELAY);
CAN_b_95_Setup();
delay(T_DELAY);
SendCANmessage(0x111,1,msgD0);
delay(T_DELAY);
msgD0++;
}

Ссылка на библилтеку (5 значимых файлов):


https://github.com/megadrifter/Arduino_STM3...HardwareCAN/src
И файл https://github.com/megadrifter/Arduino_STM3...e/series/gpio.h
drifterrr
Ответ:
afio_init();
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.