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

cosmobot

Свой
  • Постов

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

  • Посещение

Репутация

0 Обычный

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

  • Звание
    Местный
    Местный

Контакты

  • Сайт
    Array
  • ICQ
    Array

Посетители профиля

1 447 просмотров профиля
  1. Да занятный девайс , жаль нет Ethernet родного, цены бы ему не было.
  2. это два разных gcc один собран для таргета совместимого с x86 (ну или выше) второй для arm (а может и тупо симлинк , в некоторых тулчайнах и такое можно увидеть ) предполагаю что со времени своей компиляции
  3. Пытаюсь сравнить две "архитектуры" (скорее ниши ядра) с не очень технической точки зрения(поскольку с технической пока просто некомпетентен) Вот примерно какие критерии выбрал для сравнения Собственно для ARM и MIPS 1) Наличие доступных средств аппаратной отладки/эмуляции (проприетарных\свободных): +- 2) Наличие качественных тулчайнов: ++ (GCC и куча пропиетарных) 3) Область применения , приложения : мобильные сетевые 4) Производительность: ? (понятно что получается нечто вроде средней температуры по больнице но все же ) 5) Наличие квалифицированных специалистов с опытом разработки приложений для данной архитектуры: +- 6) Литература , количество , качество: +- 7) Свободные ОС : ++ (Linux как минимум) 8) Распространённость : +- 9) Перспективность: +- ? Может кто нибудь прокомментирует . Любые идеи приветствуются. Любые ссылки на документы , маркетинговые сравнения были бы весьма полезны. Собственно задача для меня сводится к пониманию подходит ли МК на ядре ARM для создания сетевых приложений, либо все же не зря все известное мне сетевое оборудование начиная от цисок , заканчивая принтерами и дсл мыльницами построена на MIPS МК.
  4. Да я уже понял и посмотрел на цены , на сии девайсы. И как-то желания поубавилось трогать МИПС.
  5. Тоже кстати интересно на мипсах что то отлаживать нормально . Может для этого нужные специальные кристаллы с нормальным jtag? Такое впечатление что ejtag для отладки не предназначен :-)
  6. Читай скрипт /etc/init.d/network именно он занимается поднятием интерфейсов обычно он хранит конфиги в /etc/sysconfig/network-scripts/ Там несколько текстовых файлов вида ifcfg-ethX , дальше думаю понятно.
  7. Вот тоже подумал над этим . В принципе в документации вполне доступно написано как добавить атвосборку любого софта (в том числе и ядра) , и даже каталог package/linux существует. Но он пуст. Вот мне тоже интересно почему? Может разработчики buildroot предлагают использовать другую систему сборки для ядра? ХЗ. Можно конечно сделать и самому. Но очень не хочется .. ибо есть стойкое ощущение что это будет велосипед. И все до нас уже давно сделали. Может кто нибудь прояснит ситуацию?
  8. хочу понять что перспективней: SystemC vs SystemVerilog Вы не одиноки в этой задаче. Думаю этот выбор скорее должен определяться вашим бакграундом и целями. CoCentric SystemC Compiler имеется на фтп, впрочем как Precision.
  9. Вот оно: Advanced Verification Methodology Cookbook от MentorGraphics http://www.mentor.com/products/fv/_3b715c/cb_download.cfm Содержание ИМХО интересное.
  10. В Windows API есть все для связи через порты. В том числе можно и кэширование отключать. Есть все. Кроме прямого доступа к эти портам:-) Как пример можно привести программный spi, one-wire, twi на com. Думаю avreal или avrdude тоже не дураки писали.
  11. Кстати отсутствие нормальной литературы это одна из главных причин не использовать delphi и builder. Книги большинства авторов это - перевод справки растянутый на стони страниц с примерами. Архангельский пишет ересь , к примеру как то встретил в его книге фразу о том что sql придумал microsoft в 70х годах:-) Жуть. Более менее нормальный автор это Марко Канту с Mastering Delphi 7 (и ниже), на английском можно найти в интернете, перевод в книжном магазине. В что-такое "драйвер"? Я естестствено не раз ставил дрова на машину.... Но одно дело поставить драйвер а другое написать его... Ну во первых "драва", дрова это то что в лесу. Драйвер это как правило часть кода ядра ОС вмонтированная монолитно или подгружаемая как модуль которая отвечает за взаимодействие системы с конкретным железом или реализацию протокола или фильтра. Как правило драйвер работает в нулевом кольце, но не обязательно. Писать драйверы в принципе можно на многих языках в том числе и на асме, но мелкомягкие поддерживают описания структур ядра и системных сервисов(не путать со службами и сервисами в понимании драйвера) только для Си . Но одно дело поставить драйвер а другое написать его... Если есть связь с компьютером то драйвер нужен обязательно? В принципе нет , но на практике да(для NT) другой вопрос что такие задачи как управление портами уже имеют множетсво решений с драйверами которые просто цепляются к программе (см. winio, dlport и т.д.). В форуме интерфейсы есть подобные темы и рекомендации различных библиотек с драйверами которые возьмут низкуорвневую работу на себя. Или без драйвера программа нечего принимать и отпралять не будет? Ну вобщем если не трудно то просвятите пожал Под 98 все будет нормально , под NT не совсем , ибо при доступе к порту через файловый дискриптор будет использоваться внутренние механизмы кеширования windows. Работать будет скорее всего но через Ж. Есть хорошая книжка по внутреннему устройству Windows NT, авторы Соломон , Русинович - Внутреннее устройство Windows 2000 (Inside for MS Windows 2000) , имеется в интернете в виде скана, так и в магазине.
  12. ИМХО разницы нет. Затраты на изучение синтаксиса нового языка ничтожны. Тут скорее надо сравнивать библиотеки обертки для Win API Builder, Delphi , все равно обе среды используют туже библиотеку VCL , которая написана на Delphi и в исходники которой вам придется заглядывать если вы собираетесь более менее серьезно программировать хоть в среде Delphi хоть в Builder. Язык Delphi(ex Object Pascal) имеет также гораздо более шустрый компилятор чем любой сишный, что тоже удобно. ИМХО VCL одна из лучших ОО оберток для win api, которая без больших затрат позволит реализовать морды для большинства приложений ну и логику, правда Win APi вам тоже придется иногда использовать. Что же касается Visual Studio и интерфейсов, тот тут есть варианты, 1)при необходимости компиляции в native код: вам придется иметь дело с MFC которая на мой сугубо субьективный взгляд (Г.) нелогичное убогое и т.д. , можно конечно писать все на WinAPI , но это дело неблагодарное. Или к примеру использовать Qt или Gtk , но они лицензированы по GPL. 2) всякая ересь типа .net , дает возможность использовать неплохую библиотеку классов для любых задач , но на выходе мы имеем что то типа явовского байт-кода , который требует соотв. ПО на машине пользователя (сколько там .net рантайм весит , метров тридцать?). В общем мелкомягкие хотят сделать из этого будущее(предпологается что со временем читый win32 успешно издохнет). Но пока ХЗ что из получится.
  13. торможу, скачал только license.dat и радуюсь, а там оказывается генератор для любой feature лежит, разобрался, спасибо
  14. Так это я понял, не такой я всетаки медленный газ;-), просто платформ креатор с этой лицензией запускается?
×
×
  • Создать...