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

Проблемы с наладкой FreeRTOS


Кот с ружьём

Рекомендуемые сообщения

@Кот с ружьём не обращай сильно внимания. Этот человек живет для того чтобы какой то железяке было хорошо. А на самом деле это она должна быть для того, чтобы тебе было хорошо Чтобы задачи решались легко и быстро. И срать я хотел на то, сколько ресурсов она на это потратит. Хоть все. Иначе нахрен она такая мощная нужна? Чтобы я сдох за клавишами вылизывая каждый байт? Но фанатикам таких как мы не понять к сожалению

Только что, BARS_ сказал:

Можно начать с того же easyelectronics

а я там вообще зарегистрирован?

Нужно делать то, что нужно. А то, что не нужно, делать не нужно. (С) Винни Пух

Ссылка на комментарий
Поделиться на другие сайты

Только что, BARS_ сказал:

Очень хреновый подход

Я в шутку это сказал. Что касается спора про FreeRTOS, то я считаю, что стоит отталкиваться от предпочтений. Тебе, @BARS_ , Вижу нравится кодить с минимумом скачанных библиотек и других упрощений, но с максимальным спектром возможностей. @mail_robot  наоборот, предпочитает упростить написание кода, в некоторых случаях жертвуя возможностями. Я же предпочитаю золотую середину .

Ссылка на комментарий
Поделиться на другие сайты

11 минут назад, Кот с ружьём сказал:

в некоторых случаях жертвуя возможностями

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

Товарищ виш вон, пошел видать меня в интырнетах искать. Интересно, найдет? Надо ж с себя как то репутацию звиздуна смывать :crazy:

Изменено пользователем mail_robot

Нужно делать то, что нужно. А то, что не нужно, делать не нужно. (С) Винни Пух

Ссылка на комментарий
Поделиться на другие сайты

Сравнительное тестирование аккумуляторов EVE Energy и Samsung типоразмера 18650

Инженеры КОМПЭЛ провели сравнительное тестирование аккумуляторов EVE и Samsung популярного для бытовых и индустриальных применений типоразмера 18650. 

Для теста были выбраны аккумуляторы литий-никельмарганцевой системы: по два образца одного наименования каждого производителя – и протестированы на двух значениях тока разряда: 0,5 А и 2,5 А. Испытания проводились в нормальных условиях на электронной нагрузке EBD-USB от ZKEtech, а зарядка осуществлялась от лабораторного источника питания в режиме CC+CV в соответствии с рекомендациями в даташите на определенную модель. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. 

Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств. Подробнее параметры и результаты тестов новой серии PLM по ссылке.

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

Только что, mail_robot сказал:

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

А чего ж ты тогда STM32 используешь? Ставь везде сразу компы и не ипи мозг. Ну мощное, ну дорогое, да и хрен с ним! Зато можно наговнокодить тонну кода, 2/3 из которого никогда не будут использоваться и все. А не работает как надо? Да тоже хрен с ним, напилишь десяток костылей и заработает, как надо! Ты же не программист, а дворник, или сантехник, или еще кто, зачем тебе уметь с железом работать. А потом такие, как ты ляпают софт на тот же андроид. Чего там париться с оптимизацией, будет тормозить, так еще ядер и оперативки добавят. Сколько их там уже? 8? Ну так все 8 и заюзаем, а то интерфейс лагать будет. А теперь сравни это все дело с эпл, когда даже на старых и слабых девайсах все работает быстро и без лагов. А почему? Да потому, что их разрабы могут вылизать код. У тебя ровно такая же ситуация. Сразу видно, не писал ты ничего серьезного.

 

6 минут назад, mail_robot сказал:

Но фанатикам таких как мы не понять к сожалению

Я смотрю, у тебя любой, кто умнее тебя, фАнатик (крыс ты безграмотный).

 

Только что, Кот с ружьём сказал:

нравится кодить с минимумом скачанных библиотек и других упрощений

