Вот программы для семинара ST.

Апликация STM32Cube и лабораторные работы с инструкциями как пользоваться.
https://www.dropbox.com/sh/eqim95c9s2sspqn/...8vSdRW4P3a?dl=0

За час можно склепать простой проект, а потом использовать сгенерированный код для развития проекта. Лицензию на IAR IDE дадут на короткое время, но если выбрат' при генерации проекта toolchain SW4STM32, то можно обойтись бесплатными инструментами.

Из платных поддерживаются:
EWARM
MDK-ARM V4
MDK-ARM V5
TrueStudio

В многозадачной среде есть необычные delay(), которые в момент отдыха данной задачи отдают управление менее приоритетной задаче.

I2C не сильно-то нагруженный интерфейс, чаще всего, пару байт переслать раз в минуту/час. Это не SPI/I2S/Ethernet/CAN, которые чаще всего загружены "по полной".

Такие delay задают задержку в количестве тактов таймера планировщика задач, который имеет частоты обычно не более единиц кГц. I2C на такой задержке будет ну очень медленный.

У меня задачи переключаются с частотой 10000 раз в сек - это вполне нормальная скорость. I2C не для передачи изображений же используется

А Вы откуда знаете?
Мы в некоторых изделиях используем матричные ЖКИ висящие на I2C. А также FRAM-память на I2C размером в 32кБ.
В других изделиях есть ADE78xx работающая по I2C непрерывным потоком на макс. скорости.
Если Вы думаете, что I2C используется только для передачи пары байт и никаких других применений нет, то зачем в новых МК ввели I2C с SCL до 1МГц?

PS: Имхо - тактировать шедулер 10кГц можно конечно, но по-моему многовато - много накладных расходов на переключение задач. У меня обычно максимум 1кГц или меньше.

Кхе.... Весьма жирновато.
Еще для FreeRTOS с ARM LPC2148 48Мгц прикниул, что сохранение-переключение-востановление контекста в прерывании занимает 2.2 мкс
А тут период планировщика 100 мкс, то есть в этом случае 2.2% времени процессора будет тратиться на переключение контекста.



Тогда по паре таймеров на ядро еще бы.

Ну это ВЫ так используете, но в массе своей, практика показывает, что высоконагруженное I2C это экзотика, так же как и I2C в слейве со стороны МК. Никто же не спорит, что это не нужно или нереально, просто речь идет о том, что I2C в 99% случаев, для эмбеддера это мастер с небольшим объемом данных, и все эти мегагерцы на SCL и аппаратный I2C - просто не нужны.

Вы не представляете, как много всякого разного и вполне многозадачного можно сделать в рамках схемы Super Loop.

Все верно, даже добавить нечего, ибо эта шина создавалась именно для конфигурирования и управления блоками телерадиоаппаратуры фирмы филипс. А использовать жк экраны или другие высокоскоростные стриминговые устройства считаю нерациональным, ибо почти все они есть на более скоростном SPI, с которым работать куда приятнее.
ЗЫ. А так, если принципиально "упираться", можно и на 1wire дисплей повесить, но нужно-ли?

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

Сообщение отредактировал Огурцов - Jan 12 2016, 08:51

Да уже и есть наверно, только программирование линукс-онли, поэтому - обламингос

какой линукс, речь про что-то типа 2313, только лишь штук 256 в одном соике и на гигагерц тактовой

Ооо да!! Даже не представляю, как бы все это называлось

Хотя да, берете плисину на стопятьсот лог. вентилей и втюхиваете туда свои кучи ядер... Тут главное критическую массу не набрать, а то мало-ли что...

за доллар ? давайте

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

кстати интересная фича про перывания - как в с# - несколько ядер могут подписаться на одно прерывание

Сообщение отредактировал Огурцов - Jan 12 2016, 22:00

Ну, скажем, программный там и писать нечего. 5 строчек... )) И действительно лениво ... ))
Честно сказать в последнем проекте (stm32f407) так и есть. У меня там клава по I2C подключена. Она реализована на stm8 (slave). Казалось бы написать мастера - 2 пальца об асфальт. Ну у меня там специфика - хотел без прерываний сделать... На начальном этапе включил софтовый драйвер. Когда уже проект закончил - решил подключить аппаратный. Написал первоначальный вариант - виснет иногда. Перечитал всё - написал все возможные обработчики ошибок - виснет гораздо реже. Настолько редко, что выловить причину не смог. Плюнул - оставил софтовый.

А в LPC1764/65 действительно прекрасно работает. Да и на старом LPC2106 тоже не припомню проблем. На stm32f103 slave удалось нормально сделать. Через прерывания. Оно и на 407 наверное можно... просто жалко времени... ))