jcxz

Сконфигурите bootpin-ы на загрузку из флеш. + - возможно, что необходимо чтобы точка входа в _c_int00 находилась по определённому адресу флеш (например в F28M35H52 это адрес 0x20004FF8 - после сброса запускается код в ROM, который по состоянию bootpin-ов определяет как грузиться и если стоит "флеш", переходит на этот адрес). Читайте даташит, секцию о загрузке.

Чего это вы в обработчике прерывания пользуете функции файлового В/В?

Раз есть исходники на яве - просто переписать их на с++.

Не знаю как под MSP430, но под C2000 - CCS4 - гуано полное! не советую. Отлаживать под ним можно только с матами. :( Намучался с ним когда отлаживал под F28M35. В отладке - сплошные баги (при старте и загрузке прошивки может молча загрузить её не всю (какая-нить const переменная есть в out-файле, а во флеш после загрузки её может запросто не оказаться), в окне WATCH вместо значений переменных могут начать показываться левые значения (лечится закрытием/открытием заново WATCH и заново вводом переменных и так до след. сбоя), неожиданные падения на ровном месте и куча других багов). Да ещё этот дебильный способ запуска DLL - копированием её в %TEMP% каждый раз с новым именем и запуском оттуда - файрволл постоянно матерится. CCS3.3 - много стабильнее, по-крайней мере под OMAP глючит редко. Хотя и один из последних IAR6.20 гораздо нестабильнее, чем старый IAR5.50 - часто падает на ровном месте, например - при вводе имени переменной в окне WATCH.

Насколько я понимаю у вас Cortex-M4? С ним дела не имел, но например в M3, многие исключения могут разрешаться/запрещаться через System control block. Возможно у вас генерация данного исключения просто выключена. Может в M4 есть что-то типа memory manager-a и его можно использовать для этого?

Даже если принять это, где у вас запись в нулевой адрес? Скорее в адрес == 4.

Да вроде там всё понятно: если передача память->периферия, то поле SrcPeripheral игнорится (старт передачи происходит по инициативе периферии), если передача память<-периферия, то поле DstPeripheral игнорится (то же), передачи память->память очевидно можно стартовать только вручную выставив запрос старта через DMACSoftBReq/DMACSoftSReq (оба поля DstPeripheral и SrcPeripheral игнорятся), насчёт случая периферия->периферия - не знаю, да и сомневаюсь в его нужности. Думаю - если Вы выставите режим память->память, то не сможете такую передачу запустить от сигнала DMA-запроса периферии, а только вручную через DMACSoftBReq/DMACSoftSReq хотя утверждать не стану, ибо сам никогда не использовал память->память. Так что поле TransferType определяет какое из полей DstPeripheral или SrcPeripheral используется для определения источника DMA-запроса. (Возможно что в случае "периферия->периферия" используются оба - по одному чтение во внутренний буфер DMAC, по другому - запись в периферию из буфера. Никогда не использовал этот тип передачи). В алгоритме предложенном мной выше, режим будет память->периферия всегда, а источник запросов - ваш таймер в DstPeripheral, SrcPeripheral - игнор. Посмотрите мануал на LPC178x - там DMACCxConfig еще больше усложнился ;)

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

А где здесь "память-память"? У вас несколько событий и несколько каналов DMA используется, к тому же закладывается на время выполнения GPIO и излишне грузит шину в первую мкс. Мой метод проще и экономичнее.

Можете ещё до кучи реализовать некоторые операции через механизм исключений. К примеру: пишем некое значение в некий адрес памяти физически несуществующий, получаем что там - bus error вроде? В обработчике исключения (который кста выполняется в привилегированном режиме) получаем значения целевого адреса записи и записываемого значения, которые юзаем как аргументы. :) Так можно например представить память, висящую к примеру на SPI, как виртуальную страницу в общем адресном пространстве.

