jcxz

Выкиньте все эти мегабайты чужого кода - зачем в них ковыряться? Откройте даташит на CPU, найдите лёгкий stand-alone проект под ваш CPU, разберитесь с его asm-стартапом, перепишите под себя. На SVC часто вешаются системные сервисы. Например - видел в каких-то исходниках, использовавших чужой стартап в котором CPU сразу переводился в thread-mode, main() запускался уже в thread-mode, потом, позже при инициализации чего-то (для чего требовался handler-mode), как раз и использовались вызовы SVC для переключения в handler-mode. Если вы пишеет всё сами, то и управлять режимами CPU можете сами. И SVC-сервис тоже можете использовать для своих целей (если захотите). И никакие "секретные добавки" вам будут не страшны ;) Я например SVC использую для вызова ловушек критических ошибок и других надобностей.

Открываете документацию на ядро Cortex. Там SVC подробно разжёвана.

И?...

Хм.... Интересно - где Вы усмотрели у ТС-а Ethernet?

дополнительные хлопоты :) Ну если так можно назвать переписывание стандартного си-стартапа, чтобы разделить функции main(), а также сегменты инициализации глобальных и static переменных. Это кроме всего прочего.

Компилировать как один проект нельзя - как же вы потом отрежете? Там ведь возможны перекрёстные ссылки. Например: функция a() используется и в основной программе и в загрузчике. Естественно, что компилятор не будет (и не сможет) делать две её копии. По-любому надо два разных проекта, которые и собирать по-отдельности. И линковать в разные области flash. А уж готовые бинарники можно и склеить при желании.

superfonarik.ru и космическая/летающая техника как-то не очень между собой вяжутся ;)

Так и идите сами туда, что-ж вы сюда-то все прётесь, возомнившие себя благодетелями сирых и убогих?? Там же всё уже есть - берите и используйте. "Таким как вы" - до заказчика ещё как пешком до Луны. Вы даже не знаете что это такое. Так что приведите в соответствие ваше неумеренное самомнение вашим ущербным способностям. PS: Эх, не удержался! Да и как тут можно удержаться?

На каждом указателе. По существу есть что сказать? Само понятие "модель памяти" - это совокупность разрядностей кода+данных. Нет понятий "модель памяти данных" или "модель памяти кода". Как я понимаю: small - 16data+20код. tiny - 16data+16код.

Ну я то побольше в нём сижу ;) Если у вас проблемы с вылетом при компиляции, то следует обновить code generation tools до последних. У меня последние для TMS470 и для C6x, с ними такой проблемы нет. А по необъяснимым причинам CC3.3 падает примерно с такой-же частотой как и IAR, т.е. - достаточно редко. PS: пожалуй IAR - даже чаще.

А что не так с 'я' в CCS3.3? В асм-файлах? Просмотрел свои исходники - куча 'я' в си-файлах - не вылетает. Может Вы с IAR5.50 (for ARM) перепутали? Это в нём в asm-файлах такая проблема.

Дык - пользуйтесь CCS3.3. Там всё доступно и работает с этим SAU510

Возьмите любой cstartup.asm (или как он там называется) из любого примера IAR для вашего ядра.

Вот именно существует. Только там свой канальный уровень - ориентированный на Ethernet с её кадровой природой. А SPP-профиль в BT - это байтовый поток, а-ля - COM-порт. Т.е. - совсем не кадровый по своей природе, а поток байт. Только он не имеет временных характеристик обычного COM-порта. А значит - ни канальный уровень Modbus-TCP ни канальный уровень последовательного порта здесь применить нельзя. С Modbus-TCP дела не имел, но думаю что там кадр Modbus полностью входит внутрь TCP-кадра, так и определяются его границы. А как вы границы Modbus-кадра в SPP-профиле определите? Нужен другой алгоритм выделения кадров. Для такого канала как BT, где нельзя привязаться к временным характеристикам и он не имеет пакетной природы, подойдёт например SLIP-протокол канального уровня. Он не имеет привязки к временным характеристикам - может работать на любом последовательном канале, хоть железный UART, хоть любой виртуальный (BT, GSM, CDC-USB и т.п.). Для передачи IP-датаграмм через последовательные каналы как раз и используют SLIP-протокол, когда среда передачи представляет из себя поток байт. Например ранее, когда были телефонные модемы, он как раз и использовался. SLIP-протокол обеспечивает деление на кадры и кодонезависимость. Можно использовать и другой протокол, с меньшей избыточностью. Либо можно использовать какой-то другой BT-профиль, где передача носит кадровый характер (с приемлемыми размерами кадров).

