Несколько вопросов по lpc176x Опции

[vallav]

1. Почему у него такая странная распиновка выводов?
На 100 ногах нашли место только для 70 gpio, причем ни одного целого 32х битного регистра, всего один целый 16 битный а разбросаны
и перемешаны они - мама не горюй! Наследие тяжелого прошлого?
Как красиво с этим у ST32 - 5 16 битных регистров и почти все ножки в ряд.

2. 12 тактов входа в прерывание и 12 тактов выхода из него ( обязательных ) преподносится как достижение.
Вроде достижением было у ADSP 218x - полтора такта до первой команды в прерывании и 1 такт на выход.

3. Меня интересует, в lpc176x ПДП такое же тормозное....
Правда, по слухам, до кортексов у АРМа с этим было еще хуже.

Причина редактирования: Дублирование вопроса в разных темах

[sonycman]

Если контрольная сумма отсутствует в файле прошивки, значит, она вычисляется и подставляется в процессе записи во флеш.

Таймеры мне чем понравились, это тем, что они 32 битные, а не 16 как в STM.
В том, что они работают на частоте ядра, нет ничего удивительного.

[vallav]

Если контрольная сумма отсутствует в файле прошивки, значит, она вычисляется и подставляется в процессе записи во флеш.

Или вообще не вычисляется, а в описании - лажа.
Что намного более вероятно.

Таймеры мне чем понравились, это тем, что они 32 битные, а не 16 как в STM.
В том, что они работают на частоте ядра, нет ничего удивительного.

Ага, для lpc17xx.
Есть кортексы, в которых это не так.

[igorsk]

Или вообще не вычисляется, а в описании - лажа.
Что намного более вероятно.

Залей прошивку в чип, прочитай назад и сравни.

[vallav]

Залей прошивку в чип, прочитай назад и сравни.

Спасибо за очень ценный совет.

Ну ни в жисть бы сам не догадался...

[mrKirill]

Спасибо за очень ценный совет.
Ну ни в жисть бы сам не догадался...

//off-top
Свою манеру общения на форумах изменили бы на "помягче", а то глядишь скоро Вам вообще никто ничего отвечать не будет.

[vallav]

//off-top
Свою манеру общения на форумах изменили бы на "помягче", а то глядишь скоро Вам вообще никто ничего отвечать не будет.

А по мягче - это как?
Вот на данный ответ Вы бы как прореагировали ( если помягче )?

[vallav]

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

[vallav]

Скомпилил аппноуту AN10866 от NXP - secondary USB bootloader в Keil.
При компиляции что то там исправлял.
Загрузил в плату mbed - работает.
Только, так как прога занимает 8K флеша, опции на пользовательскую прогу надо немного поменять.
Штука очень удобная. Чип прикидывается флешкой на 500К.
Компилишь прогу в .bin. Удаляешь старый .bin с этой флешки, копируюешь туда новый, нажимаешь сброс - новая прога работает.
Добавить к mbed пришлось - кабель с разъемом от резанный от мышки и проводок, чтобы замыкать на землю p1.20.
Кому интересно, файлы привожу. Там usbboot1 - сам загрузчик, а blinki2 - мигалка светодиодами mbed_а.

Прикрепленные файлы

 usbboot1.rar ( 152.05 килобайт ) Кол-во скачиваний: 72

 

[vallav]

Похоже рабочие исходники проги, которая после небольшой переделки позволит подключить lcp176x по USB к PCюку без промежуточных
чипов и без драйверов на максимальной скорости - неинтересны. Неужели это уже не актуально?
И еще, ну ладно загрузка проги через USB без наворотов неинтересна, а если ее дописать, чтобы она прикидывалась родным USB житагом
для Кейла и позволяла вести загрузку и отладку, эмулируя житаг?
Тоже не интересно? Что тогда будут делать многочисленные производители чипов переходников USB-UART и приставок житагов?
Да и плата с lpc176x будет как то не серьезно выглядеть - ни проводов ни деталей...
А если еще про USB обманывают и он будет работать на внутреннем RC генераторе - то вообще пипец.
Особенно если NXP все это защьет в ROM по просьбе трудящихся.

Ладно, тогда вернусь к начальной загрузке.
Слинковал я прогу для работы в ОЗУ целиком, вместе с таблицей прерываний.
Первые 8 слов загрузчика такие:
10000300 10000065 10000069 1000006b
1000006d 1000006f 10000071 00000000