Вся проблема в том, что ни SPL ни HAL ничего не упрощают. На настройку периферии уходит ровно столько же времени, что и без них, вот только в проекте появляются горы кода, написанного ногами из которого 99% вообще не используется, а тупо занимается проверкой - а не дибил ли программер и правильно ли он выставляет вот этот бит. Это же бред. Плюс теряется всякая возможность проверить настройки по даташиту, ибо регистров ты не видишь. А вот кроме, как для настройки МК эти либы практически не используются. Вот и смысл тащить в код простыни кода и для простейших действий производить вызов десяток функций? Ладно бы они реальную пользу приносили, а так вообще непонятно, на кой их написали.

 

6 минут назад, Кот с ружьём сказал:

FreeRTOS, то я считаю, что стоит отталкиваться от предпочтений

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

Ссылка на комментарий
Поделиться на другие сайты

Литиевые батарейки и аккумуляторы от мирового лидера  EVE в Компэл

Компания Компэл, официальный дистрибьютор EVE Energy, бренда №1 по производству химических источников тока (ХИТ) в мире, предлагает продукцию EVE как со склада, так и под заказ. Компания EVE широко известна в странах Европы, Америки и Юго-Восточной Азии уже более 20 лет. Недавно EVE была объявлена поставщиком новых аккумуляторных элементов круглого формата для электрических моделей «нового класса» компании BMW.

Продукция EVE предназначена для самого широкого спектра применений – от бытового до промышленного. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

@Кот с ружьём не слушай никого и никогда (и меня тоже). Вникай во все инструменты и пользуйся ими в нужный момент

Нужно делать то, что нужно. А то, что не нужно, делать не нужно. (С) Винни Пух

Ссылка на комментарий
Поделиться на другие сайты

@BARS_ ну дык чо, где мой говнокод на форумах то? звиздунишко

Нужно делать то, что нужно. А то, что не нужно, делать не нужно. (С) Винни Пух

Ссылка на комментарий
Поделиться на другие сайты

Только что, BARS_ сказал:

Если проект простейший, типа помигать/попищать/повключать/отобразить на дисплее/попинать интерфейсы, то ртос нам нафиг не уперлась.

Если проект простейший, то ты прав. НО, я с FreeRTOS начал знакомиться вчера, поэтому, для упрощения обучения пишу банально игры с лампочками. Ты ведь тоже с этого начинал, верно? Не сразу же программы для материнок писал?

1 минуту назад, mail_robot сказал:

Вникай во все инструменты и пользуйся ими в нужный момент

Справедливо.

Ссылка на комментарий
Поделиться на другие сайты

Только что, mail_robot сказал:

на форумах то?

Это все, на чем сошелся твой ограниченный мозг, мыша?

 

Только что, Кот с ружьём сказал:

Ты ведь тоже с этого начинал, верно?

Я еще с AVR начинал. Наверно поэтому спокойно пишу без всяких левых либ. Плюс когда устроился на работу, у них в ходу были C8051 МК. Пришлось и на них писать. Потом, к счастью, перешли на СТМ.

Ссылка на комментарий
Поделиться на другие сайты

К слову, зачем мне многопоточность. Есть у меня проект, который требует засекания времени в микросекундах, за которые пройдет определенное количество импульсов на высокой частоте. Счет работает беспрерывно. Параллельно идет обработка полученного результата, и в соответствии с еще несколькими входными данными генерируем ШИМ-модуляцию. @BARS_ , какого твое мнение, нужна ли здесь многопоточность (или как ты сказал Псевдомногопоточность). Если да, то как её максимально просто и качественно реализовать, так как при ошибке могут возникнуть большие проблемы?

Ссылка на комментарий
Поделиться на другие сайты

