|
STM32F4, DMA GPIO event, нельзя начать транзакцию по событию от GPIO? |
|
|
|
Sep 10 2014, 13:17
|
Знающий
   
Группа: Свой
Сообщений: 688
Регистрация: 4-09-09
Пользователь №: 52 195

|
Цитата(adnega @ Sep 10 2014, 17:00)  А вы могли бы озвучить задачу полностью? Зачем DMA? Почему не прерывание по EXTI? С какой частотой планируются запросы? Какими данными будут оперировать DMA (кто источник, кто приемник данных)? есть внешний АЦП. передает данные по SPI. О готовности данных сообщает отрицательным фронтом на ноге. На OMAP-L138 такое решается на раз (есть GPIO event mode) Последовательность работы должна быть такая: 1)каждые 10мкс приходит отрицательный фронт на ногу 2) с приходом каждого фронта один канал DMA пишет в SPI_TX несколько байт 3) другой канал DMA натсроен на событие от SPI_RX и принимает столько данных сколько отправили в SPI_TX. В SPI_TX отправляются dummy данные, так как это нужно лишь для приёма данных от SPI_TX
|
|
|
|
|
Sep 10 2014, 15:26
|
Знающий
   
Группа: Свой
Сообщений: 688
Регистрация: 4-09-09
Пользователь №: 52 195

|
Цитата(adnega @ Sep 10 2014, 17:42)  Можно сделать через прерывание EXTI для ноги, на которую приходит сигнал готовности. В обработчике прерывания настраивать два канала DMA для SPI_TX и SPI_RX.
Можно попробовать сделать и полностью аппаратное решение на таймере. Сколько байт нужно принимать каждые 10мкс? 16 байт Сейчас подумал: 1) пришло прерывание, нужно забрать 16 байт 2) для этого нужно эти 16 байт отправить Вопрос: как DMA отправляет данные в SPI_TX, если нужно ещё какое-то время чтобы данные отправились. Т.е. как DMA получит уведомление что байт ушёл и можно копировать следующий байт (и так 16 раз) ? или вопрос надуманный, и это делается автоматически...?
|
|
|
|
|
Sep 12 2014, 02:52
|
Гуру
     
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713

|
Цитата(TigerSHARC @ Sep 10 2014, 21:26)  Сейчас подумал: 1) пришло прерывание, нужно забрать 16 байт 2) для этого нужно эти 16 байт отправить Вопрос: как DMA отправляет данные в SPI_TX, если нужно ещё какое-то время чтобы данные отправились. Т.е. как DMA получит уведомление что байт ушёл и можно копировать следующий байт (и так 16 раз) ? или вопрос надуманный, и это делается автоматически...? Так как в STM32 в каналах SPI нет буферизации, то одним DMA здесь не обойтись. Можно сделать примерно так: Таймер1 получает внешний сигнал, пинает DMA-канал1, который конфигурит другой таймер2, который в свою очередь начинает выдавать события (16 штук) на пересылки DMA-канал2->SPI, последним блоком (в STM32 есть DMA-передачи свЯзным списком типа L137/L138 или NXP LPC17xx?) DMA-канал2 конфигурит таймер2 (выключает его). Всю эту кухню можно сделать работающей в пинг-понг (без перепрограммирования CPU на каждый цикл). Если в DMA STM32 нет возможности передач связным списком, то функцию выключения таймера2 можно также возложить на таймер1+DMA-канал1 (в таймере1 делаем два события по совпадению: одно - сразу после старта, второе - через определённый промежуток времени, достаточный для генерации таймером2 16 событий). Если-бы в SPI STM32 было FIFO на 16*8бит, то можно было-бы обойтись одним DMA и таймером - сразу загонять в FIFO 16*8бит, а уже он, с установленной частотой выдавал бы их наружу. Опять-же - на LPC17xx такое возможно (там есть требуемый объём FIFO) и на L137/L138 думаю тоже.
|
|
|
|
|
Sep 12 2014, 10:29
|
Знающий
   
Группа: Свой
Сообщений: 688
Регистрация: 4-09-09
Пользователь №: 52 195

