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

vanner

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

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

  • Посещение

Весь контент vanner


  1. Да, абсолютно понятна ваша мысль, вы совершенно не занимаетесь проектированием своего ПО. Конечно трудно протестировать спаггети-код который делает несколько функций сразу, да еще программист пишет одной рукой ;) В общем, читайте книги, практикуйтесь, со временем все придет :)
  2. Смотрите выше, andrewlekar на пальцах объяснил как это делается. Это классическое TDD. Написали тест, написали функцию. Для эмбедед, конечно, запуск юнит-тестов на таргете не всегда удобен, я бы даже сказал, что не требуется. Поэтому приходится грамотно разделять логику программы и обращение к железу. Этого достаточно, чтобы провести тестирование всей логики/математики на ПК. соответсвенно тесты не будут даже входить в прошивку, для которой обычно имеются жесткие ограничения на размер используемой памяти. Для некоторых вещей связанных с железом можно применить такие техники как Mock-объекты. Например, чтение с АЦП заменяем на чтение из файла. Вот вкратце, что можно сделать юнит-тестами. Можно, конечно, копнуть глубже, использовать всякие симуляторы, но зачастую допиливание нормальной модели занимает слишком много времени. Это оправдано только для проектов, которые необходимо развивать и поддерживать многие годы :) Ну и не стоит забывать, что юнит-тесты это только одна из фаз тестирования системы.
  3. Я сомневаюсь в том, что проверка корректности синтаксиса улучшает качество, можно совершенно корректно для компилятора написать вещи, которые содержат ошибки. Хотя чистота кода да - это полезное свойство. Вероятность, что пропущенный warning может привести к ошибке имеется. Но это никак не относится к тестированию. Все таки первая задача модульного тестирования - это проверка корректности работы функции (модуля), т.е. проверка условия что при указаных входных данных получается корректный результат и/или корректная обработка ошибки. Проверка регрессий это уже побочный эффект по-сути, при наличии ранее работоспособных тестов легко определить какое изменение сломало модуль.
  4. Не путайте теплое с мягким, юнит-тесты используются для проверки логики. Статический анализ для выявления некоторых багов, и обычно статический анализ все таки сложнее, чем проверка компилятором правильности только синтаксиса кода. Да, в llvm, вроде, есть какие-то средства статического анализа.
  5. Добавь в command line ядра: quiet
  6. Для начала определись, какой имеено процессор используется в этом девайсе, вероятнее всего именно его эмулировать qemu не умеет. И какова цель запуска прошивки? Можно взять и собрать ядро linux под один из эмулируемых qemu чипов и подсунуть имеющийся rootfs, конечно, некоторые аппаратно зависимые вещи сэмулировать не удастся. В общем зависит от задачи.
  7. приложение win32

    Лучше один раз модифицировать исходники, чем бороться с проблемами костылей в дальнейшем, в том же wine не все гладко от версии к версии, и его допиливание гораздо сложнее правки собственных исходников.
  8. приложение win32

    Если есть исходники, то какой смысл использовать костыли? Ну и вообще можно попробовать в qemu-user chroot запустить на арме линукс для х86 с wine и вашим exe, но производительность будет соответсвующая :)
  9. Если нужна практичность и документированность, да еще и под линукс - то лучше смотреть в сторону beagleboard или beaglebon. Будет, конечно, чуть дороже бюджета, с LCD раза в 2 больше где-то.
  10. Сборка RootFS

    Возьми Buildroot или OpenEmbedded и собирай.
  11. Mini6410

    На сайте производителя все есть, http://www.friendlyarm.net/downloads
  12. Еще один вариант - компилировать в qemu-user chroot-е - http://www.gentoo.org/proj/en/base/embedde...rt=1&chap=5
  13. Возможно пригодится в дальнейшем http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html
  14. И не будет работать, HTTP работает по TCP. В Qt для работы по HTTP есть класс QHttp.
  15. Прочитай еще раз, что делает sizeof() и подумай, почему твой код не работает.
  16. Показывают снифферы энумерацию, например, USBlyzer, USBTrace.
  17. С чего начать dsPIC.

    Не путай I2C и I2S. У dsPIC другая периферия. Под dsPIC можно бесплатно использовать студенческую версию компилятора C30 dsPIC.
  18. Нужно добавить приставку L к строковым литералам (L"COM2") или в настройках проекта отключить использование Unicode.
  19. мплаб и пик

    Ничего забавного в этом явлении нет, такой вычисляемый goto работает только в пределах страницы, если переход может попадать на несколько страниц, нужно корректировать pclath.
  20. Возьми какой нибудь PIC18 со встроенным Ethernet (например PIC18F66J60), стек TCP/IP тоже дают готовый. Осатанеться только припаять разъем :)
  21. Когда же вы начнете читать манулы? В модуле init.asm объяви процедуру как глобальную, т.е. GLOBAL InitProc Можеш создать файл init.inc и приинклюдить его к main.asm или прямо в main.asm объявить эту процедуру как внешнюю. EXTERN InitProc
  22. В чем вопрос? Бери любой нравящийся компилятор и смотри как использовать ассемблерные вставки и файлы в документации. Особенности оформления ассемблерного текста, вызов функций и т.п. будут там описаны.
  23. pic18f4525_little help

    Да что так скромно, проси сразу готовый код. Как ты вообще собираешься программировать, если ты не можешь написать простейшее? Читай мануалы и смотри примеры идущие с компилятором.
  24. Не нужно инклюдить ассемблерный файл. В проект добавляются нужные asm файлы, в тех файлах, функции или переменные в которых нужно видеть в другом модуле, эти функции описываются директивой global. Чтобы вызвать функцию или переменную из другого модуля, нужно описать ее как extern. Это удобно сделать в файл inc, для каждого модуля. Вот этот inc файл и нужно инклюдить. Скрипт линкера менять не требуется.
  25. PIC + ИК порт

    www.microchip.com/irda
×
×
  • Создать...