Двигателем рулить будет? По поводу счета, считать можно таймером вообще в фоне. Ставим на таймер работу от внешнего клока и в счетном регистре у него будет набираться количество пришедших импульсов. Счет идет полностью железно и к работе программы вообще не привязан. А дальше просто выдергивай из регистра значение и все. Только обнулять его не забывай после этого. ШИМ тоже железный, значит вся его генерация - просто запись данных в регистр CCR. На РТОС тут ничего особо и не скинешь. Кстати, на хабре видел статьи, там на STM32 делали полумостовой и мостовой ПН. Никаких ртосов не пользовали.

Или требуется именно засечь, за какое время прошло, к примеру, 100 импульсов, а не подсчитать импульсы за отрезок времени?

Ссылка на комментарий
Поделиться на другие сайты

4 минуты назад, BARS_ сказал:

именно засечь, за какое время прошло, к примеру, 100 импульсов

 

4 минуты назад, BARS_ сказал:

Двигателем рулить будет

Да не просто двигателем, а двигателем внутреннего сгорания

Изменено пользователем Кот с ружьём
Ссылка на комментарий
Поделиться на другие сайты

12 минут назад, Кот с ружьём сказал:

Да не просто двигателем, а двигателем внутреннего сгорания

ваще ни единой быстрой задачи на нем нет. Но и операционка там точно не пригодится никаким боком

Нужно делать то, что нужно. А то, что не нужно, делать не нужно. (С) Винни Пух

Ссылка на комментарий
Поделиться на другие сайты

РТОС если у вас есть свободное ОЗУ ничего плохого не привносит в программу. 4 - 8 задач не отнимут очень много ОЗУ. Зато у вас будут отдельные процессы и можно в любое время переходить от одного к другому и это гораздо удобнее конечного автомата. Я вот читал эту ветку и не пойму да есть задержка по обработке событий в РТОС (приняли например пакет по юарту), ну так в конечном автомате вы тоже не быстро его можете обработать мало ли на каком этапе вы там в автомате правильно. А вот в РТОС можно спокойно из прерывания выйти совсем в другую задачу (та что обработает пакет, а потом вернется в прерванную задачу) и прервать текущую это решать вам. Так что РТОС быстрее обработает пакет с учетом что вы так сделаете руками, ну или диспетчер уже переключит с учетом приоритета. 

И я видел как пишут на РТОС типа все задачи крутятся в while да так что вы тупо тратите процессорное время. Внутри задачи можно и нужно реализовывать тот же автомат сделали проход нет событий отдали свободное время другой задаче и переключились на нее, ну или по алгоритму пнули данные по ДМА и вышли из задачи. 

Единственная большая проблема работа с общими ресурсами если они есть. (хотя она точно такая же как использование общих ресурсов в прерывании и основной программе эффект один и тот же)

на одну задачу без локальных переменных минимум уйдет 128 байт + данные задачи 64 байта. Есть конечно свои сложности и заморочки с РТОС, но таки оно удобно даже в плане перетягивания библиотек (в виде задач) из проекта в проект, а не ломать весь автомат (да как там с приоритетами в автомате их же нет).  

Изменено пользователем MasterElectric
Ссылка на комментарий
Поделиться на другие сайты

6 часов назад, Кот с ружьём сказал:

именно засечь, за какое время прошло, к примеру, 100 импульсов

Не сильно сложнее и снова большая часть работы пойдет аппаратно. Точно так же запустить таймер на внешнем клоке. Только включить прерывание по совпадению и настроить его на требуемое количество импульсов. Далее включить второй таймер на счет с некоторым интервалом, в зависимости от требуемого разрешения временных засечек. В каждом прерывании по совпадению выдергивать значение из CNT регистра второго таймера с последующим обнулением. Это и будет искомое время. Главное выбрать интервал так, чтобы при максимальном времени регистр не переполнялся. Опять же, большая часть задачи выполнится аппаратно. А расчеты выполняются быстро. Как пример. У меня в самопальном УНЧ на дисплей выводится анализатор спектра. Для этого постоянно крутится два канала АЦП и собирают выборки в массив через DMA. Каждые 18 мкс накапливается 1024 выборки и отдаются в расчет. Пока идет расчет накапливаются следующие 1024 выборки. Раз в 1мс полученные отсчеты выводятся в виде 64 уровней на цветной дисплей. 320х240 точек. Тактовая у проца всего 72МГц и FPU нет. При этом все успевает работать. Это не считаю остальных задач, типа мониторинга защит, энкодера и т.п. Никакого ртоса там нет. У тебя же задача вообще простейшая, и как уже сказал @mail_robot ртосу тут делать нечего.

 