|
Цитата(jcxz @ Sep 12 2014, 06:52)  Так как в STM32 в каналах SPI нет буферизации, то одним DMA здесь не обойтись. Можно сделать примерно так: Таймер1 получает внешний сигнал, пинает DMA-канал1, который конфигурит другой таймер2, который в свою очередь начинает выдавать события (16 штук) на пересылки DMA-канал2->SPI, последним блоком (в STM32 есть DMA-передачи свЯзным списком типа L137/L138 или NXP LPC17xx?) DMA-канал2 конфигурит таймер2 (выключает его). Всю эту кухню можно сделать работающей в пинг-понг (без перепрограммирования CPU на каждый цикл). Если в DMA STM32 нет возможности передач связным списком, то функцию выключения таймера2 можно также возложить на таймер1+DMA-канал1 (в таймере1 делаем два события по совпадению: одно - сразу после старта, второе - через определённый промежуток времени, достаточный для генерации таймером2 16 событий).
Если-бы в SPI STM32 было FIFO на 16*8бит, то можно было-бы обойтись одним DMA и таймером - сразу загонять в FIFO 16*8бит, а уже он, с установленной частотой выдавал бы их наружу. Опять-же - на LPC17xx такое возможно (там есть требуемый объём FIFO) и на L137/L138 думаю тоже. это конечно тот ещё винигрет Цитата(adnega @ Sep 12 2014, 14:11)  +1. Что-то ТС пропал, видимо, уже все сделал) ТС тут. старт реализации задумки намечен не ранее чем через 2 недели. пока курю даташит... Цитата(AHTOXA @ Sep 12 2014, 14:09)  Не болтайте ерундой, всё прекрасно делается только на DMA. Один канал на передачу, второй на приём. наверное, в моём случае, не только на DMA, но и на одном таймере, так как "DMA GPIO event" нет.
|
|
|
|
|
Sep 12 2014, 11:09
|
Гуру
     
Группа: Свой
Сообщений: 2 724
Регистрация: 14-05-07
Из: Ярославль, Россия
Пользователь №: 27 702

|
Цитата(TigerSHARC @ Sep 12 2014, 14:29)  ТС тут. старт реализации задумки намечен не ранее чем через 2 недели. пока курю даташит... Я бы предложил так: 1. Настраиваем один DMA на передачу 16 байт по событиям от SPI_TX. 2. Настраиваем другой DMA на прием N*2*16 байт по событиям от SPI_RX в кольцевой буфер с генерацией прерываний при заполнении и полузапонении. 3. Настраиваем таймер на одиночный запуск по спаду на ноге. 4. Первый канал совпадения таймера настраиваем на запись через еще один канал DMA числа 16 для NDTR первого DMA (M2M). 5. Второй канал совпадения таймера настраиваем на запись через еще один канал DMA управляющего слова (регистр CR) для первого DMA для запуска передачи (M2M). 6. Разрешаем таймер. 7. Имеем каждые N срабатываний готовности одно прерывание с данными в кольцевом буфере. Пока шаманим с этими данными, заполняется вторая часть кольцевого буфера - никто не потеряется.
|
|
|
|
|
Sep 12 2014, 11:35
|
Знающий
   
Группа: Свой
Сообщений: 688
Регистрация: 4-09-09
Пользователь №: 52 195

|
Цитата(AHTOXA @ Sep 12 2014, 15:28)  А я б не парился, и сделал запуск DMA-обмена с SPI в прерывании от EXTI. Хотя в качестве разминки для мозгов такие комбинации наверное полезны, да  Это как в прерывании дёргать пин чтобы меандр нужной частоты получить без прерывваний экономичнее получается (в плане расхода процессорного времени).
|
|
|
|
|
Sep 12 2014, 13:30
|
Гуру
     
Группа: Свой
Сообщений: 4 256
Регистрация: 17-02-06
Пользователь №: 14 454

|
В LPC ДМА следит как за флагом готовности данных если оно читает их, так и за флагом готовности передатчика если передает. Задаете куда и сколько байт заслать, запускаете процесс, наслаждаитесь.
Не думаю что в STM настолько тупо сделано, что ДМА будет просто тупой писалкой из адреса в адрес. Наверняка там можно выбрать что будет приемником адрес или периферия, а если так, то оно должно само справиться с этой задаче.
Потому с вероятностью 90% (или я буду еще хуже думать об СТМ) задача решается запуском ДМА записи и чтения, я бы запускал по прерыванию, но можно ножкой запустить таймер, а от таймера запустить ДМА, но какая то это долбанная матрешка....
|
|
|
|
|
Sep 12 2014, 13:36
|
Гуру
     
