Перейти к содержанию
    

podelkin

Участник
  • Постов

    14
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о podelkin

  • День рождения 12.05.1986

Контакты

  • Сайт
    Array
  • ICQ
    Array
  1. IP/UDP/TFTP uIP v1.0

    а lwip слишком тяжел? По мне так продвинутее на порядок
  2. Родился более производительный вариант uint32_t RTC_GetCounter(void) { uint32_t counter; uint16_t tmp; do { tmp = RTC->CNTH; counter = (((uint32_t)tmp << 16 ) | RTC->CNTL); } while(tmp != RTC->CNTH); return counter; }
  3. Ничем не лучше, на мой взгляд. Молчит как партизан.
  4. STM32 библиотечный RTC_GetCounter

    на мой взгляд теущая реализация RTC_GetCounter в стандартной библиотеки от ST не совсем корректная и при переполнении нижнего 16 битного регистра может вернутся неверное значение (что происходит примерно раз в 18 часов) uint32_t RTC_GetCounter(void) { uint16_t tmp = 0; tmp = RTC->CNTL; return (((uint32_t)RTC->CNTH << 16 ) | tmp); } предлогаю следующий вариант, что скажете? если uint32_t RTC_GetCounter(void) { uint32_t counter; uint16_t tmp; do { tmp = RTC->CNTL; counter = (((uint32_t)RTC->CNTH << 16 ) | tmp); } while(tmp != RTC->CNTL); return counter; }
  5. Захотел тут через меню ExternalTools в Eclipse залить камень. Использую openocd под виноус (приходится в нем на работе сидеть :crying: ) Встала задача через .bat файл подключиться через telnet и выполнить скрипт (openocd всегда работает в фоне) .bat это вам не shell в линукс. всякие перенаправления не работают. Нашел решение: используем TST10.exe (Telnet Scripting Tool) google в помощь - первая ссылка. запускаем из external tools TST10.exe /r:telnet_script.txt сам :telnet_script.txt: localhost 4444 SEND "script load_firmware.tcl\m" WAIT ">" SEND "exit\m" в load_firmware.tcl пишем собственно прошивку. у меня так echo "Load Firmware" halt flash write_image erase unlock ../Debug/firmware.hex 0 ihex reset может кому поможет ;) если используете openocd то попробуйте при инициализации вставить определение события при отключении gdb продолжить выполнение как-то так #продолжить выполнение, когда отключается GDB $_TARGETNAME configure -event gdb-detach { echo "GDB disconnect, but resume"; resume } может поможет, у меня так стоит и ничего не вылезает
  6. Тоже на эти грабли наступал, но почему то сразу увидел что они не работают) повезло мне
  7. Странно, может из-за кэша на работе Ваш пост от Oct 26 2011, 08:12 я увидел только сейчас. сейчас попробовал скомпилировать простейший пример из поста выше и все собралось :cranky: вернул lib.a к первоначалному виду и мой проект теперь компилица без ошибок Какого лешего gcc раньше тянул mloc.o из библиотеки я так понял(( поначалу тоже подумал что я ошибся в написании __malloc_unlock, но тогда бы у меня не собралось бы приложение после выкидывания mloc.o из libc.a (к тому же я смотрел отладчиком мои __malloc_lock и __malloc_unlock прилежно вызывались, то есть были написаны без ошибок) Остановлюсь на том что где-то кривизна моих рук ускользнула от моего взгляда... Вообщем alx2 респект :a14: А я теперь умею шаманить с символами и знаю ключ --allow-multiple-definition который нафиг не нужен :08:
  8. Все линкуется как обычно. На mlock ссылается сам malloc. но в исходниках newlib __malloc_lock вызывает __lock_acquire, который определен по умолчанию как #define __lock_acquire(lock) (_CAST_VOID 0) #define __lock_acquire_recursive(lock) (_CAST_VOID 0) то есть символ __malloc_lock в библиотеке есть, но он ничего не делает, только мешает определить свой __malloc_lock. Поэтому и пришлось выкинуть mlock.o из libc.a, чтоб спокойно определить свои __malloc_lock, который бы защитил кучу в много поточной среде. После 2ух дней тестов все работает. Уже пишу, поскольку не нашел никакой информации на форуме по использованию malloc из newlib (и *printf по зависимостям также) из многопоточной среды, надеюсь кому-то поможет. кстати исправил определение своих символов на : void __malloc_lock(struct _reent *r) { vTaskSuspendAll(); } void __malloc_unlock(struct _reent *r) { xTaskResumeAll(); } чтоб не терять прерывания во время работы с памятью Все работает
  9. Вобщем решил сделать так: В программе реализовал лок кучи через FreeRTOS void __malloc_lock (struct _reent *r) { vPortEnterCritical(); } void __malloc_unlock (struct _reent *r) { vPortExitCritical(); } чтоб не было ошибки линковки - выполняю команду arm-none-eabi-ar dv libc.a lib_a-mlock.o libc.a - который используется в данный момент ( у меня это arm-none-eabi/lib/thumb/v7m\libc.a поскольку cortex-m3), зависит от multilib она удаляет из архива объектник с mlock. Все. буду тестировать newlib'ский malloc, мне кажется он должен быть понадежнее, чем FreeRTOS'овский.
  10. так __malloc_lock() и __malloc_unlock() не определяются из-за ошибки линкера! multiple definition of `__malloc_lock' нашел вот это mail архив newlib этож чтож - пересобирать? :crying: пока придумал удалить mlock.o из libc.a чтоб линкер не ругался, кто что думает пока нашел сырое решение опция линкера --allow-multiple-definition теперь я могу определить свой void __malloc_lock (struct _reent *r) и он вызывается! только вот криво это, буду копать дальше
  11. глюк. может стек переполнился? или только при отладке? Hook'и FreeRTOS не сработали?
  12. stm32f1x нормально шьется. но только на 0.5.0. в 0.4.0 были ошибки драйвера. может теперь обязательно надо формат файла? flash write_image erase unlock ../Debug/firmware.hex 0 ihex что пишет то хоть?
  13. в исходниках newlib увидел MALLOC_PROVIDED, никто не пробовал объявлять? тогда вроде newlib не будет свою malloc компилить
  14. Народ, помогите все по полкам разложить. Все началось с того, что хотел прикрутить *printf из newlib. В проекте используется FreeRTOS. По прошлому опыту ожидал, что сразу возникнут ошибки линковки _sbrk ,_write, _read и т.д. Но все скомпилировалось нормально :cranky: . ToolChain от klen'а (спасибо ему) При запуске из под отладчика выпал в _swiwrite на инструкции bkpt. Копаясь в исходниках newlib 1.19 нашел где это. Правильно ли я понял, что это из-за сборки newlib без ключа --disable-newlib-supplied-syscalls? Дальше я скачал yagarto, заменил компилятор. и ошибки линковки возникли (я впервые был ряд ошибкам ))) Реализовал syscalls, и все заработало. Но!!! printf использует malloc, malloc вызывает _sbrk для получения памяти. в исходниках для блокировки кучи используется вызовы _malloc_lock и _malloc_unlock. Отладчиком смотрел, они пустые (и в исходнике newlib их смотрел) void __malloc_lock (ptr) struct _reent *ptr; { #ifndef __SINGLE_THREAD__ __lock_acquire_recursive (__malloc_lock_object); #endif } Значит из многопоточной среды вызывать printf черевато :crying: (и malloc тоже) собственно вопросы: можно ли заставить ToolChain klen'a работать с моими syscalls без пересборки newlib как залочить кучу newlib в проекте FreeRTOS (пересобирать что-ли без __SINGLE_THREAD__) если прошлое нельзя, то может наоборот заставить newlib использовать vPortMalloc из FreeRTOS За любую помощь заранее благодарен!
×
×
  • Создать...