Axel

Видимо не выживаться: внутренней подтяжки может элементарно не хватить для приличного уровня помех - там десятки килоом.

Ну почему же, вполне себе вариант в определенных обстоятельствах. В данном же случае - интерфейс работающий, не без нюансов, но "...всю Одессу удовлетворяет..."©

Обманул, для 103-го дома не оказалось. Есть только для F4xx и для F030, но они вроде очень похожи. Посмотрите... f030_i2c.zip

Кривоватый конечно, но работает. Если может помочь код, не использующий либы, могу поделиться работающим примером для EEPROM (STM32F103)

В Simulink есть поддержка AUTOSAR. На их сайте есть демо ролик. Кое-что можно понять...

Свежий STVP v3.3.1 поддерживает.

Вряд ли... В этом случае логично было бы увидеть "всегда нужно перезаливать" вместо "всегда можно".

Естественный вопрос... если бутлоадер является самой сложной частью системы.

:rolleyes:

Дык вселенная здесь не при чем. Источник шуток наверняка располагается где-то между стулом и клавиатурой. Вас не смущает, что у 24С256 размер страницы 64 байта?

Несколько субъективное утверждение. "просче" - вопрос критериев. С точки зрения занимаемого Flash-а standalone бутлоадер плюс одна аппликация почти наверняка меньше простого бутлоадера плюс две аппликации. Кроме того - средства для переключения между версиями, риски при перезагрузке очередной "надежной"версии...Ессно можно представить экзотические ситуации, когда это оправдано, например если для апгрейда используется USB и втечение жизни девайса допускается возможность смены его VID/PID, а так...

Так вроде I2C_CR1_SMBHEN (3-й бит в CR1) здесь не при делах (если Вы действительно говорите про I2C, а не про SMBUS). Рекомендация по поводу собаки видится по-прежнему актуальной...

Сомнительный путь для отсева сомнений (ИМХО)... А регистры в отладчике просматривали?

Ну прям сердце разрывается... Итак: 1. ST-шный I2C работает. Проверено на разных STM32 и STM8. 2. ST-шный I2C производит впечатление недоделанного курсового. Причина ворчания (одна из) - удивительные упражнения с ACK-ом и STOP-ом в конце приема. 3. ST-шные примеры малополезны по причинам: а) используют весьма нелюбимую мной либу б) не облегчают понимание в) абсолютно не гарантируют отсутствие (или уменьшение) проблем при попытке их адаптации под свои нужды Теперь советы (естественно только ценные): 1. Детально разобраться с регистрами (по мануалу, на всякие AN-ы не заморачиваться), после чего сконфигурить порт по собственному разумению 2. Разрешить клоки на I2C (RCC->APB1ENR) и GPIO (RCC->APB2ENR). Не забыть про бит 0 в RCC->APB2ENR. 3. Начать изучать поведение пинов с команды I2C1->CR1 |= (1 << 8) (старт)

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

Конечно, Вы правы. Но все-таки это из разряда "Если нельзя, но очень хочется - то можно...".

"Категорический" недостаток - невозможность апгрейда совместно используемых фрагментов. Остальное - просто дополнительные хлопоты по их размещению и интерфейсу.

Может и поможет, только смысла в этом совете не больше, чем в моем предыдущем. У меня внешняя SRAM без всяких реверансов работает с LPC17 и с STM32F1/F4. Беда где-то в другом месте...

"Не получается правильно - делай наоборот"©. Не пробовали вместо *pBuffer++ написать *(pBuffer++) ?

У меня работает похожий вариант: дисплей 16-битовой шиной подключен к матрице, которая либо сама гонит данные из SFLASH, либо транслирует их из FSMC контроллера (STM32F437). Тайминги для FSMC подбирал по осциллографу, чтобы более-менее уложиться в требования даташита контроллера дисплея (цикл шины - 145ns). Для CPLD задача была противополжная - успеть загрузить экран за 20ms. Никаких "слишком белых" проблем не отмечено...

Из Standby от USB непсредственно не просыпается. Я использую RTC wake up для периодического контроля подключения USB. Можно естественно и аппаратно, если прицепить USB-шные 5V к PA0, PC13 или PI8

Отключение тактирования точно ничего не сбрасывает. Так что - или регистры RSTR, или общий ресет.

Даже Ваши 460800 это как-то не совсем USB-шные теоретические 12Мb... Что мешает - не знаю. Знаю, как работают функции bulk_read из известных мне драйверов. Знаю (из собственного опыта), что "обычный" bulk-обмен (с фиксированным размером пакета) достаточно легко пoзволяет скорости до 750kB/s и работает часами без потерь информации, а моя единственная (может быть не очень умелая) попытка организовать обмен пакетами пермеменной длины с приемлемой (более 300 kB/s) скоростью закончилась такими же результатами, как и те, что имеет сообщество с виртуальным (не FTDI) COM

Виртуальный COM, как отмечалось, использует bulk трансфер. PC-шные bulk-драйверы умеют принимать только заранее известный объем данных. Для передачи этой информации используются дополнительные interrupt ендпоинты. Оба типа обменов, естественно, должны быть жестко засинхронизированы. Именно потерями на синхронизацию объясняется невозможность достижения максимальнх скоростей при использовании FTDI. И именно проблемами этой синхронизации (IMXO) объясняются обсуждавшиеся потери информации в направлении девайс - РС.

При балк обмене драйвер хоста должен знать размер принимаемого пакета, иначе он выйдет из приема по таймауту с потерей информации. Именно для передачи этого знания используется ЕР2, а через ЕР1 идут собственно данные. Если Вам просто нужно организовать обмен и не строго использовать Virtual Com или HID, то (ИМХО) самый простой путь - выдрать из либы минимум для балк обмена и определить фиксированную длину пакета. Со стороны хоста - libusb или winusb. Они достаточно хорошо описаны и несложны в использовании, правда (как и все остальные) не снимают геморроя при удаленной инсталляции, особенно под Windows8.