Группа: Свой
Сообщений: 2 724
Регистрация: 14-05-07
Из: Ярославль, Россия
Пользователь №: 27 702

|
Цитата 1) можно ли решить задачу используя два DMA и один таймер? Можно с использованием EXTI. Т.е. прерывание по каждому сигналу готовности. Цитата 2) не понятно как именно осуществляется транзакция нескольких байт последовательно в SPI_TX через DMA. Я понимаю так: как только DMA получает сигнал о готовности данных (от таймера или от флага, установленного в обработчике прерывания GPIO) то, в соответствии с настройками, DMA отправляет последовательно 16-байт в SPI_TX. Не понятно как именно DMA узнает что байт улетел наружу и можно кидать следующий байт в SPI_TX. если ниак, то получается что DMA тупо перезапишет регистр 16-раз. О готовности данных он узнает по запросам на DMA-транзакцию. Например, SPI_TX. Не от таймера или флага GPIO, а именно от SPI_TX. Однако, ничто не мешает копировать в SPI_DR по запросам от таймера или GPIO, но в этом случае программист должен гарантировать, что не будет перезаписи, а ранее записанные данные уже обработаны. Вопрос в том, как заставить таймер сказать DMA, что можно начинать передавать данные в SPI_DR по запросам от SPI_TX?
|
|
|
|
|
Sep 12 2014, 14:06
|
Знающий
   
Группа: Свой
Сообщений: 688
Регистрация: 4-09-09
Пользователь №: 52 195

|
Цитата(adnega @ Sep 12 2014, 17:36)  О готовности данных он узнает по запросам на DMA-транзакцию. Например, SPI_TX. Не от таймера или флага GPIO, а именно от SPI_TX. запрос на транзакцию от SPI_TX для DMA может быть только по готовности данных в SPI_TX. Т.е. появился байт в SPI_TX - возникает событие для DMA. У меня два DMA: один передает "тупые" данные, другой принимает валидные. Так вот первый должен как-то узнать о том что отправлять надо не сразу 16 байт один за другим, а только когда один отправился - -отправлять другой, при этом запрос на транзакцию он принимает от флага GPIO(или таймера). Вы предлагаете третий DMA завести, который будет принимать запрос от SPI_TX? но как это поможет первому DMA узнать когда нужно отправить слудующий байт из 16ти... не понимаю логику...  P.S. или существует механизм(наличие флага?), позволяющий определить что SPI_TX пуст?
|
|
|
|
|
Sep 12 2014, 14:42
|
Гуру
     
Группа: Свой
Сообщений: 2 724
Регистрация: 14-05-07
Из: Ярославль, Россия
Пользователь №: 27 702

|
Цитата(TigerSHARC @ Sep 12 2014, 18:06)  запрос на транзакцию от SPI_TX для DMA может быть только по готовности данных в SPI_TX. Т.е. появился байт в SPI_TX - возникает событие для DMA. У меня два DMA: один передает "тупые" данные, другой принимает валидные. Так вот первый должен как-то узнать о том что отправлять надо не сразу 16 байт один за другим, а только когда один отправился - -отправлять другой, при этом запрос на транзакцию он принимает от флага GPIO(или таймера). Вы предлагаете третий DMA завести, который будет принимать запрос от SPI_TX? но как это поможет первому DMA узнать когда нужно отправить слудующий байт из 16ти... не понимаю логику...  P.S. или существует механизм(наличие флага?), позволяющий определить что SPI_TX пуст? Допустим мы используем SPI1. SPI1_TX можно найти на канале 3 в DMA2_Stream3, SPI1_RX можно найти на канале 3 в DMA2_Stream2. Настраиваем DMA2_Stream3 на копирование данных из памяти, в которой лежит 0xFF, в SPI1->DR. Длина 16 транзакций. Настраиваем DMA2_Stream2 на копирование данных из SPI1->DR в буфер приема. Длина 16 транзакций. Устанавливаем в SPI1 TXDMAEN и RXDMAEN. В SPI будет отправлено 16 раз 0xFF и принято 16 байт в буфер приема.
|
|
|
|
|
Sep 12 2014, 16:34
|