Не путайте человека. У него ARM7, а вы ему про Cortex-M. В ARM7 никакого HardFault в принципе нет.

Останавливаете после уже "улёта" в неизвестность? В этом случае - толку от содержимого регистров ==0. До того как вы нажали HALT в отладчике, CPU уже успел выполнить неск. миллионов инструкций, и многократно переписал эти регистры. Такую ошибку отловить сложно и очень долго и муторно. Хотя вроде есть Tracer-ы, которые умеют запоминать сколько-то последних инструкций и отматывать назад. Но стоят жорого и требуют особенного подключения для себя (Trace). Когда у меня были подобные проблемы, приходилось использовать таймер с высокочастотным прерыванием: Так скажем с частотой 1МГц (или чаще) вызывалась ISR и писала в буфер содержимое регистров и стека. И проверяла некоторые условия - например - нахождение SP и PC в пределах некоторых значений с остановом если вышли за диапазон.

ARP-кадр у вас вроде верный. Не забыли, что пре передаче по Ethernet, кадр дополняется до некоей величины (не помню точно, 50 с чем-то байт, вроде 54 или 56) паддингом. Вы его имеете в виду? PS: пользуемся своим TCP/IP-стеком, ругани от WireShark на его кадры не замечал. Хотя у нас только ARP, IP, ICMP, TCP. UDP - не используется.

Modbus по BT? Через SPP??? Интересно - как Вы это себе представляете? Вы как бы не задумывались, что разделение кадров на канальном уровне в Modbus делается по паузам меж байтов? И что вы получите после прохождения этих кадров через SPP? SPP вовсе не гарантирует передачу временных характеристик входного потока байт через канал в выходной поток. Да и не может гарантировать, ибо по нижнему уровню любой RF-канал - это пакетная передача. Или нужен другой канальный уровень Modbus, а не канальный уровень последовательных каналов.

поднимайтесь по таймеру

В LPC17xx - частота периферии получается делением частоты ядра. Так что выше - никак. В LPC177x/178x - для периферии имеется отдельный от ядра делитель. Но всё равно в даташите явно указано: A 5-bit divider allows a range of frequencies to be used. Note that the peripheral clock rate should not be set higher than the CPU clock rate.

Имхо - наоборот избыточен по быстродействию. Ну разве только для HTTP (смотря по содержимому) ОЗУ может по-больше потребуется. У нас в изделии на LPC2378 на 72МГц крутится TCP-стек, поддерживает работу по нескольким сокетам параллельно и при этом - кучу ещё задач выполняет (TCP/IP - очень малая часть ПО).

Modbus-RTU - это сложно?

По-моему - это уже даже ТСу ясно

Ну - это можно и под обычным uCOS на M3-ядре сделать. Защита памяти в M3 есть. В хуке uCOS на переключение задачи прописать работу с MPU M3.

Прокатит, если писать грамотно и разбить ПО на платформо-независимую часть с вызовами соответствующих сервисов. И реализовать эти сервисы отдельно. Потом для другой ОС/платформы нужно будет только этот набор сервисов подкорректировать. Мне случалось писать ПО, которое работало и под uCOS на M3 через прослойку - уровень абстрагирования от периферии/ОС, и в то же время этот же самый файл один-в-один копировался под виндуXP и работал там через такую-же прослойку, но для винды. Размер прослойки был много меньше самого ПО. Так что - ни разные ОС ни разные платформы - не проблема. Было-бы желание и время спроектировать всё грамотно. Хотя конечно хозяин - барин.