28 минут назад, MasterElectric сказал:

4 - 8 задач не отнимут очень много ОЗУ. Зато у вас будут отдельные процессы и можно в любое время переходить от одного к другому и это гораздо удобнее конечного автомата

Для такого мизерного количества задач ртос нафиг не нужна. Тем более из них 100% не больше половины будут теми, которые крутятся постоянно, типа опроса устройств по SPI и т.п.. Остальное будет опросом кнопок, выводом чего-то куда-то и т.п., и вызываться они будут раз в 10-100 мс.

 

31 минуту назад, MasterElectric сказал:

А вот в РТОС можно спокойно из прерывания выйти совсем в другую задачу (та что обработает пакет, а потом вернется в прерванную задачу) и прервать текущую это решать вам.

Это можно сделать в любом случае, прерывание имеет приоритет над while и даже если while вообще повис, прерывания будут работать.

 

32 минуты назад, MasterElectric сказал:

ну или диспетчер уже переключит с учетом приоритета. 

Всегда при написании кода учитывается приоритет задач. Иначе какое-нибудь мигание диодом будет главнее чего-то действительно важного. К примеру, у меня есть блок, который по RS485 опрашивает еще 7 блоков, сливая с каждого 100 с лишним байт данных и хранит в памяти в виде таблиц. Кроме этого есть два ЛВС интерфейса по 8 сокетов в каждом. Подключены по SPI. По обоим может идти как запрос данных с текущего блока, так и запрос таблиц данных из памяти. Причем подключены могут быть и десяток клиентов. Кроме того, помимо запроса данных клиенты могут слать команды управления в блоки, подключенные по RS485. Остальные задачи, типа включения реле или опроса кнопок в расчет не берем из-за их простоты. И ничего, без ртос прекрасно и быстро все пашет. В простое идет опрос 7 блоков раз в 500 мс и проверка наличия данных в буфере чипов ЛВС. Если же что-то прилетело по ЛВС - идет чтение и разбор пакета. В случае чтения параметров - просто отсылается требуемое их количество. Если же это команда управления на один из 7 блоков, то ждем, пока закончится текущий прием данных, т.к. RS полудуплекс, затем тормозим опрос и пробрасываем команду. Если ответ пришел, перенаправляем в ЛВС и продолжаем опрос, не пришел - шлем по ЛВС код ошибки. ВСЕ, и никаких РТОС. Просто при написании ПО надо четко представлять, КАК оно должно работать.

 

На самом деле раскидать задачи по приоритетам не так уж и сложно. Лично для меня куда большей проблемой является написание GUI при работе с дисплеями. Ибо это дофигищща кода, где учесть надо очень многое. И вот если бы ртос упрощал эту задачу хотя бы до уровня создания GUI на ПК было бы очень здорово.

Ссылка на комментарий
Поделиться на другие сайты

17 часов назад, Кот с ружьём сказал:

нужна ли здесь многопоточность

не нужна здесь многопоточность! Здесь надо абсолютно точно распределить вычисления-обработку данных-событий в периоды между этими событиями, так чтобы эти события не мешали обработке!

Многопоточность используется когда никакой точности распределения вычислений во времени не нужно поддерживать, то есть событие произошло, а когда оно обработалось (5 мс позже/раньше) и как эта обработка накладывается на последующие события особо не важно!

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