фанат дивана
     
Группа: Свой
Сообщений: 3 387
Регистрация: 9-08-07
Из: Уфа
Пользователь №: 29 684

|
Цитата(TigerSHARC @ Sep 12 2014, 17:35)  Это как в прерывании дёргать пин чтобы меандр нужной частоты получить без прерывваний экономичнее получается (в плане расхода процессорного времени). Ну, не преувеличивайте  Основной-то обмен всё же будет по DMA. Насчёт расхода процессорного времени я бы не был так уверен. DMA тоже выполняется процессором. И, боюсь, что 2(или даже 3 - ещё возможно надо будет записывать TXDMAEN в SPI_CR2) дополнительных канала DMA могут нагрузить процессор больше, чем ма-а-аленькая процедурка прерывания с тремя командами внутри. Ещё одно соображение: каналов DMA не так уж много, и это может быть более ценный ресурс, чем процессорное время.
--------------------
Если бы я знал, что такое электричество...
|
|
|
|
|
Sep 12 2014, 19:46
|
Гуру
     
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713

|
Цитата(AHTOXA @ Sep 12 2014, 22:34)  Насчёт расхода процессорного времени я бы не был так уверен. DMA тоже выполняется процессором. И, боюсь, что 2(или даже 3 - ещё возможно надо будет записывать TXDMAEN в SPI_CR2) дополнительных канала DMA могут нагрузить процессор больше, Вот это открытие так открытие! Кто-ж знал-то??? Я-то по скудости ума всегда думал, что DMA - это такой периферийный узел, главное назначение которого - разгрузить CPU от тупого перетаскивания байтов по шине. А значит - это совершенно разные узлы. Ан нет, он оказывается тоже какая-то часть CPU... левая задняя нога наверное.. Цитата(AHTOXA @ Sep 12 2014, 22:34)  чем ма-а-аленькая процедурка прерывания с тремя командами внутри. Маленькая процедурка с сохранением контекста на входе и выходе в ISR, десятком команд, с выборкой их из памяти (заполнение как минимум 2-3 prefetch-буферов по 128/256бит каждый), +несколько обращений по шине для чтения/записи данных, и опять заполнение prefetch-буферов командами после возврата из ISR. И Вы утверждаете, что это быстрее чем заранее настроенному каналу DMA активироваться и сделать 2-3 пересылки по шине для записи управляющих регистров таймера или другого канала DMA для запуска пакета из 16 операций обмена с SPI??? Ню-ню.... Цитата(AHTOXA @ Sep 12 2014, 22:34)  Ещё одно соображение: каналов DMA не так уж много, и это может быть более ценный ресурс, чем процессорное время. Это уже разработчику решать - что ему важнее: потратить несколько DMA-каналов или по всему коду программы вводить жёсткие ограничения на длительность запретов прерываний, понижать приоритеты других ISR (в которых тоже время реакции может оказаться критичным). Если речь идёт о периоде событий порядка 10 мкс (и это только период стартовых импульсов, а время реакции на них значит ещё в разы меньше), то требования к времени реакции на прерывание (если делать по прерыванию) весьма жёсткие. При таких требованиях имхо надо всё делать максимально без-процессорно, всё свалив на DMA. Для того он и нужен. А более медленную периферию можно и программно обслужить, если каналов DMA не хватит. PS: Кстати - ТС указал период стартовых событий (10мкс), но забыл указать более важное - максимальное время реакции на стартовый импульс. Оно будет зависеть ещё от частоты SPI и необходимого запаса времени между последней SPI-пересылкой и новым импульсом.
|
|
|
|
|
Sep 12 2014, 20:14
|
Гуру
     
Группа: Свой
Сообщений: 2 724
Регистрация: 14-05-07
Из: Ярославль, Россия
Пользователь №: 27 702