Проверено, после включения питания работает.
И что будет, если после снятия сброса бутлоадер убедившись непонятно каким способом, что есть пользовательская прога,
первое слово загруpузит в sp и произведет переход по значению второго слова из таблицы прерываний?
А код переносить из флеши в ОЗУ и устанавливать битики в проце о том, что таблица прерываний не в нуле - кто будет? Загрузчик?
Так что в описании по этому поводу - полная лажа.
По моему мнению линкер по фиксированному адресу в начале флеша подключает свой кусок кода, который делает все начальные разборки.
И переход после отработки бутлоадера идет на этот адрес.

[zltigo]

Похоже рабочие исходники проги, которая....

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

И что будет, если после снятия сброса бутлоадер убедившись непонятно каким способом

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

Так что в описании по этому поводу - полная лажа.

Это в голове

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

. Скрипт исполняется при загрузке через JTAG, в нем все и устанавливается для работы в RAM и прямо передается управление. В остальных случаях этим занимается startup. Так уж в 'С' принято испокон веков.

[vallav]

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

И в результате что?
Кстати у меня оригинал не компилился, пришлось ощибки исправлять.

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

Вы это описание читали?
С приведенными мною 8 первыми словами во флешке согласовать смогете?
Или Вы только - болтать?

. Скрипт исполняется при загрузке через JTAG, в нем все и устанавливается для работы в RAM и прямо передается управление. В остальных случаях этим занимается startup. Так уж в 'С' принято испокон веков.

Увы, в startup_е нет даже инициализации sp. Именно с этого - а где же sp то инициализируется, я и начал ковырять startup.
И откуда startup_у знать, какую именно я раскладку памяти линкеру назначил?
Тем боле и startup и таблица прерываний в данном случае - в ОЗУ.
Что их туда из флеша при включении притания перемещает? Startup?

А то, что в 'C' принято испокон веков, в кортексах похерено.
Знаете, как в кортексном 'C' передача параметров в функцию происходит?

Вы бы лучше занимались тем, что у Вас хорошо получается - выписывание баньки, и не лезли туда,
где ничего не смыслите.
Можно я на Ваши глупости больше отвечать не буду?
Надеюсь это не против правил форума?

Сообщение отредактировал vallav - May 29 2010, 12:30

[zltigo]

Вы это описание читали?

Да. И даже понял. И вот это совершено спокойно написал: http://electronix.ru/forum/index.php?showt...60&start=60 оно этими самыми суммами и занимается в том числе.

Увы, в startup_е нет даже инициализации sp.

Есть. Вот, например, у меня так:

Код

static unsigned long system_stack[STACK_SIZE] @ ".noinit";

