Jump to content

    

vanner

Участник
  • Content Count

    48
  • Joined

  • Last visited

Community Reputation

0 Обычный

About vanner

  • Rank
    Участник
  • Birthday 12/24/1981

Контакты

  • Сайт
    Array
  • ICQ
    Array
  1. Да, абсолютно понятна ваша мысль, вы совершенно не занимаетесь проектированием своего ПО. Конечно трудно протестировать спаггети-код который делает несколько функций сразу, да еще программист пишет одной рукой ;) В общем, читайте книги, практикуйтесь, со временем все придет :)
  2. Смотрите выше, andrewlekar на пальцах объяснил как это делается. Это классическое TDD. Написали тест, написали функцию. Для эмбедед, конечно, запуск юнит-тестов на таргете не всегда удобен, я бы даже сказал, что не требуется. Поэтому приходится грамотно разделять логику программы и обращение к железу. Этого достаточно, чтобы провести тестирование всей логики/математики на ПК. соответсвенно тесты не будут даже входить в прошивку, для которой обычно имеются жесткие ограничения на размер используемой памяти. Для некоторых вещей связанных с железом можно применить такие техники как Mock-объекты. Например, чтение с АЦП заменяем на чтение из файла. Вот вкратце, что можно сделать юнит-тестами. Можно, конечно, копнуть глубже, использовать всякие симуляторы, но зачастую допиливание нормальной модели занимает слишком много времени. Это оправдано только для проектов, которые необходимо развивать и поддерживать многие годы :) Ну и не стоит забывать, что юнит-тесты это только одна из фаз тестирования системы.
  3. Я сомневаюсь в том, что проверка корректности синтаксиса улучшает качество, можно совершенно корректно для компилятора написать вещи, которые содержат ошибки. Хотя чистота кода да - это полезное свойство. Вероятность, что пропущенный warning может привести к ошибке имеется. Но это никак не относится к тестированию. Все таки первая задача модульного тестирования - это проверка корректности работы функции (модуля), т.е. проверка условия что при указаных входных данных получается корректный результат и/или корректная обработка ошибки. Проверка регрессий это уже побочный эффект по-сути, при наличии ранее работоспособных тестов легко определить какое изменение сломало модуль.
  4. Не путайте теплое с мягким, юнит-тесты используются для проверки логики. Статический анализ для выявления некоторых багов, и обычно статический анализ все таки сложнее, чем проверка компилятором правильности только синтаксиса кода. Да, в llvm, вроде, есть какие-то средства статического анализа.
  5. Добавь в command line ядра: quiet
  6. Для начала определись, какой имеено процессор используется в этом девайсе, вероятнее всего именно его эмулировать qemu не умеет. И какова цель запуска прошивки? Можно взять и собрать ядро linux под один из эмулируемых qemu чипов и подсунуть имеющийся rootfs, конечно, некоторые аппаратно зависимые вещи сэмулировать не удастся. В общем зависит от задачи.
  7. Лучше один раз модифицировать исходники, чем бороться с проблемами костылей в дальнейшем, в том же wine не все гладко от версии к версии, и его допиливание гораздо сложнее правки собственных исходников.
  8. Если есть исходники, то какой смысл использовать костыли? Ну и вообще можно попробовать в qemu-user chroot запустить на арме линукс для х86 с wine и вашим exe, но производительность будет соответсвующая :)
  9. Если нужна практичность и документированность, да еще и под линукс - то лучше смотреть в сторону beagleboard или beaglebon. Будет, конечно, чуть дороже бюджета, с LCD раза в 2 больше где-то.
  10. Возьми 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() и подумай, почему твой код не работает.