|
Цитата(jcxz @ Sep 12 2014, 23:46)  Вот это открытие так открытие! Кто-ж знал-то??? Я-то по скудости ума всегда думал, что DMA - это такой периферийный узел, главное назначение которого - разгрузить CPU от тупого перетаскивания байтов по шине. А значит - это совершенно разные узлы. Ан нет, он оказывается тоже какая-то часть CPU... левая задняя нога наверное..  Я бы предостерег от категоричных высказываний) 1. DMA и CPU разделяют общие шины. 2. Инициализация DMA тоже занимает ресурс CPU. 3. Пересылка крошечными блоками не эффективна. 4. DMA транзакция может выполняться с задержкой, считая от момента возникновения запроса (больше 12 тактов). DMA хорош только на больших объемах данных, не привязанных строго к тактам.
|
|
|
|
|
Sep 13 2014, 06:35
|

фанат дивана
     
Группа: Свой
Сообщений: 3 387
Регистрация: 9-08-07
Из: Уфа
Пользователь №: 29 684

|
Цитата(jcxz @ Sep 13 2014, 01:46)  Вот это открытие так открытие! Кто-ж знал-то??? Я вас чем-то обидел? Что вы всё пытаетесь на меня нападать, уличить в чём-то? Может быть вас задела фраза "не болтайте ерундой"? Так фраза-то была по делу. Если вы не в теме, то зачем лезть со своими глупостями? Причём так уверенно, безапелляционно. Вы же так не помогаете топикстартеру, а наоборот, мешаете. Вот и сейчас: вы, похоже, нервничали, и опять понаписали кучу глупостей. Не надо так всё близко к сердцу принимать, это же всего лишь буковки в интернете. Я вам не враг, я здесь с той же целью, что и вы - пытаюсь делиться знаниями, заодно узнаю что-то и сам. Поэтому давайте общаться спокойно, дружески. По теме: попробуйте загрузить процессор непрерывной DMA-пересылкой и прогоните какой-нибудь бенчмарк. Потом сравните результаты с результатами этого же бенчмарка, но без DMA.
--------------------
Если бы я знал, что такое электричество...
|
|
|
|
|
Sep 13 2014, 08:24
|
Гуру
     
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713

|
Цитата(adnega @ Sep 13 2014, 02:14)  1. DMA и CPU разделяют общие шины. И что? USB тоже использует внутреннюю шину (да и прочая периферия), это тоже CPU? Функционирование DMA (после инициализации) и выполнение команд CPU - совершенно разные и асинхронные вещи. То что они разделяют общий ресурс к делу не относится. Откройте reference manual или user manual или как там и найдите что такое Core Cortex-M3/M4 и что такое DMA/GPDMA/uDMA или как там в конкретном МК. Везде одинаково. Цитата(adnega @ Sep 13 2014, 02:14)  2. Инициализация DMA тоже занимает ресурс CPU. В задаче ТС этот этап делается один раз - при старте ПО (если делать как хочет ТС). Так что - тоже к делу не относится. Цитата(adnega @ Sep 13 2014, 02:14)  3. Пересылка крошечными блоками не эффективна. Пересылка малыми блоками в любом случае неэффективна. Дёрганье в ISR и такая пересылка CPU - ещё менее эффективны чем заранее настроенный DMA в режимах flip-flop, связные списки и т.п. Цитата(adnega @ Sep 13 2014, 02:14)  4. DMA транзакция может выполняться с задержкой, считая от момента возникновения запроса (больше 12 тактов). Как ни странно - вход в ISR тоже выполняется с задержкой + ещё и шину грузит. Цитата(adnega @ Sep 13 2014, 02:14)  DMA хорош только на больших объемах данных, не привязанных строго к тактам. Это можно сказать о любом методе пересылки любым bus master-ом. Это общее свойство. Цитата(AHTOXA @ Sep 13 2014, 12:35)  Если вы не в теме, то зачем лезть со своими глупостями? Причём так уверенно, безапелляционно. Вы же так не помогаете топикстартеру, а наоборот, мешаете. Вот и сейчас: вы, похоже, нервничали, и опять понаписали кучу глупостей. Вы сейчас говорите о себе? Где это я обижался? У Вас ни в одном сообщении ни капли полезной информации. Вам по делу нечего сказать. И не пытался я Вас оскорбить, просто написал, что несёте полную чушь.
|
|
|
|
|
Sep 13 2014, 12:04
|

фанат дивана
     
