[demiurg_spb 0]

Не пойму, почему народ не использует свежие и проверенные компиляторы для сравнения со сборками Клёна?

 

Нынче актуальна эта версия:

gcc version 5.3.1 20160307 (release) [ARM/embedded-5-branch revision 234589] (GNU Tools for ARM Embedded Processors)

 

https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q1-update

[AHTOXA 15]

У меня при попытке перехода на неё с 2015q1, компилятор на текущем проекте неожиданно запросил _sbrk() и компанию. Так что я пока отложил переход (времени выяснять, от чего там подцепились malloc() и компания, не было).

[demiurg_spb 0]

У меня нет таких проблем...

nosys линкуете?

 

[AHTOXA 15]

nosys линкуете?

Нет конечно. Иначе бы не заметил:)

При беглом просмотре показалось, что дело в каких-то структурах TZDATA, которые пытаются распределиться при подключении time.h (или при использовании каких-то функций оттуда).

[RabidRabbit 0]

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. Хоть относительно общего размера изменения небольшие, на самом деле большую часть кода занимают константы - всяческая графика.

 

[nanorobot 3]

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

Изменено 12 апреля, 2016 пользователем nanorobot

[Lomaker 0]

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 такой разворот выполнен не будет, соответственно код, печатающий эту строку путём выборки байт с последовательно инкрементирующегося адреса, будет работать неправильно.

[TJ27 0]

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к комманд. Патч на ассемблер я себе давно приделал.

[Lomaker 0]

Спишись со мной по мылу из профиля. Мы уже три года пользуем этот проц. Дока не ДСП, но по лиц соглашению не положено ее разглашать. Проц аналог R3800 с 4к кешем данных и 4к комманд. Патч на ассемблер я себе давно приделал.

Мыло из профиля скрыто от посторонних глаз (в настройках надо соответствующая галочка имеется, у тебя она стоит, по всей видимости).

А что этот патч делает? Если дело касается только перестановки байт, то уже не актуально. Программа, которую я зашил в ПЗУ, содержит загрузчик, который принимает и запускает исполняемый код по порту RS-232.

Поскольку загрузчик сам уже выполняется процессором 5890ВЕ1Т, то принимаемые по порту байты он уже распихивает как ему самому это видно, т.е. правильно, и никакие дополнительные развороты не требуются.

Я вчера как наладил загрузку, скомпилировал несколько тестовых примеров на C как big-endian, там и вычисления с плавающей точкой были (умножить, поделить, квадратный корень-sqrt), и печать полученных результатов (sprintf).

Загрузил и выполнил это дело - полёт нормальный, проблем не обнаружил (по крайней мере, через некэшируемую область ОЗУ). Так что пока у меня сложилось такое впечатление, что собственно с компиляцией кода проблем нет при использовании имеющегося у меня компилятора, всё-таки довольно приличный уже объём.

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

 

P.S. А контроллер "манчестера" 5890ВГ1Т случайно не используете? Особо интересует режим монитора шины. В документации вижу только описание режима контроллера шины и режима оконечного устройства. О мониторе шины только упоминание, что он тоже типа есть.

Но вот как им пользоваться, совершенно непонятно.

Изменено 15 апреля, 2016 пользователем Lomaker

[TJ27 0]

Используем 3 com порта, манчестер оба устройства в режимах контроллера канала и оконечного устройства.

Патч на ассемблер - правятся ошибки описанные в доке на 120 странице ЮКСУ.431288.001.Д4.

Может они это в современных ревизиях и исправили, но об изменениях не сообщают. (у ВМ1 этих ошибок точно нет).

Еще у них есть глюк с антипереполнением с плавающей запятой (не генерится искл.ситуация и проц подвисает).

sergkruglov at bk . ru

Не хочу контору подставлять, у нас с НИИСИ и так отношения странные :)

[klen 1]

здравствуйте! очень рад что в ветка всплеск активности. С НИИСИ я и сам справлюсь если потребуется, никого подставлять ненадо. есть теоретическая возможность через верх зайти и практическая - с авторами микросхемы. если я не ошибаюсь, авторше из этой банды было лет пять назад что то за 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 - для успокоения души тем у кого "продакшен" и боятся нерелизного компилятора.

[AHTOXA 15]

для тех кто в бронепоезде - могу собрать релизные сборки версий 5.3 и 6.1 - для успокоения души тем у кого "продакшен" и боятся нерелизного компилятора.

Хотим, хотим! :)

[Lomaker 0]

здравствуйте! очень рад что в ветка всплеск активности. С НИИСИ я и сам справлюсь если потребуется, никого подставлять ненадо. есть теоретическая возможность через верх зайти и практическая - с авторами микросхемы. если я не ошибаюсь, авторше из этой банды было лет пять назад что то за 60 лет :)

Что касается 5890ВГ1Т (манчестеры), то мне сказали, что разработчики уволились. Но описание на режим монитора шины надыбать всё же удалось: ребята из другого подразделения, давно применяющие эту микросхему, по своим каналам раздобыли.

[klen 1]

свежак

www.klen.org/Files/DevTools/x86_64-kgp-linux-gnu/arm-kgp-eabi_@_x86_64-kgp-linux-gnu_20160502_TANACETUM.7z

[klen 1]

поздравляю Всех с празниками.

в предверии 9 мая...

 

свежак из ARM для тех кто хочет эмбеддидь в win64

www.klen.org/Files/DevTools/x86_64-kgp-mingw32/arm-kgp-eabi_@_x86_64-kgp-mingw32_20160503_TANACETUM.7z

 

свежак из ARM для тех кто хочет эмбеддидь в win32

www.klen.org/Files/DevTools/i686-kgp-mingw32/arm-kgp-eabi_@_i686-kgp-mingw32_20160503_TANACETUM.7z

 

для тех кто хочет собрать прогу под linux64 для win64

www.klen.org/Files/DevTools/x86_64-kgp-linux-gnu/x86_64-kgp-mingw32_@_x86_64-kgp-linux-gnu_20160503_TANACETUM.7z

 

для тех кто хочет собрать прогу под win64 для win64

www.klen.org/Files/DevTools/x86_64-kgp-mingw32/x86_64-kgp-mingw32_@_x86_64-kgp-mingw32_20160503_TANACETUM.7z

 

для тех кто хочет собрать прогу под linux64 для win32

www.klen.org/Files/DevTools/x86_64-kgp-linux-gnu/i686-kgp-mingw32_@_x86_64-kgp-linux-gnu_20160503_TANACETUM.7z

 

для тех кто хочет собрать прогу под win32 для win32

www.klen.org/Files/DevTools/i686-kgp-mingw32/i686-kgp-mingw32_@_i686-kgp-mingw32_20160503_TANACETUM.7z

 

что то забыл? mips32, m68k?