Перечитайте внимательнее начальное сообщение. Там говорится о "атомарности операции bit-banding", а не атомарности доступа к порту. Сделать эту последовательность из 3-х команд атомарной можно тока запретом прерываний. Тогда как в 1-м случае, как я понимаю, используется спец. адресное пространство и команда STR r0,[r1,#0x64] модифицирует только заданные биты ячейки памяти (заданные маской или номером бита в R0).

У вас передача в UART идёт по событиям таймера или стартует по таймеру, а далее используются DMA-запросы от UART? Вообще - есть в DMA (и данного проца тож) такая фича как linked list. Если у вас все передачи в UART идут по событиям таймера, добавьте в конец и в начало передачи доп. пакеты пишущие в GPIO 0 и 1, и пакеты перепрограммирующие этот таймер. Например: 1-й DMA пакет устанавливает GPIO==1 и программирует таймер на 1 мкс выдержку, потом идут пакеты передачи по UART, следующий DMA-пакет программирует таймер на выдержку, достаточную для завершения передачи по UART,последний пакет DMA - запись 0 в GPIO. Я думаю - идея ясна.

И где же здесь атомарность??

А зачем делать коряво и неэстетично если можно элегантно и красиво и без доп. расходов? Религия не позволяет?

Я тож не знаю, но ПО на него написал ;) Там почти всё на си. Ядро x51 нужно тока для конфигурирования, обработки контрол-запросов (если нужно) и для медленных эндпоинтов, которые можно внутри обслуживать. А для 2-х быстрых эндпоинтов там GPIF, временные диаграммы которого прописываются визуально в типа граф. редакторе. Плюс - на ПК не нужно писать драйвер устройства - библиотека и драйвер Cypress даёт доступ к функциям API системного драйвера USB с уровня приложения (подключаешь библиотеку и пишешь весь обмен в приложении). Плюс - все возможные типы передач, включая изохронную, плюс - нет ненужных надстроек и эмуляций а-ля COM-порт. По-моему там даже есть примеры типа - прописываешь его в CY7C68013A и получаешь к примеру ATAPI через USB. Хотя конечно если нужна гальваническая развязка, то - Ethernet....

Под "с++" я и имел в виду ООП. Прочитайте то моё сообщение до конца. "всяческое там наследование и соотв. расходы" - наследование не приводит к доп. расходам в общем случае (если нет вирт. методов). Полностью согласен.

CY7C68013A == USB High-speed + ядро x51 Интерфейс у неё - параллельный 8 или 16 бит

не поверю

Где "там"? с++ - это язык на котором написаны ИСХОДНИКИ, а память у вас в контроллере занимает СКОМПИЛЁННЫЙ КОД, а не исходники.

с++ и мипсы/память - никак между собой не связаны. Алгоритм на с++ не отличается по занимаемой памяти/мипсам от реализации его на си. А вот кривость рук и компетентность разработчика впрямую связаны с размером/производительностью. А что мешает НЕ ИСПОЛЬЗОВАТЬ виртуальные методы? Или другими словами - кто их заставляет использовать? ЗЫ: всегда пишу на все контроллеры на с++ при полном отсутствии вирт. методов и динамической памяти, и пользованием в основном статическими конструкторами. При этом никто не мешает пользоваться другими прелестями ООП, типа перегрузки функций/операторов, порождением/наследованием, ограничением области видимости и доступа класса и т.п.

А зачем с нуля? Берите любой пример и выкидывайте всё ненужное - ломать не строить! cmd-файл пишется по разделу "memory map" даташита. Там же можно описать и адресное пространство регистров периферии.

А в чём проблема? Кто мешает? CCS поддерживает c++ - значит можно.

И насколько это телефононезависимо? ;)

Загляните в мануал на проц - там в разделе "PLL" обычно указывается формула расчёта частоты. Для LPC23x, например, она такова: Fcco = (2 × M × Fin) / N видите множитель 2?

Откуда процессор узнает, что ему надо стартовать не с обычной точки старта (с начала флеш для LPC17x & LPC23x), а с вашего адреса? Если вы скомпилили программу так, чтобы она работала с бутлоадером, то его нужно предварительно прошить во флеш. Также он должен знать куда передавать управление для запуска вашей прошивки. Также его таблица векторов прерываний должна перенаправлять все прерывания на обработчики рабочей программы (либо рабочая прога должна переместить таблицу своих векторов в ОЗУ). Читайте даташиты по процессу загрузки процессора. Для LPC17x это "Boot process flowchart" - у NXP всё хорошо разжёвано.