caxapa.ru :: Лень копаться в документации, но для таких сопроцессорных штук ИМХО нелишним будет какой-нибудь простой открытый протокол внутрисхемного программирования.

vmp (30.04.2013 10:28, просмотров: 143) ответил Evgeny_CD на Еще один взрыв моска. Семейство FreeScale KL05 и KL15. MKL05Z32VFK4 100 шт - $1.06 дижикей. MKL15Z128VFM4 100 шт - 1.78 - но в этом багов прилично.

Лень копаться в документации, но для таких сопроцессорных штук ИМХО нелишним будет какой-нибудь простой открытый протокол внутрисхемного программирования. Чтобы прошивку сопроцессора хранить где-то внутри основного процессора и по включении питания проверять и при необходимости перешивать сопроцессор без дополнительного оборудования.

Ответить

- Как там у KL* - пока не вкуривал, но у CF+ есть замечательный протокол а ля SPI для ISP. О нас позаботились :). Большинство из взрывомосковых Cortex, и ВСЕ XMEGA, которые мне попались за последнюю неделю, имеют выделенную область для бутлодыря, Evgeny_CD(68 знак., 30.04.2013 11:21)
  - Свой бутлодырь - это хорошо, но не для сопроцессора. Его использование добавляет лишнюю технологическую операцию (зашивку бутлодыря) и возможно лишние разъемы. - vmp(30.04.2013 16:30)
    - Поэтому мастер должен общаться со слейвом по SWD, если отсутствует заводской загрузчик. - SciFi(30.04.2013 16:34)
      - Да. Это сейчас перестало быть "военной тайной". А "всяческая секретность" (ежели таковая требуется) - в мастере. - Гудвин(30.04.2013 16:39)
  - Для мег (и иксмег) область бута - стандартная фича. У Кортексов не встречал такого. У кого есть? И не в ROM. - Apтём(30.04.2013 13:59)
    - так у них таблица векторов перемещаемая, на кой им эта радость? Nikolay801_(113 знак., 30.04.2013 14:09)
      - В любое место? Они же M0. Без +... - Apтём(30.04.2013 14:16)
        
        В M0 это тоже решается. Немного конечно через (_._) - в стандартных векторах прописываются редиректы на область целевой программы. - Гудвин(30.04.2013 14:39)
        
        Решается...через... Но этож прерывание будет медленней работать! - Apтём(30.04.2013 15:07)
        
        Одна команда... - Гудвин(30.04.2013 15:16)
        
        Три. Apтём(108 знак., 30.04.2013 15:23)
        
        Одна команда: "B isr" или "BL isr". - SciFi(30.04.2013 16:20 - 16:24, ссылка)
        
        B label может только на 2К переход сделать, что маловато будет. - Apтём(30.04.2013 16:59)
        
        Хватит. BL может на 16 МБайт, а сдвинуть стек при возврате несложно. Короче, варианты есть, если хочется побыстрее. - SciFi(30.04.2013 17:03)
        
        BL достанет, да. Сдвиг стека зачем делать? - Apтём(30.04.2013 17:11)
        
        Забыл, что ARM не пихает адрес возврата в стек :-) - SciFi(30.04.2013 17:12)
        
        Понятно. - Apтём(30.04.2013 17:16)
        
        Ну три. Не шибко уж и парит. Впрочем, подергал недавно LPC11U37 и LPC1347 и в том числе и по этой причине остановил выбор на втором - M3. Загрузчик пользую везде - лишние камлания ни к чему... - Гудвин(30.04.2013 15:28)
        
        Это к лучшему. Спешка нужна при ловле блох. Серьёзно -> - SciFi(30.04.2013 15:09 - 15:14, ссылка)
        
        Организм, неспособный написать бутлодыря без использования прерываний, чтобы не корячиться с перемещением векторов, должен покинуть биосферу :)) - MBedder(30.04.2013 14:59)
        
        Дело не в прерываниях. Надо гарантированно при сбросе попадать в загрузчик. А там, как правило, находятся и векторы. В AVR, M3 это не доставляет проблем. В ARM можно сделать ремап в RAM. С другим приходится извращаться. Высшаяя стадия идиотизма Гудвин(87 знак., 30.04.2013 15:13)
        
        А в чем проблема попадания в загрузчик? abivan(39 знак., 30.04.2013 15:40)
        
        "main" у нас где живет? В стартовой области вместе с векторами? Тогда я за AVR :) Да еще с его аппаратной защитой области загрузчика. - Гудвин(30.04.2013 16:04)
        
        main может жить где угодно. Вначале стартует загрузчик, потом, если загружать не надо, делает jp 0x1000, откуда есть jp _start. Нулевая страница, где вектора и загрузчик, в итоге прошивается раз в жизни. - fk0(30.04.2013 16:55)
        
        Как это все на сях, без асма организовать(размещение в 0-й странице), да еще чтобы загрузчик жил вместе с проектом в одной прошивке? - abivan(30.04.2013 17:31)
        
        Без *.as в *.c? asm("blablabla...") Только так не нужно делать. Вообще дело не в асме, а в объяснению правил компоновки линкеру. Причём два раза: для загрузчика и для программы. Где-то это делается правкой *.ld (*.gld) файла (GCC). Где-то fk0(1255 знак., 30.04.2013 17:41)
        
        Один файл нужен чтобы программатором все прошить. Чем плох вариант с размещением в последней странице? Реализуется полностью на си в одном проекте, только секцию линкеру для бутлодыря указать. И при отладке загрузчик не помешает. У модуля с бут abivan(38 знак., 30.04.2013 17:54)
        
        Вариант с последней страницей, очевидно, умирает при перезашивке первой в неудачный момент времени. Вообще первым стартовать всегда должен загрузчик, даже если основной программы нет. И секцию не одну. У загрузчика же не только text свой, fk0(675 знак., 30.04.2013 18:43)
        
        Все-таки очень хочется загрузчик не иметь отдельным проектом. Опасность потери прошивки это прошивка стартовой-й страницы. Для моего проца это 64байта 2ms. Это время кондер вытянет. С const согласен не прокатит, но вроде в загрузчике это не abivan(239 знак., 01.05.2013 20:21)
        
        Питание -- не единственная причина сброса. Я не расчитывал бы на конденсаторы (и они разряжены в момент могут быть...) Не вижу, чем плохо 2 проекта. Ведь и загрузчик-то пишется один раз за месяц для "аппаратной платформы", а на ней потом проекты fk0(26 знак., 01.05.2013 21:24)
        
        не скажи. В одном проекте загрузчик по USB из main прописывает дополнительную flash, потом вызывается boot и перепрошивается из доп flash в ПП. В другом проекте с флэшки записывается в неиспользованную ПП контроллера потом boot копирует прошивку. abivan(194 знак., 01.05.2013 22:50)
        
        Не совсем ... Apтём(181 знак., 01.05.2013 23:22)
        
        Ну в конце концов, не обязательно же, чтоб проект компилировался по нажатию именно F10 в MPLAB. Можно через bat или makefile собрать вначале одно, а потом второе... Причина сброса основная -- электромагнитное излучение. А уж как оно (не)попадает fk0(1365 знак., 01.05.2013 23:12 - 23:17)
        
        Наверное можно изголится и сделать такое. Тогда функцию которая загружает прошивку неплохо бы вызывать не из main, а до и даже раньше. Для такого подошло бы что-то типа ИАРовского __low_level_init - переменные ещё не инициализированы и значит не Apтём(68 знак., 01.05.2013 20:38)
        
        надо в startup лезть, а не понятно чем плохо вызов загрузчика из main. От порчи прошивки спасает расположение загрузчика в стартовой области и защиты ее от selfwrite. Иначе стартовый джамп может быть испорчен и в загрузчик мы никогда не попадем. abivan(99 знак., 01.05.2013 21:19)
        
        IMHO в embedded в startup надо лезть в 90% случаев: C-runtime стартует слишком медленно, а обычно хочется порты настроить быстрей нужным образом (чтоб всякие релюхи и т.п. зазря не клацало) и включить нужный тактовый генератор (ибо с дефолтным fk0(100 знак., 01.05.2013 21:27)
        
        надо в startup лезть, а не понятно чем плохо вызов загрузчика из main. От порчи прошивки спасает расположение загрузчика в стартовой области и защиты ее от selfwrite. Иначе стартовый джамп может быть испорчен и в загрузчик мы никогда не попадем. abivan(99 знак., 01.05.2013 21:13)
        
        Надо ли лезть в startup зависит от компилятора. В IAR AVR можно и не лезть - просто нужно написать функцию low_level_init в которую программа попадёт сразу после сброса и до очиски переменных. Apтём(439 знак., 01.05.2013 21:27)
        
        Нет уж. Я лучше буду и дальше держаться подальше от контроллеров профессионального уровня ;) Измываться над фирмварью, добавлять/удалять обработчики прерываний, как заблагорассудится, высылать клиентам прошивки, не заботясь о том, что они зальют Гудвин(57 знак., 30.04.2013 17:10 - 17:13)
        
        Вот видишь, точки над i расставлены. Контроллер проф. уровня требует, соответвенно подхода проф. уровня. А в любительских кортексах любители сходу могут в дружелюбных любительских IDE практически как на бейсике писать свои любителькие программы fk0(85 знак., 30.04.2013 17:44)
        
        MCS51 - ΚΑΚΟΓΟ UPOBHYA? INTERESNO JE... - _KLIM83(05.05.2013 08:48, )
        
        Конечно профессионального! - fk0(05.05.2013 13:22)
        
        Приятно видеть такой ответ. Спасибо за добрые слова. А еще, для антуража профессионального уровеня - внешняя 27с***. - KLIM83(05.05.2013 23:19)
        
        Щаз! 573РФ1 и только! - Evgeny_CD(05.05.2013 23:32)
        
        Нелогично. РФ2/5 тогда уж... - Гудвин(05.05.2013 23:41)
        
        Первые AVR были "ногосовместимые" с 51. Дык, получается AVR тоже? ;) - Гудвин(05.05.2013 13:27)
        
        Угу. С оттенками мазохизма :-) - SciFi(05.05.2013 13:26)
        
        именно так - MBedder(30.04.2013 15:57)
        
        Пример проекта не покажите?Как оно "именно так" делается? - Apтём(30.04.2013 16:10)
        
        Ну в пиках оно, как правило, так делалось - загрузчик в верхних адресах. При старте в целевом коде JMP на стартовый адрес загрузчика. Естественно с риском "потерять девайс" после стирания первой страницы флэш. В PIC18 векторов прерывания всего Гудвин(434 знак., 30.04.2013 16:22 - 16:25)
        
        Объясни, зачем "целевой код" класть в 0 адрес? Поправить линкер скрипт, чтоб начиналось с 0x1000, например, ниасилили? Переправить же 2 или 200 векторов одинаково легко. Трудно если по-индусски: 200 раз написать JP 0x1234. В нормальном fk0(78 знак., 30.04.2013 16:58)
        
        первую страницу флэш нужно стирать последней. а перед ее стиранием во вторую страницу поместить jmp Boot. - abivan(30.04.2013 16:29)
        
        Согласен, если код "0xFF" выполняется как NOP (или еще что то "безобидное"). - Гудвин(30.04.2013 16:32)
        
        Обычно нужны раздельные области памяти для раздельного подсчета crc. - Vladimir Ljaschko(30.04.2013 15:52)
        
        Во-о-oт! Пикоман N1 :) - Гудвин(30.04.2013 15:50)
        
        Смишно... - Apтём(30.04.2013 15:50)
        
        В PIC24 никакой проблемы нет. Первый набор векторов используется загрузчиком, второй рабочей программой. Чтоб не определять вектор на лету. Разумеется второй набор векторов содержит что-то вроде JP $+0x1000 в каждом элементе. Прерывание удлиняется fk0(118 знак., 30.04.2013 15:30)
        
        Во-о-oт! Пикоман N2 :) - Гудвин(30.04.2013 15:51)
        
        .. Apтём(52 знак., 30.04.2013 15:24)
        
        Не, ну там индусский полет мысли (в 24H и DSPIC) всякой ~~забористой травы~~ секьюристой фуйни напридумывал - с разграниченим доступа к разным областям кода. (которая вряд ли где-либо или кем-либо пользуется) А вот просто тупо поместить вторую Гудвин(52 знак., 30.04.2013 16:02 - 16:06)
        
        В другой -- это в какой? Например 0x1000? А если у тебя загрузчик не 0x1000 занимает, а все 0x2000 байтов. Тогда что? Правильно всё сделали индусы. Сейчас JP куда угодно там написать можно и от размера загрузчика и его соотношения с размером fk0(28 знак., 30.04.2013 17:00)
        
        Ты у нас в последнее время вроде как пикоман? Вот поэтому наверное твоим клиентам и незнамо слово "обновление фирмвари" ;=P - Гудвин(30.04.2013 15:22)
        
        Скорей наборот. Проникнуть в биосферу реактора им. Луговского. - fk0(30.04.2013 15:04)
        
        сорри, у м0 такой радости нет - Nikolay801_(30.04.2013 14:25)
    - Про кортексы непонятно "не в ROM"... Ежели для M3, то там перемещаемая таблица векторов - "облать бута" можно в любом месте забодяжить (хотя логичнее в стартовых адресах). И почему все-таки "не в ROM"? - Гудвин(30.04.2013 14:08)
      - Так навнерное привычней тосле АВР, чтоб была переписываемая область бута. - Apтём(30.04.2013 14:27)
    - тама -> --> - Evgeny_CD(30.04.2013 14:04, ссылка, ссылка)
      - А, ну те буты в ROM-е. - Apтём(30.04.2013 14:10)
  - Два апноута по тебе бутлодырей KL. Evgeny_CD(30.04.2013 11:48)

ARM, RISC-V контроллеры