Можно сделать все! Но чем больше можно, тем больше нельзя!

Ссылка на комментарий
Поделиться на другие сайты

21 час назад, BARS_ сказал:
22 часа назад, MasterElectric сказал:

А вот в РТОС можно спокойно из прерывания выйти совсем в другую задачу (та что обработает пакет, а потом вернется в прерванную задачу) и прервать текущую это решать вам.

Это можно сделать в любом случае, прерывание имеет приоритет над while и даже если while вообще повис, прерывания будут работать.

При чем тут прерывание имеет приоритет над while? Предположим вам надо мигнуть сто раз в цикле в вашем алгоритме светодиодом (любая задача с низким приоритетом). Вот вы приняли пакет по юарту и узнали об этом в прерывании, что вы делаете? вы установили флаг о том что пришел пакет и вышли из прерывания и вы вышли в процедуру мигания светодиодом сто раз, потому как вы не знаете в какой момент времени вы получите пакет, а обработка пакета выше по приоритету чем мигание диодом. Вот вам пример отсутствия у конечного автомата системы приоритетов. А как можно работать при РТОС я уже писал выше. Я лично готов платить по 150 тактов на переключение но получить в итоге более структурированную программу разбитую на модули чем один огромный while. Ну нет там приоритетов вы просто по кругу перебираете условия, а внутри условия перебираете еще условия и т.д.

Ссылка на комментарий
Поделиться на другие сайты

13 часов назад, MasterElectric сказал:

вы установили флаг о том что пришел пакет и вышли из прерывания и вы вышли в процедуру мигания светодиодом сто раз

Во-первых. Я могу обработать пакет прямо в прерывании ибо UART мне скажет что получен именно пакет, а не один его байт. А кинуть структуру на отправку через DMA - дело очень быстрое. Наполняется же структура в фоне. Во-вторых, даже если я ставлю флаг, то почему я должен ждать окончания мигания диодом? В промежутках, пока он горит или погашен можно заниматься чем угодно. Да и мигать куда удобнее из таймера, а не while. Завел таймер с низким приоритетом прерывания и хоть замигайся. Всем по барабану, мигнул он через 500мс или через 505мс. В общем пример абсолютно бредовый и в жизни не встречающийся.

 

13 часов назад, MasterElectric сказал:

отсутствия у конечного автомата системы приоритетов.

А на конечном автомате мир клином сошелся? Почитайте внимательно то, что выше писал про мои программы.

 

13 часов назад, MasterElectric сказал:

Ну нет там приоритетов вы просто по кругу перебираете условия, а внутри условия перебираете еще условия

Если вы их не делаете, это не значит, что их нет. Что мешает сделать? Это же не ПК, где выполняется куча сложных процессов. Это МК, где все задачи - простые функции типа послать что-то по интерфейсу/посчитать/пошевелить ножкой/посмотреть, что на ножке. ВСЕ, он ничего больше не умеет. Куда там целый ртос лепить? Ну и по поводу перебора условий, планировщик задач работает ровно так же, просто перебирает условия.

Ссылка на комментарий
Поделиться на другие сайты

не хочешь, не лепи. Никто не заставляет. А кому нравится ртос использует. И с ее применением многие задачи вообще меняют свою привычную форму. Например опрос клавиатуры. Там где раньше приходилось городить огород с дебунсингом и контроль двойных/длительных нажатий с ртос все становится намного проще. Структура программы становится более четкой и очень просто масштабируемой. Обслуживание меню и интерфейсов упрощается. Да много чего становится другим. Дааалеко не всегда нужна прям экстримальная производительность с расчетом каждого такта. А вот задач чисто утилитарного характера, связанных с совсем не быстрой обработкой данных просто тьма. Почему бы не экономить свое время, используя готовый диспетчер? Тем более что там все просто, как угол дома.