Группа: Свой
Сообщений: 3 387
Регистрация: 9-08-07
Из: Уфа
Пользователь №: 29 684

|
Цитата(jcxz @ Sep 13 2014, 14:24)  Вы сейчас говорите о себе? Нет, я говорю о вас. Ведь это именно вы, в первом же вашем сообщении в этой теме жидко обделались, показав, что совершенно не разбираетесь в STM32 вообще и его DMA в частности. И после того, как я вам на это указал, вы, вместо того, чтобы сидеть и тихо обсыхать, всё пыжитесь и пыжитесь что-то доказать. Получается, если честно, так себе. Зря вы полезли в тему, в которой не разбираетесь.
--------------------
Если бы я знал, что такое электричество...
|
|
|
|
|
Sep 13 2014, 17:08
|
Гуру
     
Группа: Свой
Сообщений: 4 256
Регистрация: 17-02-06
Пользователь №: 14 454

|
АНТОХА вы иногда резковаты, иногда не по делу. jcxz вы тоже иногда слишком уж напористо заявляете некоторые вещи, которые имеют не одно решение.
Но вы оба судя по другим вашим сообщениям не плохие профессионалы, и я думаю стоит вам прекратить пикироваться.
ДМА действительно грузит шину. А загрузка шины тормозит проц, если она ему нужна и занята он притормаживает. Потому и есть арбитраж шины и приоритеты.
Но с другой стороны 2 обмена по ДМА, в которых идет быстрая запись слова и пауза на его последовательную отправку вряд ли парализуют проц. Также думаю запуск начала обмена в прерывании 1 раз на 16 байт, опять же никакой особой погоды не сделает. Не думаю что пока идет сбор данных проц проигрывает веселые мелодии и кино показывает. Опять же сделать так чтобы проц собирал данные вообще в фоне, тоже красиво. Но надо еще контролировать и когда набрали 1000 посылок, то есть все равно надо прерываться и считать.
Вы предложили несколько нормальных и в глобально одинаковых решений, и почему то сразу перешли на личности и начали кусаться, отстаивая только свое...
Думаю следующий ход должен сделать ТС, сказав нам работает ли ДМА заряженный на отправку 16 байт через SPI как мы все ждем, отправляя байт за байтом или же попихает все сразу и надо что-то мутить. Принимающий ДМА я бы сразу настраивал на прием 16*1000 байт и сразу в общий массив, с прерыванием по сбору всех байт. А порционость данных рулил бы первым ДМА заряжая его на 16 байт, каждый импульс.
|
|
|
|
|
Sep 14 2014, 13:52
|
Гуру
     
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713

|
Цитата(Golikov A. @ Sep 13 2014, 23:08)  jcxz вы тоже иногда слишком уж напористо заявляете некоторые вещи, которые имеют не одно решение. Очень похожую задачу (тоже по приходу импульса надо было считать пачку байт с ПЛИС) я решал. Только на LPC176x. И решил как раз так как описал в первом сообщении. Всё прекрасно работало и это при том, что проц в это время занимался другими (более тяжёлыми) делами. Цитата(Golikov A. @ Sep 13 2014, 23:08)  Но вы оба судя по другим вашим сообщениям не плохие профессионалы, и я думаю стоит вам прекратить пикироваться. Я уже прекратил. Кнопка - "поместить в игнор" очень полезна  Цитата(Golikov A. @ Sep 13 2014, 23:08)  Также думаю запуск начала обмена в прерывании 1 раз на 16 байт, опять же никакой особой погоды не сделает. Не думаю что пока идет сбор данных проц проигрывает веселые мелодии и кино показывает. Как я писал - дело не в том насколько это загрузит CPU, а в том что требование реакции на прерывание в 1-2 мкс, сильно ужесточит требования ко всему остальному коду (где могут быть критические секции с запретом прерывания или другие высокоприоритетные прерывания. Я для себя всегда беру за правило: стараться строить работу системы прерываний так, чтобы она была устойчива к запретам прерывания до неск. десятков мкс (по возможности конечно). К тому-же ТС у нас - из мира DSP, тогда он тем более должен понимать чем вредны высокочастотные прерывания (на DSP с несколькими десятками регистров и конвееризацией вычислений).
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|