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

spongebob

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

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

  • Посещение

Сообщения, опубликованные spongebob


  1. Ну там две сборки. Одна на Убунте, другая на Дебиане. Обе не рекомендуют себя в продакшн.
    А чем systemd плох?

    Надо что-то попроще. Готовый дистрибутив.

     

    Bionic — дистрибутив основан на Ubuntu 18.04.5 LTS (Bionic Beaver).
    Focal — дистрибутив основан на Ubuntu 20.04.1 LTS (Focal Fossa).
    Buster — дистрибутив основан на Debian 10.7.
    Buster xfce desktop — дистрибутив основан на Debian 10.7, с установленным графическим интерфейсом xfce.
    Bullseye — дистрибутив основан на Debian 11 Bullseye.

  2. Всем привет.

    Подскажите, пожалуйста, кто пользует Armbian, что там у них со стабильностью и надежностью?
    При первом старте и настройке выдает, что сборка автоматическая и не предназначена для продакшн. 
    Это что значит? Что все нестабильно и плохо или все нормально и они так просто ответственность с себя снимают?

    Пробовал две сборки со страницы https://www.armbian.com/orange-pi-pc/
    Это Armbian 22.02 Bullseye и Armbian 22.02 Focal XFCE.

  3. 1 hour ago, aaarrr said:

    Потому что собрали для armhf. aarch64 имеет обратную совместимость с ним.

    Если не сложно, объясните, пожалуйста, подробнее... путаюсь я в этих архитектурах и совместимостях...

    Я вот к AVRам привык, там понятнее :)

  4. Я собрал на рабочем компе сначала тестовую программу, залил на Апельсину, проверил. Работает.
    Потом основную софтину залил - тоже работает.
    Получается, что на Апельсине работает то, что я собрал для Малины...
    Объясните, пожалуйста, почему?
    Разные процессоры, разные архитектуры, никаких платформозависимых ключей при сборке не было...

  5. 49 minutes ago, Eddy_Em said:

    Честно говоря, я не понимаю, зачем это делать: почему не собрать прямо на одноплатнике? Все равно ведь исходный код распространяется по GPLv3…

    Неудобно на одоплатнике, IDE на рабочем компе, бинари копирую.

  6. 1 hour ago, Eddy_Em said:

    Что значит "подойдет ли"? Ты просто ставишь gcc из репозитория - и всë!

    Если же нужно собрать систему из виртуалки, подними в qemu'вском чруте систему, там и собирай. Если нужна  инструкция, могу скинуть ссылку (но это элементарно гуглится). Я себе генту для одноплатников так и собирал: на самом одноплатнике это будет длиться вечность, поэтому просто на нормальном серваке в 64 потока собирал под эмулятором. А после всего записал готовый образ на флешку и воткнул в одноплатник — вуаля!

    Забыл уточнить, нужен именно кросс-компилятор. Т. е., нужно собирать на простой рабочей машине, под Линухом. Собираю для Малины и нужно теперь собирать для Апельсины.

  7. Ранее собирал этим компилятором для Малины (Raspberry Pi 3 B+) - https://www.raspberrypi.com/products/raspberry-pi-3-model-b-plus/ Она 64 бит Cortex-A53 (armv8).
    Теперь нужно собирать для Апельсины (Orange Pi PC) - http://www.orangepi.org/orangepipc/ Она 32 бит Cortex-A7 (armv7).

    Объясните, пожалуйста, где и что смотреть... где указаны процессоры, архитектуры и т. п. для компилятора.
    Посмотрел доки на свой компилятор (опции для ARM), вроде, есть там и armv8 для Малины и armv7 для Апельсины, но не уверен... буквы там всякие еще... я не понимаю, как сопоставить поддерживаемые архитектуры (конкретные процессоры?) компилятором определенным процессорам (их архитектурам, они ведь обычно в описании для плат указываются?).
    В общем, вопрос-то по сути сводится к тому, как подобрать компилятор к процессору...

    Spoiler
    -march=name

    This specifies the name of the target ARM architecture. GCC uses this name to determine what kind of instructions it can emit when generating assembly code. This option can be used in conjunction with or instead of the -mcpu= option. Permissible names are: ‘armv2’, ‘armv2a’, ‘armv3’, ‘armv3m’, ‘armv4’, ‘armv4t’, ‘armv5’, ‘armv5e’, ‘armv5t’, ‘armv5te’, ‘armv6’, ‘armv6-m’, ‘armv6j’, ‘armv6k’, ‘armv6kz’, ‘armv6s-m’, ‘armv6t2’, ‘armv6z’, ‘armv6zk’, ‘armv7’, ‘armv7-a’, ‘armv7-m’, ‘armv7-r’, ‘armv7e-m’, ‘armv7ve’, ‘armv8-a’, ‘armv8-a+crc’, ‘armv8.1-a’, ‘armv8.1-a+crc’, ‘armv8-m.base’, ‘armv8-m.main’, ‘armv8-m.main+dsp’, ‘iwmmxt’, ‘iwmmxt2’.

    Architecture revisions older than ‘armv4t’ are deprecated.

    -march=armv6s-m is the ‘armv6-m’ architecture with support for the (now mandatory) SVC instruction.

    -march=armv6zk is an alias for ‘armv6kz’, existing for backwards compatibility.

    -march=armv7ve is the ‘armv7-a’ architecture with virtualization extensions.

    -march=armv8-a+crc enables code generation for the ARMv8-A architecture together with the optional CRC32 extensions.

    -march=armv8.1-a enables compiler support for the ARMv8.1-A architecture. This also enables the features provided by -march=armv8-a+crc.

    -march=armv8.2-a enables compiler support for the ARMv8.2-A architecture. This also enables the features provided by -march=armv8.1-a.

    -march=armv8.2-a+fp16 enables compiler support for the ARMv8.2-A architecture with the optional FP16 instructions extension. This also enables the features provided by -march=armv8.1-a and implies -mfp16-format=ieee.

    -march=armv8.2-a+dotprod enables compiler support for the ARMv8.2-A architecture with the optional Dot Product instructions extension. This also enables the features provided by -march=armv8.1-a.

    -march=armv8.2-a+fp16+dotprod enables compiler support for the ARMv8.2-A architecture with the optional FP16 and Dot Product instructions extension. This also enables the features provided by -march=armv8.1-a and implies -mfp16-format=ieee.

    -march=native causes the compiler to auto-detect the architecture of the build computer. At present, this feature is only supported on GNU/Linux, and not all architectures are recognized. If the auto-detect is unsuccessful the option has no effect.

    -mtune=name

    This option specifies the name of the target ARM processor for which GCC should tune the performance of the code. For some ARM implementations better performance can be obtained by using this option. Permissible names are: ‘arm2’, ‘arm250’, ‘arm3’, ‘arm6’, ‘arm60’, ‘arm600’, ‘arm610’, ‘arm620’, ‘arm7’, ‘arm7m’, ‘arm7d’, ‘arm7dm’, ‘arm7di’, ‘arm7dmi’, ‘arm70’, ‘arm700’, ‘arm700i’, ‘arm710’, ‘arm710c’, ‘arm7100’, ‘arm720’, ‘arm7500’, ‘arm7500fe’, ‘arm7tdmi’, ‘arm7tdmi-s’, ‘arm710t’, ‘arm720t’, ‘arm740t’, ‘strongarm’, ‘strongarm110’, ‘strongarm1100’, ‘strongarm1110’, ‘arm8’, ‘arm810’, ‘arm9’, ‘arm9e’, ‘arm920’, ‘arm920t’, ‘arm922t’, ‘arm946e-s’, ‘arm966e-s’, ‘arm968e-s’, ‘arm926ej-s’, ‘arm940t’, ‘arm9tdmi’, ‘arm10tdmi’, ‘arm1020t’, ‘arm1026ej-s’, ‘arm10e’, ‘arm1020e’, ‘arm1022e’, ‘arm1136j-s’, ‘arm1136jf-s’, ‘mpcore’, ‘mpcorenovfp’, ‘arm1156t2-s’, ‘arm1156t2f-s’, ‘arm1176jz-s’, ‘arm1176jzf-s’, ‘generic-armv7-a’, ‘cortex-a5’, ‘cortex-a7’, ‘cortex-a8’, ‘cortex-a9’, ‘cortex-a12’, ‘cortex-a15’, ‘cortex-a17’, ‘cortex-a32’, ‘cortex-a35’, ‘cortex-a53’, ‘cortex-a57’, ‘cortex-a72’, ‘cortex-a73’, ‘cortex-r4’, ‘cortex-r4f’, ‘cortex-r5’, ‘cortex-r7’, ‘cortex-r8’, ‘cortex-m33’, ‘cortex-m23’, ‘cortex-m7’, ‘cortex-m4’, ‘cortex-m3’, ‘cortex-m1’, ‘cortex-m0’, ‘cortex-m0plus’, ‘cortex-m1.small-multiply’, ‘cortex-m0.small-multiply’, ‘cortex-m0plus.small-multiply’, ‘exynos-m1’, ‘marvell-pj4’, ‘xscale’, ‘iwmmxt’, ‘iwmmxt2’, ‘ep9312’, ‘fa526’, ‘fa626’, ‘fa606te’, ‘fa626te’, ‘fmp626’, ‘fa726te’, ‘xgene1’.

    Additionally, this option can specify that GCC should tune the performance of the code for a big.LITTLE system. Permissible names are: ‘cortex-a15.cortex-a7’, ‘cortex-a17.cortex-a7’, ‘cortex-a57.cortex-a53’, ‘cortex-a72.cortex-a53’, ‘cortex-a72.cortex-a35’, ‘cortex-a73.cortex-a53’.

    -mtune=generic-arch specifies that GCC should tune the performance for a blend of processors within architecture arch. The aim is to generate code that run well on the current most popular processors, balancing between optimizations that benefit some CPUs in the range, and avoiding performance pitfalls of other CPUs. The effects of this option may change in future GCC versions as CPU models come and go.

    -mtune=native causes the compiler to auto-detect the CPU of the build computer. At present, this feature is only supported on GNU/Linux, and not all architectures are recognized. If the auto-detect is unsuccessful the option has no effect.

    -mcpu=name

    This specifies the name of the target ARM processor. GCC uses this name to derive the name of the target ARM architecture (as if specified by -march) and the ARM processor type for which to tune for performance (as if specified by -mtune). Where this option is used in conjunction with -march or -mtune, those options take precedence over the appropriate part of this option.

    Permissible names for this option are the same as those for -mtune.

    -mcpu=generic-arch is also permissible, and is equivalent to -march=arch -mtune=generic-arch. See -mtune for more information.

    -mcpu=native causes the compiler to auto-detect the CPU of the build computer. At present, this feature is only supported on GNU/Linux, and not all architectures are recognized. If the auto-detect is unsuccessful the option has no effect.

     

  8. Всем привет!

    Подскажите, пожалуйста, как понять, подходит ли компилятор для определенного процессора или нет.
    Где конкретно в документации указаны процессоры, совместимость?

    К примеру.
    Есть gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf для Raspberry.
    Подойдет ли он для Orange?
    Нужны ли какие-нибудь особые опции?

  9. 13 hours ago, Darth Vader said:

    Операции чтение-модификация-запись неатомарны ни для каких типов. Если таковые имеются над этой переменной в вашем коде (например |=, &= ), то средства межпроцессного взаимодействия нужны.

    Не, чтение-модификация-запись - у меня нет. У меня bool. Два процесса, просто читают, пишут, проверяют значение.

  10. 49 minutes ago, k155la3 said:

    нужно ли обеспечивать межпроцессорную синхронизацию

    Ой, прошу прощения... написал совсем не то, что нужно... конечно же межпроцессную (межпоточную) синхронизацию.

    50 minutes ago, k155la3 said:

    Разбираясь с синхронизацией, атомарностью "наразвес" своими силами, Вы рискуете изобрести велосипед в виде mutex-а или семафора.

    Да, конечно, я знаю про них и использую их. Вопрос был про доступ к простой однобайтной переменной. Спасибо.

    14 minutes ago, Plain said:

    Логичен ещё один процесс арбитра записи, и к/от каждого участника очереди — две пары флагов и буферная переменная.

    А это для чего?

    1 hour ago, rkit said:

    В любой ос есть критические секции, которые не могут быть прерваны.

    Если сомневаешься, то пользуйся.

    Да, конечно, я использую их, спасибо.

  11. 44 minutes ago, mantech said:

    И как вы себе это представляете? Аппаратных механизмов доступа к общей памяти нет и у гораздо более мощных процессоров, программно, через порт и прерывания с использованием механизмов синхронизации при обновлении можно.

    Я не про можно, а про нужно :)
    Правильно ли я понимаю, что доступ к 8-битным переменным всегда атомарен? Ну, т. е., ситуации, при которых один процесс пишет в переменную и его прерывает другой процесс, чтобы записать или прочитать (и наоборот), не приведут к проблемам?
    Если переменная более 8 бит (или какая-либо сложная структура), то между записью/чтением ее байтов могут вклиниться другие подобные операции и тут точно могут быть проблемы...

    24 minutes ago, jcxz said:

    А что - уже многоядерные AVR появились???  :scratch_one-s_head:

    Я про доступ к переменной в памяти из разных процессов ОС, допустим scmRTOS.
    В рамках этой ОС потоки называются процессами. Это непринципиально.

  12. Всем привет.

    Объясните, пожалуйста, нужно ли обеспечивать межпроцессорную синхронизацию для доуступа к переменным простых типов (8 бит, bool) на AVR с использованием scmRTOS и др. ОС?
    Имеется несколько читающих и пишущих процессов в эту переменную.

  13. Здравствуйте!

     

    Объясните, пожалуйста, логику работы команды при работе с каталогами:

    svn cp svn://server/testrepo/branches/br1/ svn://server/testrepo/trunk

     

    Если trunk существует, то в него будет скопирован каталог br1.

    Если trunk не существует, то он будет создан и в него будет скопировано содержимое каталога br1.

    Почему так? Может, есть еще какие особенности?

     

    Смысл вот в чем. Вели разработку в branches/br1/. Потом решили скопировать в чистый созданный ранее trunk для дальнейших ветвлений из trunk и мержа. Ожидали, что будет скопировано содержимое каталога br1, а скопировля в trunk весь каталог br1, теперь имеем структуру trunk/br1/файлы, а нужно trunk/файлы.

     

  14. Могу ошибаться, но наверное сложно придумать больший изврат чем пытаться прикручивать топор к альтиуму- что касается озвученной задачи, то не нужен никакой альтиум: берите сразу доску с ножом и режьте любые фигуры как нравится :laughing: . Для того что изображено на рисунке(с учетом описания) даже спринтлэйаута будет много.

     

    То, что я изобразил выше - просто для примера. Реальная плата существенно сложнее и больше!

    Сделал схему, разместил компоненты оптимальным образом. Вот если бы Альтиум как Топор смог преобразовать дорожки в полигоны, то было бы замечательно...

  15. Автору нужно

     

    Вашу экзотику чтобы сделать таким сложную форму вырезов нужно обладать ювелирным инструментом

     

    Да, да, именно так, их есть у меня :)

    Микростамесочка.

    Спасибо!

     

    Для маленьких однослойных плат иногда проще не использовать сложные САПР. А для этой задачи можно воспользоваться совместимым с Альтиумом сторонним трассировщиком TopoR. Причем хватит бесплатной лайт-версии.

     

    Так это ж надо новый САПР изучать... но за идею спасибо :)

     

    После автоматического преобразования проводников в полигоны:

     

    Да, да, такое как раз и надо! :)

  16. Всем привет!

    Хотелось бы по-быстрому и по-простому трассировать элементарные односторонние платы содержащие несколько элементов типа приведенной ниже (нарисовал от балды, чтобы суть была понятна).

    s_1499924190_2603049_e921864667.jpg

    На сегодняшний момент для широких прямоугольных дорожек использую полигоны вручную.

    Но есть ли способ как выполнить такую трассировку быстрее и проще? В автоматическом режиме?

    Цель - трассировать плату так, чтобы дорожки было удобно сформировать процарапыванием/прорезанием.

  17. А зачем интерфейс, если надо просто передать импульсы. Может просто по оптрону с резистором на каждой приемной стороне и запиткой от передающей стороны, своего рода подобие токовой петли.

     

    Можно и так, да, спасибо.

    Как я понимаю, помехоустойчивость системы будет определяться кабелем и током в линии? Какой ток выбрать?

     

    Без гальваники можно делать только в случае, если гарантировано, что система сначала собирается, а затем все питатели втыкаются в розетки. В любом другом случае - развязка обязательна.

     

    Вы имеете в виду, что в моем случае может быть большая разность между потенциалами земель?

  18. Всем привет!

     

    Подскажите, пожалуйста, как лучше организовать передачу пачки импульсов (не более 100 Гц) на расстояние нескольких десятков метров.

    Топология следующая: звезда, в середине 1 передатчик (генератор пачки), на концах 8 приемников (потребителей пачки), передатчик передает данные каждому из приемников отдельно.

    Длина луча звезды может достигать 30 м.

    Все устройства имеют индивидуальные источники питания. Фаза питающая, скорее всего, общая (но не факт).

    Склоняюсь к выбору интерфейса RS-422, но пока не пойму, нужна ли гальваническая развязка.

    Если гальваническая развязка нужна, чтобы развязать полностью все устройства друг от друга, то выходит дороговато (8 шт. изолированных DC-DC).

  19. Спасибо всем большое за советы! :)

    Немного доработал конструкцию, из имеющихся источников пробовал 18 В 3 А (54 Вт) - балласт работает нормально.

    Ради интереса распилил сгоревший транзистор, кристалл поврежден в области эмиттера, проводник отгорел.

  20. у прокладки сопротивление в лучшем случае 1 градус на ватт

    Почему? ХиХ говорит 0.2-0.4 гр./Вт. У меня получилось около 0.2. Похоже. Площадь вычислил не очень точно, да и с толщиной, может, не совсем угадал. Ну не на порядок же разница?! Если где ошибка в расчете - прошу указать.

    Я вообще пытаюсь понять насколько адекватны подобного рода тепловые расчеты, следует ли ими пользоваться впринципе...

     

    итого 2.4 градуса на ватт

    вы вдули в транзистор 100Вт

    кристалл стал горячее радиатора на 100*2,4 = 240 градусов, а тот был ещё и комнатной температуры, итого все 260

    Итого около 1.6 гр./Вт, при мощности 96 Вт кристал стал горячее радиатора на (1.4 + 0.2) * 96 = 154 гр. При комнатной температуре радиатора, температура кристалла - 179 гр.

    Это нормально. Другой вопрос а был ли радиатор комнатной температуры? Нет... он был теплее. Да и, как писали выше, дело, скорее всего в том, что выделяющееся на кристалле тепло просто не успело отвестись...

     

    Правильно ли я понимаю, что при указанных мною величинах в первом посте (8 А и 12 В) по графикам максимальных режимов (картинки, конечно, ужасного качества) транзистор находится уже в области вторичного пробоя или даже хуже?

     

    А я добавлю. Если делать гирлянду, то к ней можно добавить и резисторы-печки, да хоть из нихрома мотать. И тогда надо будет только добавить схему управления, самую простую аналоговую.

    Вы имеете в виду переключать самодельные сопротивления из нихрома (ну или покупные) или галетником или релюхами?

     

    А поскольку у резисторов можно иметь высокую температуру, то и суммарные габариты станут меньше...

    Ну да... радиатор с вентилятором не нужны ;)

     

    Номиналы резисторов - либо 8421, либо R-2R, надо посмотреть разные варианты...

    По "8421" ищутся старые гибриды. Что Вы имели в виду?

     

    82 Вт выделения на один транзистор - это не промышленное решение.

    Я не в серию, а для себя :) Но чувствую, что надежность при таком способе - низка.

    В документации максимальная величина рассеиваемой мощности 125 Вт и приведен график максимальных режимов.

    Как правильно воспользоваться графиком максимальных режимов?

    Как я понял, для данного транзистора величины 20 А и 6 В (120 Вт) лежат в безопасной области.

    Т. е., впринципе транзистор будет работоспособен, но главная проблема при этом - отвод тепла и тут уже нужен тепловой расчет (допустим, мой, приведенный выше), который покажет в какую сторону двигаться?

  21. Да, нормальным.

    Плёночные распространены с десятков пикофарад. Хороший выбор ещё на единицы - сотни пФ - слюдяные.

     

    Слюдяные еще не устарели? Как я понимаю, достаточно габаритный, дорогой и редкий товар? :)

  22. Читаю про конденсаторы. Как я понял, конденсаторам с диэлектриком NPO не присущ микрофонный эффект (ну или очень слабо выражен)?

    Не нашел пленочные конденсаторы на емкости единицы пФ для установки параллельно резистору ОС для ограничения полосы.

    Да и в активный фильтр на пару сотен пФ тоже не нашел...

    Нормальным ли выбором будут конденсаторы NPO?

×
×
  • Создать...