| |
|
  |
 свежак KGP win32/arm/avr/mips/m68k, GNU tools chain |
|
|
|
|
 Apr 12 2016, 09:11
|
Местный
Группа: Участник
Сообщений: 244
Регистрация: 29-02-08
Пользователь №: 35 503
|
Цитата(RabidRabbit @ Apr 12 2016, 11:49)  www.klen.org/Files/DevTools/x86_64-kgp-linux-gnu/arm-kgp-eabi_@_x86_64-kgp-linux-gnu_20160329_MELISSA.7z
тот же самый небольшой проект для Cortex-M0+ по сравнению с предыдущей сборкой:
было (размер text): 115692, стало 115352. Хоть относительно общего размера изменения небольшие, на самом деле большую часть кода занимают константы - всяческая графика. И никаких HardFault-ов? Мейкфайлом и скриптом линкера не поделитесь? У меня что мелисса, что hypericum - хардфаулт на двух разных проектах.. Конечно можно было бы задаться целью и найти причину ХФ. Но мотивации особой нет, больше люботытство, С arm-none-eabi v4.9 все ОК почта r*a*i*n*6*2*s*t*e*r* dog gmail.com
Сообщение отредактировал nanorobot - Apr 12 2016, 12:43
|
|
|
|
|
|
|
|
Apr 14 2016, 09:58
|
Группа: Участник
Сообщений: 10
Регистрация: 12-02-15
Пользователь №: 85 112
|
2_klen
Обещал отписаться по поводу глюков с порядком байт в 5890ВЕ1Т - выполняю.
По большому счёту, это не вопрос компиляции даже. У нас вышло так, что содержимое ПЗУ он интерпретирует всегда одинаково, хотя судя по описанию, он должен мочь стартовать как в big-endian режиме, так и в little-endian (в зависимости от логического уровня на одном из выводов в момент выхода из состояния reset).
Писать программу и компилировать её надо для big-endian режима, с точки зрения программиста (которого не особо интересует, что и на каких линиях шины адреса и данных при этом выставляется) всё будет выглядеть именно так.
А вот чтобы "скормить" процессору дамп для прошивки 32-разрядного ПЗУ, полученный из big-endian elf-файла, нужно в каждом 32-разрядном слове этого дампа поменять местами 0-ой байт с 3-им, а 1-ый со 2-ым. В результате получится little-endian код (касаемо собственно команд).
Если программа не содержит инструкций работы с памятью байтами и полусловами (lbu, lhu, sb, sh), то можно его сразу компилировать, как будто он little-endian, и получать из него дамп для прошивки - результат будет идентичным.
А вот если в программе присутствует это дело вместе с данными, описанными как байты (строки символов) и полуслова, то нужно обязательно действовать по первому варианту (компилировать big-endian и потом разворачивать), потому как строка, описанная в исходнике как "01234567abcd" в дампе должна превратиться в "32107654dcba".
При компиляции в little-endian такой разворот выполнен не будет, соответственно код, печатающий эту строку путём выборки байт с последовательно инкрементирующегося адреса, будет работать неправильно.
--------------------
Жить однозначно вредно: все, кто жили - померли
|
|
|
|
|
|
|
|
Apr 14 2016, 10:28
|
Группа: Участник
Сообщений: 5
Регистрация: 13-06-08
Пользователь №: 38 263
|
Цитата(Lomaker @ Apr 14 2016, 12:58) 2_klen
Обещал отписаться по поводу глюков с порядком байт в 5890ВЕ1Т - выполняю.
По большому счёту, это не вопрос компиляции даже. У нас вышло так, что содержимое ПЗУ он интерпретирует всегда одинаково, хотя судя по описанию, он должен мочь стартовать как в big-endian режиме, так и в little-endian (в зависимости от логического уровня на одном из выводов в момент выхода из состояния reset).
Писать программу и компилировать её надо для big-endian режима, с точки зрения программиста (которого не особо интересует, что и на каких линиях шины адреса и данных при этом выставляется) всё будет выглядеть именно так.
А вот чтобы "скормить" процессору дамп для прошивки 32-разрядного ПЗУ, полученный из big-endian elf-файла, нужно в каждом 32-разрядном слове этого дампа поменять местами 0-ой байт с 3-им, а 1-ый со 2-ым. В результате получится little-endian код (касаемо собственно команд).
Если программа не содержит инструкций работы с памятью байтами и полусловами (lbu, lhu, sb, sh), то можно его сразу компилировать, как будто он little-endian, и получать из него дамп для прошивки - результат будет идентичным.
А вот если в программе присутствует это дело вместе с данными, описанными как байты (строки символов) и полуслова, то нужно обязательно действовать по первому варианту (компилировать big-endian и потом разворачивать), потому как строка, описанная в исходнике как "01234567abcd" в дампе должна превратиться в "32107654dcba".
При компиляции в little-endian такой разворот выполнен не будет, соответственно код, печатающий эту строку путём выборки байт с последовательно инкрементирующегося адреса, будет работать неправильно. Спишись со мной по мылу из профиля. Мы уже три года пользуем этот проц. Дока не ДСП, но по лиц соглашению не положено ее разглашать. Проц аналог R3800 с 4к кешем данных и 4к комманд. Патч на ассемблер я себе давно приделал.
|
|
|
|
|
|
|
|
Apr 15 2016, 05:57
|
Группа: Участник
Сообщений: 10
Регистрация: 12-02-15
Пользователь №: 85 112
|
Цитата(TJ27 @ Apr 14 2016, 13:28) Спишись со мной по мылу из профиля. Мы уже три года пользуем этот проц. Дока не ДСП, но по лиц соглашению не положено ее разглашать. Проц аналог R3800 с 4к кешем данных и 4к комманд. Патч на ассемблер я себе давно приделал. Мыло из профиля скрыто от посторонних глаз (в настройках надо соответствующая галочка имеется, у тебя она стоит, по всей видимости). А что этот патч делает? Если дело касается только перестановки байт, то уже не актуально. Программа, которую я зашил в ПЗУ, содержит загрузчик, который принимает и запускает исполняемый код по порту RS-232. Поскольку загрузчик сам уже выполняется процессором 5890ВЕ1Т, то принимаемые по порту байты он уже распихивает как ему самому это видно, т.е. правильно, и никакие дополнительные развороты не требуются. Я вчера как наладил загрузку, скомпилировал несколько тестовых примеров на C как big-endian, там и вычисления с плавающей точкой были (умножить, поделить, квадратный корень-sqrt), и печать полученных результатов (sprintf). Загрузил и выполнил это дело - полёт нормальный, проблем не обнаружил (по крайней мере, через некэшируемую область ОЗУ). Так что пока у меня сложилось такое впечатление, что собственно с компиляцией кода проблем нет при использовании имеющегося у меня компилятора, всё-таки довольно приличный уже объём. Или всё-таки есть какое-то тайное шаманство, которое проявляется сильно иногда? Полезу сейчас в свой профиль, сделаю видимым своё мыло, если по почте удобнее. P.S. А контроллер "манчестера" 5890ВГ1Т случайно не используете? Особо интересует режим монитора шины. В документации вижу только описание режима контроллера шины и режима оконечного устройства. О мониторе шины только упоминание, что он тоже типа есть. Но вот как им пользоваться, совершенно непонятно.
Сообщение отредактировал Lomaker - Apr 15 2016, 06:26
--------------------
Жить однозначно вредно: все, кто жили - померли
|
|
|
|
|
|
|
|
Apr 15 2016, 08:40
|
Группа: Участник
Сообщений: 5
Регистрация: 13-06-08
Пользователь №: 38 263
|
Цитата(Lomaker @ Apr 15 2016, 08:57) Используем 3 com порта, манчестер оба устройства в режимах контроллера канала и оконечного устройства. Патч на ассемблер - правятся ошибки описанные в доке на 120 странице ЮКСУ.431288.001.Д4. Может они это в современных ревизиях и исправили, но об изменениях не сообщают. (у ВМ1 этих ошибок точно нет). Еще у них есть глюк с антипереполнением с плавающей запятой (не генерится искл.ситуация и проц подвисает). sergkruglov at bk . ru Не хочу контору подставлять, у нас с НИИСИ и так отношения странные 
|
|
|
|
|
|
|
|
Apr 24 2016, 15:10
|
бессмертным стать можно тремя способами
Группа: Свой
Сообщений: 1 405
Регистрация: 9-05-06
Из: Москва
Пользователь №: 16 912
|
здравствуйте! очень рад что в ветка всплеск активности. С НИИСИ я и сам справлюсь если потребуется, никого подставлять ненадо. есть теоретическая возможность через верх зайти и практическая - с авторами микросхемы. если я не ошибаюсь, авторше из этой банды было лет пять назад что то за 60 лет .. а в это время незаметно подкрался пи... не ... не писец, а транк ветка gcc поимела версию 7 представляю свежак 7 ветки www.klen.org/Files/DevTools/x86_64-kgp-linux-gnu/arm-kgp-eabi_@_x86_64-kgp-linux-gnu_20160424_FCORUS.7z проверил на своих проектах - хруста в коробке передач на ходу не возникло, все нормально. есть особенность сборки - gdb собран с поддеркой питона 2.7. поэтому тянет либу libpython2.7.so. если она у Вас поставлена - то все должно заработать, если нет то я не проверял - возможно отвалится. тогда из предыдущей сборки можно бинарь взять и не парится. зачем ОНО надо - я хочу прикрутить к GDB механизм передачи отладочных сообщений - линия SWO в SWD интерфейсе. если получится то влинкую питон статически что бы на любой ситеме работало, а пока через сошку. для тех кто в бронепоезде - могу собрать релизные сборки версий 5.3 и 6.1 - для успокоения души тем у кого "продакшен" и боятся нерелизного компилятора.
|
|
|
|
|
|
|
|
Apr 25 2016, 10:27
|
Группа: Участник
Сообщений: 10
Регистрация: 12-02-15
Пользователь №: 85 112
|
Цитата(klen @ Apr 24 2016, 18:10) здравствуйте! очень рад что в ветка всплеск активности. С НИИСИ я и сам справлюсь если потребуется, никого подставлять ненадо. есть теоретическая возможность через верх зайти и практическая - с авторами микросхемы. если я не ошибаюсь, авторше из этой банды было лет пять назад что то за 60 лет Что касается 5890ВГ1Т (манчестеры), то мне сказали, что разработчики уволились. Но описание на режим монитора шины надыбать всё же удалось: ребята из другого подразделения, давно применяющие эту микросхему, по своим каналам раздобыли.
--------------------
Жить однозначно вредно: все, кто жили - померли
|
|
|
|
|
|
|
|
5 чел. читают эту тему (гостей: 5, скрытых пользователей: 0)
Пользователей: 0
|
|
|