Да и на счет скорости обработки данных я бы сильно поспорил. Операционка никуда не девает ни ДМА, ни аппаратные блоки ни прерывания от них. Так же точно они и работают. Если я применяю каскадирование блоков и тем же таймером дергаю АЦП а от него ДМА, то каким боком операционка у меня будет жрать производительность? А уж про такую сверхскоростную задачу как UART я вообще молчу. Ну и если случилось что-то требующее немедленного внимания, то разве прерывание сработает медленнее чем обычно? И разве код внутри него не отработает точно так же? Да прерывание даже не узнает что рядом еще и какая то ось есть, если конечно там не будет GiveFromISR какой нибудь передачи данных наружу

Похоже барсик очень так себе представляет работу оси применительно к стм

Изменено пользователем mail_robot

Нужно делать то, что нужно. А то, что не нужно, делать не нужно. (С) Винни Пух

Ссылка на комментарий
Поделиться на другие сайты

Опять же, ртос себя оправдывает только на сложных проектах с большим количеством кода, не привязанного по работе к железу, а не как у автора счет импульсов и ШИМ или у @MasterElectric UART и мигание диодом. Я не спорю, что в этом случае ртос будет в выигрыше. Но когда проекты простецкие, то она там нафиг не уперлась...

Ссылка на комментарий
Поделиться на другие сайты

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

Изменено пользователем mail_robot

Нужно делать то, что нужно. А то, что не нужно, делать не нужно. (С) Винни Пух

Ссылка на комментарий
Поделиться на другие сайты

20 часов назад, MasterElectric сказал:

но получить в итоге более структурированную программу разбитую на модули чем один огромный while.

Не вижу связи. Огромный while - это результат кривых рук, а не отсутствия РТОС.

В качественном коде while состоит из списка задач - тупо стоящих одна за другой основных функций кода. И все.

При этом совершенно не факт, что этот список будет исполнятся весь, а паче в том порядке, в котором он стоит.

РТОС никак не решает проблему структурирования. Насрать, извините, можно и на художественный паркет.

26.08.2020 в 14:30, mail_robot сказал:

 И срать я хотел на то, сколько ресурсов она на это потратит. Хоть все.

А вот это реальная проблема. Когда человек плюет на производительность, производительность плюет на человека. Это я к тому, что такого рода код оказывается не масштабируемым и затем следует детский лепет погромиста - ставьте более мощный МК. Однако ему болезному невдомек, что более мощный мало того, что мощнее стОит, так ведь к тому же он  ДРУГОЙ. С другой логистикой, с другой топологией и много чего "с другой".

Красиво - это когда одно и тоже железо может быть "флексибл".... Когда подходишь к человеку с новой вводной, а он за пару часов решает задачу, а не жалуется на то, что надо было раньше думать...

戦う前に相手のベルトの色に注目

Ссылка на комментарий
Поделиться на другие сайты

13 часов назад, my504 сказал:

логистикой

не воспринимаю критику от людей, не владеющих русским языком

Нужно делать то, что нужно. А то, что не нужно, делать не нужно. (С) Винни Пух

Ссылка на комментарий
Поделиться на другие сайты

7 часов назад, mail_robot сказал:

не воспринимаю критику от людей, не владеющих русским языком

ЭТА ПЯТЬ!!! :crazy:

Человек не владеющий русским языком не воспринимает критику... 

Милейший, логистика - это организация СНАБЖЕНИЯ (управление материальными потоками). Замена МК, прежде всего, приводит к сложностям в поставках для серийного производства...

Так кто тут безграмотен, пейсатель вы наш?

Изменено пользователем my504

戦う前に相手のベルトの色に注目

Ссылка на комментарий
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.
Примечание: Ваш пост будет проверен модератором, прежде чем станет видимым.

Гость
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Ответить в этой теме...

×   Вставлено с форматированием.   Восстановить форматирование

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

Загрузка...
  • Последние посетители   0 пользователей онлайн

    • Ни одного зарегистрированного пользователя не просматривает данную страницу

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