__root const Vector_entry_u __vector_table[] @ ".intvec" =
{
    {                        // The initial stack pointer
    .stack_ptr = (unsigned long)system_stack + sizeof(system_stack)
                                                        },
    __iar_program_start,    // The RESET handler
    nmi_isr,                // The NMI handler
........

Что их туда из флеша при включении притания перемещает? Startup?

Ага, ведь если-бы этим занимался Александр Сергеевич, это было-бы очень странно. А посему, при необходимости, как в startup инициализируются переменные в RAM, так и преносятся при необходимости и секции содержащие исполняемый код.

А то, что в 'C' принято испокон веков, в кортексах похерено.
Знаете, как в кортексном 'C' передача параметров в функцию происходит?

Так-же, как в AVR, так-же, как в ARM, так-же, как в x86 с примерно 90x годов, когда, например у Watcom, появились первые соглашения о передаче параметров через регистры. Стандарт языка это вообще не нормирует, посему слова про 'C' пустые слова.

Вы бы лучше занимались тем, что у Вас хорошо получается - выписывание баньки

Хорошо, и этому уделю внимание.

Можно я на Ваши глупости больше отвечать не буду?

Только я на глупости, в том числе и Ваши, на форуме буду по прежнему стараться указывать. Дабы не плодились оные.

[vallav]

Ну вот видите, можете, когда захотите.

Да. И даже понял. И вот это совершено спокойно написал: http://electronix.ru/forum/index.php?showt...60&start=60 оно этими самыми суммами и занимается в том числе.

И что, приведенные мной 8 первых слов во флеше у Вас дают нулевую контрольную сумму?
Что эта за контрольная сумма - "check-sum of table entries 0 through 6"?

Есть. Вот, например, у меня так:

Код

static unsigned long system_stack[STACK_SIZE] @ ".noinit";

__root const Vector_entry_u __vector_table[] @ ".intvec" =
{
    {                        // The initial stack pointer
    .stack_ptr = (unsigned long)system_stack + sizeof(system_stack)
                                                        },
    __iar_program_start,    // The RESET handler
    nmi_isr,                // The NMI handler
........

Вы не поняли. Я не говорил, что ни у кого нет.
Я говорил, что в стандартном стартапе от Кейла нет.
И как оказалось - и не нужно.
А ежели не лень или подстраховаться хочется, можно в своем написать.

Ага, ведь если-бы этим занимался Александр Сергеевич, это было-бы очень странно. А посему, при необходимости, как в startup инициализируются переменные в RAM, так и преносятся при необходимости и секции содержащие исполняемый код.

А если прога на АСМе? И я хочу, чтобы она в ОЗУ работала?
То надо перенос кода в ОЗУ при включении притания самому писать и самому делать линковку неперемещаемых кусков?
Можно конечно. Но есть надежда, что это умеет делать стандартный линкер.

Так-же, как в AVR, так-же, как в ARM, так-же, как в x86 с примерно 90x годов, когда, например у Watcom, появились первые соглашения о передаче параметров через регистры. Стандарт языка это вообще не нормирует, посему слова про 'C' пустые слова.

Стандарт языка так же игнорирует перенос кода из флеши в ОЗУ.
Значит Ваши слова про стартап - это пустые слова?

Вы упустили два вопроса.
1. Чем именно закончилась дискуссия по "цельнотянутый и писанный "бангалорскими" программерами загрузчик от NXP", который NXP
разместила у себя в качестве аппноты.
Можно на его основе написать общение между чипом и прогой в PC_юке по USB без использования дополнительных чипов и специально устанавливаемых
драйверов, причем на приличной скорости?
2. Правильно ли, что после сброса происходит загрузка в sp значения первого слова флеши и переход по адресу, равному значению второго слова флеши?
И что перед этим переносит код в ОЗУ, если второе слово флеши указывает на ОЗУ.
И главное, как узнает, что и куда из флеши надо переносить.

Кстати, уменя получилось - когда и стартап и сама прога в ОЗУ - стандартный бутлоадер не справляется, а писанный "бангалорскими" - прогу
запускает и она работает. Это наверно потому, что он кривой?
Пока не получается таблицу прерываний в ОЗУ засунуть, но когда получится и "бангалорский" и такую запустит - значит он сильно кривой...

[zltigo]

И что, приведенные мной 8....

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

Я говорил, что в стандартном стартапе от Кейла нет.
И как оказалось - и не нужно.
А ежели не лень или подстраховаться хочется, можно в своем написать.

Разумеется нужно, разумеется есть. Специально Вас тыкаю носом в то, что идет с Кейлом для LPC17xx:

Код

; <h> Stack Configuration
;   <o> Stack Size (in Bytes) <0x0-0xFFFFFFFF:8>
; </h>

Stack_Size      EQU     0x00000200

                AREA    STACK, NOINIT, READWRITE, ALIGN=3
Stack_Mem       SPACE   Stack_Size
__initial_sp

.......


; Vector Table Mapped to Address 0 at Reset

                AREA    RESET, DATA, READONLY
                EXPORT  __Vectors

__Vectors       DCD     __initial_sp; Top of Stack
                DCD     Reset_Handler; Reset Handler
                DCD     NMI_Handler    ; NMI Handler

Можно конечно. Но есть надежда, что это умеет делать стандартный линкер.

Оставте,наконец, глупейшие фантазии. Линкер только линкует. Копированием занимается подобный код инициализирующий
сегменты перед тем, ка будет вызван main().

Код

  char const * p = __section_begin("Region$$Table");
  uint32_t const * pe = __section_end("Region$$Table");
  uint32_t const * pi = (uint32_t const *)(p);
  while (pi != pe)
  {
    init_fun_t * fun = (init_fun_t *)((char *)pi + *(int32_t *)pi);
    pi++;
    pi = fun(pi);
  }

"бангалорский" и такую запустит - значит он сильно кривой...

Он кривой, но устанавливать указатели на стек и таблицу векторов он должен уметь. Всего-то и делов занести адрес куда он образ загрузил в качестве адреса таблицы векторов, считать слово по нулевому смещению из образа и проинициализировать им указатель стека, ну и передать управление по адресу содержащимуся в первом слове образа. И все. Это по определению делает любой загрузчик, как первичный имеющийся у NXP, так и любой, в том числе вторичный USB кейловский. Эти-же нехитрые операции выполняются ядром при старте запуская программу. Только адрес строго фиксирован.

[vallav]

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

Поясняю - это первые 8 слов флеша, начиная с нулевого адреса.
В случае, когда и стартап и прога слинкованы в ОЗУ.
Обратите внимание на второе слово - адрес перехода.
Как именно Ваш первичный загрузчик определяет наличие исполняемой программы на нулевых адресах?
То есть - что конкретно он делает, какой конкретный алгоритм?
Или - знаете, что определяет, но как именно - не знаете?

Разумеется нужно, разумеется есть. Специально Вас тыкаю носом в то, что идет с Кейлом для LPC17xx:

Код

; <h> Stack Configuration
;   <o> Stack Size (in Bytes) <0x0-0xFFFFFFFF:8>
; </h>

Stack_Size      EQU     0x00000200

                AREA    STACK, NOINIT, READWRITE, ALIGN=3
Stack_Mem       SPACE   Stack_Size
__initial_sp

.......


; Vector Table Mapped to Address 0 at Reset

                AREA    RESET, DATA, READONLY
                EXPORT  __Vectors

__Vectors       DCD     __initial_sp; Top of Stack
                DCD     Reset_Handler; Reset Handler
                DCD     NMI_Handler; NMI Handler

И где Вы тут обнаружили присвоение регистру sp значения __initial_sp?

Оставте,наконец, глупейшие фантазии. Линкер только линкует. Копированием занимается подобный код инициализирующий
сегменты перед тем, ка будет вызван main().

Код

  char const * p = __section_begin("Region$$Table");
  uint32_t const * pe = __section_end("Region$$Table");
  uint32_t const * pi = (uint32_t const *)(p);
  while (pi != pe)
  {
    init_fun_t * fun = (init_fun_t *)((char *)pi + *(int32_t *)pi);
    pi++;
    pi = fun(pi);
  }

Ну вот опять.
Я не говорил, что такой код написать нельзя.
Я не говорил, что такого кода нет во флеши.
Я спрашиваю - как нечто, переписывющее код из флеши в ОЗУ до того, как сделать туда переход по адресу, равному значеню второго слова из флеша
узнает - где именно этот код?

А про линкер Вы оказывается совсем мало знаете.
Не пробовали - прежде чем здесь постить с таким апломбом - описание линкера почитать?

Он кривой, но устанавливать указатели на стек и таблицу векторов он должен уметь. Всего-то и делов занести адрес куда он образ загрузил в качестве адреса таблицы векторов, считать слово по нулевому смещению из образа и проинициализировать им указатель стека, ну и передать управление по адресу содержащимуся в первом слове образа. И все. Это по определению делает любой загрузчик, как первичный имеющийся у NXP, так и любой, в том числе вторичный USB кейловский. Эти-же нехитрые операции выполняются ядром при старте запуская программу. Только адрес строго фиксирован.

Ну да, а вот родной ( из ПЗУ ) загрузчик прямой, но этого не умеет. Прога то им не запускается...
Вы лихо все расписали, но забыли - а что переносит код из флеша в ОЗУ перед "и передать управление по адресу содержащимуся в первом слове образа" и по какому адресу в флеше это находится.

В случае, когда стартап и программа в флеше, это адрес как раз равен значению второго ( в Ваших терминах первого ) слова в флеше.
А когда в этом слове адрес ОЗУ?

И по прежнему нет ответа на наиболее интересующий меня вопрос:

Чем именно закончилась дискуссия по "цельнотянутый и писанный "бангалорскими" программерами загрузчик от NXP", который NXP
разместила у себя в качестве аппноты.
Можно на его основе написать общение между чипом и прогой в PC_юке по USB без использования дополнительных чипов и специально устанавливаемых
драйверов, причем на приличной скорости?

Вы не стесняйтесь - если ответа не знаете, так и ответьте - не знаю.