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

kolobok0

Участник
  • Публикаций

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

  • Посещение

Репутация

0 Обычный

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

  • Звание
    практикующий тех. волшебник

Контакты

  • Сайт
    http://www.6461530.ru
  • ICQ
    0

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

5 053 просмотра профиля
  1. Корова немного не моя :) Пока фаза сбор инфы. И одна из них - возможно ли изготовить магнит с радиальной намагниченностью. Вот тут выше подсказали, что да возможно. Буду благодарен за посыл по общему вектору... или любую другую инфу наполняющую копилку знаний ... С уважением (круглый)
  2. Да похоже оно. Спасибо! С уважением (круглый) ЗЫ Вот первым делом стал ломится на форум - моя ошибка. а надо было как всегда в гуглю :)
  3. Добрый день! Всем известны как устроены обычные динамики. Формат их магнита - плоский тор, полюса которого располагаются на широких его сторонах (если положить на стол = сверху и снизу). Вопрос: Возможно ли изготовить магнит, полюса которого будут располагаться с торцов такой геометрии (один полюс внутрь, второй наружу) ? С уважением (круглый) ЗЫ Возможно не в ту ветку форума. Поправьте пожалуйста, если так :)
  4. Странная проблема при оптимизации

    +100500 2TC странно когда программист говорит компилятору - а теперь сделай красиво как хошь... а потом требует на отладке все стэпы которые ему казались что должны быть. Не находите? Если вы хотите дебажить выхлоп оптимизатора - то ТОЛЬКО(!) на уровне азма. всё остальное будет от лукавого.
  5. Схема OpenIMU300ZA

    мдя...поспешил начеркать... там модуль с гулькин хвост. сколоть ---дцать минут работы... из за чего сыр бор - хз.. имхо - пиар темы... (круглый)
  6. Схема OpenIMU300ZA

    ну вот у гугля навалом...все ссылки на сайт openimu.readthedocs.io забежав туда натыкаетесь на схему (круглый) ЗЫ это такой стёб типа?
  7. LwIP на STM32F4: потери UDP-пакетов

    ошибка в 55 строке... мало данных. начинайте пилить проблему на составляющие. включите-загляните в статистику lwip. Он показывает приём ваших потерянных пакетов? Если нет - сетевой уровень, плюс взаимодействие. Если ему пофигу и приём успешен - значит затык далее. И ещё. У вас в одном потоке или что то многопоточное прикручено? Используется ли пдп, он же дма :) ? аллокатор памяти какой юзаете? Правильно ли используете сам lwip? удачи вам (круглый) PS Если траблы с lwip-ом - то переносите, заводите топик в сетевов разделе вопросов. Там по сети толковые ответы получите быстрее.
  8. Интерфейс к Nest 3 (ESP8266)

    OFF/2: Вроде сие чудо от 3,3 питалось? удачи вам (круглый)
  9. LwIP, UDP

    1) юарт - не определяет протокол, формат и взаимодействие по нему. Вы можете сами выбирать разрядность, чётность, и т.д.. А уж по формату фрэйма - вообще что угодно и как угодно. UDP определён в конкретном документе. Если Вы изобразите нечто отличное от этого определения - то это уже будет не UDP...увы и ах... В этом собственно и отличие. 2) Это не моя логика. Это есть такая фигня как RFC768 (из разряда, а мужики то и не знали)... 3) В RFC написано... This protocol provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism. Это из описания собственно. сэнд мэссэдж - собственно передача сообщения. ПЕРЕДАЧА. Не буфферезирование, а ПЕРЕДАЧА. Конечно-же можно как угодно трактовать слово "сенд".... но вот так вот написано само определение. 4) Про обработку ошибочных ситуаций не было речи - не теряйте фокус... Естественно речь идёт об успешном ответе при передачи UDP. Так вот, если стэк протокола ответит OK и при этом забуфферизирует данные и не разрешит MAC адресацию то собственно это уже будет не совсем UDP (по описанию)... как то так (круглый)
  10. LwIP, UDP

    вот это в правильной реализации не должно быть по определению. если мы отдали уже управление на вызове с уровня программы, забуфферизировали и успешно грохнулись(ну или не разрешился MAC адрес) - то это собственно нарушение контракта UDP интерфейса для юзверов. (круглый) ЗЫ с ходу в рфс ничего конкретного не нашёл...может смотрел не дотошно - хз...
  11. LwIP, UDP

    По определению. Если изернет стэк это не делает - меняйте(правьте) нафик стэк. UDP - гарантирует ОТПРАВКУ пакета. Т.е. если вам вернулось управление после вызова функции send - то пакет 200% ушёл в сеть. (круглый)
  12. делал подобное в меге128. на лопапалам её флэш делил. компилял как обычно. но делал софтинку для потрошения hex формата (подправлял адресацию). Менял и вектора так-же...прошивал половинку меги + таблицу векторов. у Вас без таблицы векторов, насколько я понимаешь. Общая засада при таких хотелках = проследить чтоб везде была относительная адресация. имхо: компилять обычно как программу. обязательно везде относительная адресация. дать линкеру честно сформировать таблицу нужных вентилей вызовов (таблица векторов ли или некая своя структура адресов функций - не суть). далее корректируем эту таблицу - до загрузки, если адреса загрузки фиксированы. - в момент загрузки, если адрес загрузки не известен. адрес естественно выровнен на нужное смещение. как то так (круглый)
  13. предлагаю перевести в плоскость "какие существуют" или "какие юзали-знаете"... у мну зависило от задачи, камня, возможностей(читай лапок). ногодрыг (осцил, светодиодик), jtag отладка, в лог файл (конфигурирование из ini файла) не юзал, но на мой взгляд заслуживают внимания: - по сети (если проект поддерживает сеть) так-же интересен подход в 1 пин (делается декодер на скорострельной плисине), делается код на сях (разница нолика от единички - в один ноп) и всё...достаточно шустро и не зависит от тактовой... так-же нужно упомянуть про средства ловли hardfault. на обработчик вещаем добычу всей инфы до какой дотянемся (регистры, стэк, затирка стэка, состояние-прохождение контрольных точек если есть) и пишем во флэш. далее при старте считываем(если была запись) из флэша и пишем цивильно в систему логирования. как то так... (круглый)
  14. Ниже больше уклон в софт конечно-же. Но имхо - сильно рояли не играет... 1) Тут уже прозвучало, что Ваши требования и Ваш опыт по созданию подобных вещей в 4 человека = это малосвязанные вещи. Посему к топику можно относится как к философскому-флеймовому... 2) Тут уже выше сказали - в реалиях РФ успешного, чисто технического коллектива найти не реально. Уже несколько раз водолазы из экономики сообщали что мы имеем тенденцию движения вниз а не на всплытие. И без распила, откатов, личного вась-вась большие деньги не попадают к успешным. Можно искать конечно-же среди плавающих на поверхности фирм, но задачи там решаются не только или лучше сказать не столько технически, сколько административным ресурсом. Т.е. с точки зрения коллектива, тех. спецов и организации производства - в основном там эээээээ завал; ну или более мягше - можно работать лучше... 3) По поводу быстро-rt-передовое... Не скажу, что это то, что Вам требуется - но вэбовские проекты, банки, биржевые дела = так же пытаются входить в заявленные Вами диапазоны. Года 4 назад был например в гостях у трэйдеров(чиссо как пример) - платформа для играков на бирже. Ребята ушли от высокоуровневых языков и от объектов синхронизации. Так-же ловят микросекунды. Так-же банковские системы(подтверждение банковских транзакций), базируясь на вчерашних студентах (т.е. совсем не оптимально) и на высокоуровневых языках в лёгкую выходят на единицы миллисекунд(принятие решения, своя замудрённая логика, система хранения информации). Или RT анализ сетевого трафа(чиссая математика в плане анализа - привлекаются из НИИ люди) и принятия решения - скорострельность думаю прикинете сами. Причём на современном уровне в техническом плане масштабирование-отказоустойчивость-пропускная_способность и т.п. задачи - уже вышли из области самих разработчиков(их грамотности) и больше уже касается архитектурных построений и возможностей клиента в финансовом плане по развёртыванию(поддержанию) инфраструктуры. 4) по поводу оптимальности человеко-ресурсов. исходя из успешного опыта по управлению людьми, оптимальным коллективом в 40-70 человек можно решать любые IT задачи на должном уровне. Это если коротко. Но помянуя ситуацию в РФ - создание такого коллектива займёт месяцев (3-6) в лучшем случае. Спецов просто нет. Молодёжь надо учить, иначе они находятся в эйфории рекламных слоганов, а хотят уже и сейчас. А стариков(если по каким либо причинам завис в стране) надо счищать административную шелуху и воодушевлять на творчество. Про грамотных управленцев вообще нечего сказать - их нет на рынке. (Чиссо пример: тут недавно был в гостях. и на вопрос к тех. директору = нафига вам управленцы ответ подтверждающие мои слова: нет прироста выхлопа, при увеличении числа разработчиков. Т.е. думали, что оно само. А оказалось что разница есть как посадить квартет :) И понимают - проблемы в управлении, но мало верят, что начинать сокращения надо с себя-же любимых.) Итого... Ростите сами своих крутых спецов, оптимизируйте по управлению коллектив. И отписывайтесь спустя месяцы сюда - мы все порадуемся за Вас. удачи Вам, она Вам потребуется... (круглый)