The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Проект Raspberry Pi представил плату Pico на основе собственного микроконтроллера, opennews (??), 21-Янв-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


229. "Проект Raspberry Pi представил плату Pico на основе собствен..."  +/–
Сообщение от Аноним (-), 24-Янв-21, 15:03 
> USB 1.1? Это шутка?

Ты посмотри что такое cortex M0 вообще, до того как умничать. Он с 2.0 (Hi-Speed) даже с DMA не справится, скорее всего. Не его масштабы.

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

236. "Проект Raspberry Pi представил плату Pico на основе собствен..."  +/–
Сообщение от n80 (?), 24-Янв-21, 20:55 
> Ты посмотри что такое cortex M0 вообще, до того как умничать. Он
> с 2.0 (Hi-Speed) даже с DMA не справится, скорее всего. Не его масштабы.

Во всяких флешках и переходниках USB-SATA при этом слегка модифицированный 8051 с типичной тактовой частотой в 48 МГц вполне себе справляется, даже с 3.0 (super speed). Не надо путать частоты физического уровня и требуемую производительность контроллера. То что он не может так быстро формировать новые пакеты — вообще не проблема, зато время передачи отдельного пакета (читай, latency от формирования данных до получения их на хосте) будет маленькое. Захлебнётся при записи с хоста в контроллер? Тоже нет, для этого в протоколе NAK предусмотрен, хост просто будет ждать перед записью очередного пакета. Так что ядро контроллера и скорость физического уровня — вещи вообще слабо связанные.

Далее, 2.0 нужен не только и не столько ради скорости, сколько ради увеличенного лимита на размер пересылок, а то дробить всё по 64 байта — такое себе.

Ответить | Правка | Наверх | Cообщить модератору

237. "Проект Raspberry Pi представил плату Pico на основе собствен..."  +/–
Сообщение от n80 (?), 24-Янв-21, 21:04 
Собственно, в даташитах большинства контроллеров нынче пишут USB 2.0, поэтому заявление про 1.1 выглядит очень странно и вызвало столько негодования.

> Though high bandwidth devices are commonly referred to as "USB 2.0" and advertised as "up to 480 Mbit/s," not all USB 2.0 devices are high bandwidth. The USB-IF certifies devices and provides licenses to use special marketing logos for either "basic bandwidth" (low and full) or high bandwidth after passing a compliance test and paying a licensing fee. All devices are tested according to the latest specification, so recently compliant low bandwidth devices are also 2.0 devices.

Ответить | Правка | Наверх | Cообщить модератору

248. "Проект Raspberry Pi представил плату Pico на основе собствен..."  +/–
Сообщение от Аноним (-), 24-Янв-21, 22:15 
Все отличие - шлют версию 2.0 в дескрипторе. А так это full speed обычный, такой же как в 1.1, 12 мегабитов. Это валидно заявлять и как 1.1 и как 2.0. А более скоростной 480МГц есть только в топовых МК способных реально переварить такой поток. И это явно не про cortex M0. Скорее M4F на паре сотен мегагерц какой.
Ответить | Правка | Наверх | Cообщить модератору

260. "Проект Raspberry Pi представил плату Pico на основе собствен..."  +/–
Сообщение от n80 (?), 24-Янв-21, 22:41 
> Все отличие - шлют версию 2.0 в дескрипторе. А так это full speed обычный, такой же как в 1.1, 12 мегабитов.

Ещё, как минимум, в аппаратуре должна быть поддержка таких длинных пересылок, а то будет, например, счёткик у DMA 6-битный и всё.

> А более скоростной 480МГц есть только в топовых МК способных реально переварить такой поток.

Ну вот опять-25. Зачем контроллеру переваривать ровно такой поток? Вот хочу я пересылать 30, 50 или даже 100 МБит/с (а такой поток на железках на STM32 у меня бывает, и совсем не захлёбывается ядро), почему не имею права хотеть делать это по USB? 12 Мбит/с уже не хватит (особенно после вычитания накладных расходов), а какой-нибудь Ethernet имеет бóльшую задержку (особенно с учётом большей вероятности потерь/повреждения пакета, т.е. нужно быть готовым к перепосылкам, которые у USB железно реализованы), да и просто лишние звенья при связи с большой ЭВМ.

> И это явно не про cortex M0. Скорее M4F на паре сотен мегагерц какой.

На банальном STM32F1xx можно подключить USB Hi-Speed PHY через ULPI, ядро при этом M3 на ~100 МГц. Зачем тут M4 (который по сути просто добавляет FPU)? Да и между M0 и M3 разница по производительности всего раза в 2 (а тут ещё и усиленный M0, с аппаратным делением и прочими плюшками).

В общем, ИМХО у сабжа такие странные характеристики сугубо из-за соображений сертификации, а не потому что это такое прям сбалансированное решение.

Ответить | Правка | Наверх | Cообщить модератору

269. "Проект Raspberry Pi представил плату Pico на основе собствен..."  +/–
Сообщение от Аноним (269), 25-Янв-21, 12:40 
> Ещё, как минимум, в аппаратуре должна быть поддержка таких длинных пересылок, а
> то будет, например, счёткик у DMA 6-битный и всё.

Это была бы странная реализация DMA, бессмысленная и беспощадная. Дело в том что сетап транзакции требует возни - возможно вполне сравнимой с передачей 64 байтов вручную. Зачем такой dma надо? Поиздеваться над пользователями фичой которая есть, но бессмысленна?

У STM32F0/1/2/L0/1 например 16 битов под размер транзакции. Влупить до 64К за присест "отсюда сюда" - недурно уже. Тем более что столько памяти только у старших моделей есть. Так что в целом вполне сбалансировано. А желавшие 480Мбит все же идут за чипом пожирнее.

> Ну вот опять-25. Зачем контроллеру переваривать ровно такой поток?

Без этого нет особого смысла в жручем скоростном трансивере и куче ассоциированых с ним проблем и усложненном обвесе.

> Вот хочу я пересылать 30, 50 или даже 100 МБит/с (а такой поток на
> железках на STM32 у меня бывает, и совсем не захлёбывается ядро),
> почему не имею права хотеть делать это по USB?

Потому что система должна быть сбалансированой. И 100 мбит/сек sustained для мелких F0/F1/etc все же перебор. А в более старших и 480Мбит трансиверы есть как раз. А заодно и подсистемы памяти и тактовые частоты более под стать.

> 12 Мбит/с уже не хватит (особенно после вычитания накладных расходов),
> а какой-нибудь Ethernet имеет бóльшую задержку (особенно с учётом большей
> вероятности потерь/повреждения пакета, т.е. нужно быть готовым к перепосылкам,

В usb перепосылки тоже возможны, внезапно. И в целом большой поток данных при слабом ядре и подсистеме памяти на грани - скорее экзотика или специлизированные чипы, типа тех 51 в флешках.

> которые у USB железно реализованы), да и просто лишние звенья при связи с большой ЭВМ.

Это просто нишевая задача, F1xx не сватаются на ТАКОЕ.

> На банальном STM32F1xx можно подключить USB Hi-Speed PHY через ULPI,

Это уж точно совершенно не основное применение F1. А то что кто-то и автомобилем вертолет может сбить не означает что это отличное решение на все случаи.

> ядро при этом M3 на ~100 МГц. Зачем тут M4 (который по сути
> просто добавляет FPU)?

Так там же комплексный подход - тактовые частоты повыше, матрицу шин пожирней, памяти побольше, все такое. Комплексный апгрейд параметров в достаточно логичном допущении что большим задачам - больше ресурсов. В целом, а не 1 конкретном закоулке.

> Да и между M0 и M3 разница по производительности всего раза в 2 (а тут ещё
> и усиленный M0, с аппаратным делением и прочими плюшками).

Как бы M0 с 480 мбитами довольно извратно, если не подперто спецпериферией как тот 51 в флешке.

> В общем, ИМХО у сабжа такие странные характеристики сугубо из-за соображений сертификации,
> а не потому что это такое прям сбалансированное решение.

В смысле - сертификации? Я думаю что они не стали возиться с скоростным трансивером при том что остальное в системе не соответствует по параметрам. Да и ты же не думаешь что нубы на питоне будут такие потоки данных гонять?

Ответить | Правка | Наверх | Cообщить модератору

279. "Проект Raspberry Pi представил плату Pico на основе собствен..."  +/–
Сообщение от n80 (?), 25-Янв-21, 13:45 
> Это была бы странная реализация DMA, бессмысленная и беспощадная. Дело в том
> что сетап транзакции требует возни - возможно вполне сравнимой с передачей
> 64 байтов вручную. Зачем такой dma надо? Поиздеваться над пользователями фичой
> которая есть, но бессмысленна?

Да ладно, настройка транзакции бывает и проще.

> Потому что система должна быть сбалансированой. И 100 мбит/сек sustained для мелких
> F0/F1/etc все же перебор.

Дык, не перебор же. Вот банально у F1: 2 АЦП по 12 бит, 1Msps. Это уже 24 Мбит/с, не считая накладных расходов (и буду я мерять один канал в interleaved режиме на 2Msps или 8 каналов на 250 ksps — уже моё дело), а хочется чем-то ещё успевать заниматься, кроме передачи данных. Ядро и подсистема памяти вообще почти не загружены (DMA же), однако для пересылки на хост уже USB не применить. Впрочем, на STM32F1 ULPI спасает и это действительно сбалансированное решение: внутри только LS/FS трансивер, а более жирный могут ставить те кому надо. Но тут-то не F1, да ещё и строго про 1.1 говорится.

> В usb перепосылки тоже возможны, внезапно.

Отож, просто их необходимость быстрее обнаруживается.

> И в целом большой поток данных при слабом ядре и подсистеме памяти на грани - скорее экзотика или специализированные чипы, типа тех 51 в флешках.

В том-то и претензия, что не такой он и большой.

> Это просто нишевая задача, F1xx не сватаются на ТАКОЕ.

Да ладно, нормальная задача. Он и не для такого подходит. Помнится мне, даже прямо в даташите подобные примеры рассматриваются (типовая конфигурация для даталогера/плеера с флешкой).

> Это уж точно совершенно не основное применение F1. А то что кто-то
> и автомобилем вертолет может сбить не означает что это отличное решение на все случаи.

С распространением bluepill (когда F1 стали пихать куда ни попадя с оверкиллом на пару порядков), положим, и не основное. А так-то более чем нормальное, производитель сам такое предлагает.

> В смысле - сертификации? Я думаю что они не стали возиться с
> скоростным трансивером при том что остальное в системе не соответствует по
> параметрам. Да и ты же не думаешь что нубы на питоне
> будут такие потоки данных гонять?

Про сертификацию (в смысле, лицензирование или как это правильно называется) ниже ответил. Про то что 2.0 даёт не только и не столько HS отвечал выше (т.е. можно FS/LS без встроенного HS, но 2.0). В общем, очень странно увидеть упоминание 1.1, когда (уже цитировал itt, но повторюсь):
> Though high bandwidth devices are commonly referred to as "USB 2.0" and advertised as "up to 480 Mbit/s," not all USB 2.0 devices are high bandwidth. The USB-IF certifies devices and provides licenses to use special marketing logos for either "basic bandwidth" (low and full) or high bandwidth after passing a compliance test and paying a licensing fee. All devices are tested according to the latest specification, so recently compliant low bandwidth devices are also 2.0 devices.

Ответить | Правка | Наверх | Cообщить модератору

295. "Проект Raspberry Pi представил плату Pico на основе собствен..."  +/–
Сообщение от Аноним (-), 26-Янв-21, 10:30 
> Да ладно, настройка транзакции бывает и проще.

DMA в основном большой кус без проца пульнуть интересно. IRQ = сохранение + восстанов + флаги снять + транзакцию перезарядить, время всеж. Толкнуть так 64 байта? Сравнимо по действиям с упомянутым, нет?

> Дык, не перебор же. Вот банально у F1: 2 АЦП по 12 бит, 1Msps. Это уже 24 Мбит/с,
> не считая накладных расходов

1) 2 АЦП не у всех F1. Скажем в F100 1. Правда там и usb нет.
2) Постоянный поток, на комп нужен далеко не всем. И для такого наверное лучше камень покруче, а там и HS как раз.
3) 1MSps - здорово. Но требования к источнику сигнала читануть стоит. И посмотреть сколько из них в требования лезут.

Т.е. теоретически возможно, а практически задача на границе возможного, то что тяжело идет - логично.

> (и буду я мерять один канал в interleaved режиме на 2Msps или
> 8 каналов на 250 ksps — уже моё дело),

А вы даташит читали? Чтобы именно столько, потребуется весь аналог специально под ЭТО затачивать. Либо получите дикое вранье в отсчетах и половину LSB как раз можно выкинуть.

Хинт: перезаряд ADC S&H cap @ 1MHz канал просаживает если поляну не готовили (повторитель на БЫСТРОМ опампе?). Хрень померять можно.

> а хочется чем-то ещё успевать заниматься, кроме передачи данных.

DMA этим и интересен - асинхронен относительно проца. В паре с ADC могут по кольцу крутиться без сетапа == 100% железный кольцевой буфер с IRQ. Это не ардуина :)

> Ядро и подсистема памяти вообще почти не загружены (DMA же),

DMA - bus master, шину делит на двоих с процом. Разве что команды не гоняет. На cortex >=M3 I и D шины раздельные, I может с флеша читать пока D в оперативу лезет, так профита поменьше. А вот M0 с одной шиной, там интереснее.

> однако для пересылки на хост уже USB не применить. Впрочем, на STM32F1 ULPI спасает и это
> действительно сбалансированное решение: внутри только LS/FS трансивер, а более жирный
> могут ставить те кому надо. Но тут-то не F1, да ещё и строго про 1.1 говорится.

Ну это уже навороты. Нужные не всем. При желании из старшего F1 с внешней шиной что угодно можно, но можно != нужно.

> Отож, просто их необходимость быстрее обнаруживается.

Ошибки CRC там не отменяли.

> В том-то и претензия, что не такой он и большой.

480 мбитов - приличный уже. И еще требует 480МГц (!!!) PLL. В разы превосходит остальные частоты в чипе. Возможно требования к техпроцессу повышало? F1 дизайнили ~10 лет назад все же.

> Да ладно, нормальная задача. Он и не для такого подходит.

Да понятно что гуру и автомобилем вертолет собьет, но...

> Помнится мне, даже прямо в даташите подобные примеры рассматриваются (типовая
> конфигурация для даталогера/плеера с флешкой).

Это в каком шите? Из F1xx плеер - "не очень". Там M4F какой-нибудь уместнее, для жирных котов^W аудиокодеков. Или чего им плеить? ADPCM? :)

> С распространением bluepill (когда F1 стали пихать куда ни попадя с оверкиллом
> на пару порядков), положим, и не основное.

Так даже STMicro (а не те паленые клоны) недорого, чуть больше доллара даже околорознично. Клоны, конкуренция и вообще, дорогие чипы девов отпугивают.

> А так-то более чем нормальное, производитель сам такое предлагает.

Да нормальные чипы, спору нет. Но производителю главное продать :) а потом не его проблемы.

> Про сертификацию (в смысле, лицензирование или как это правильно называется) ниже ответил.

А, про формальное обозначение. Так вроде и на 1.х надо же сертифицироваться чтобы usb logo юзать? Это никак не фича usb 2.0, оно и до этого было IIRC.

Ответить | Правка | Наверх | Cообщить модератору

303. "Проект Raspberry Pi представил плату Pico на основе собствен..."  +/–
Сообщение от n80 (?), 26-Янв-21, 12:39 
> DMA в основном большой кус без проца пульнуть интересно. IRQ = сохранение
> + восстанов + флаги снять + транзакцию перезарядить, время всеж. Толкнуть
> так 64 байта? Сравнимо по действиям с упомянутым, нет?

Ну тут накладывается такой момент, что по USB нельзя просто так взять и передавать в любой момент, а только когда хост спрашивает (причём, конкретный endpoint). Поэтому очень удобно заранее положить данные в буфер, настроить DMA для соответствующего EP (указатель + количество) и пусть себе хост когда хочет, тогда и забирает этот буфер, не прерывая работу ядра вообще. Аналогично с записью с хоста, заранее настроил буфер для обмена и дальше только ловить прерывание, что он заполнен и можно другой буфер подставлять. Правда, у меня с USB знакомство больше с колокольни всяких 8051, поэтому довольно специфичный взгляд. На STM32 так получилось, что с Ethernet я разобрался раньше USB (задача была, в которой именно Ethernet нужен), так что до его USB так толком и не добрался.

>> Дык, не перебор же. Вот банально у F1: 2 АЦП по 12 бит, 1Msps. Это уже 24 Мбит/с,
>> не считая накладных расходов
> 1) 2 АЦП не у всех F1. Скажем в F100 1. Правда там и usb нет.

F100 — маркетологический огрызок, физически в F100~F103 один и тот же кристалл и всё там есть, разве что на заводе не тестировалось или не прошло тесты (по словам ST). В общем-то, так все делают, но большинство жадных контор ещё и fuse'ами блокируют или доступными только из системного режима регистрами (см. PSoC4), а ST позволяет на свой страх и риск пользоваться. Причём, брать F100 (как и 101 или 102) уже давно нет никакого смысла: если поначалу он и был дешевле F103, потом за счёт непопулярности он оказался уже даже дороже (цена при штучных поставках сильно выше, чем при больших партиях, в итоге получаются вот такие перекосы). Так что не аргумент.

> 2) Постоянный поток, на комп нужен далеко не всем. И для такого
> наверное лучше камень покруче, а там и HS как раз.

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

> А вы даташит читали? Чтобы именно столько, потребуется весь аналог специально под
> ЭТО затачивать. Либо получите дикое вранье в отсчетах и половину LSB как раз можно выкинуть.
> Хинт: перезаряд ADC S&H cap @ 1MHz канал просаживает если поляну не готовили (повторитель на БЫСТРОМ опампе?). Хрень померять можно.

Я, конечно, тот ещё самоучка с не очень прямыми лапками, но и фильтры, и повторители конечно же есть. Олсо, 1 Msps — это же всего лишь сигналы до 100-200 кГц, очень скромно с т.з. аналоговых цепей. Шум на пару LSB присутствует, конечно, но как-то в моём манямирке получается лучше передать вместе с этими битами и потом эту информацию в обработке учесть (накопление, осреднение, программная фильтрация, вот это вот всё), чем отрезáть заранее.

> DMA - bus master, шину делит на двоих с процом. Разве что команды не гоняет. На cortex >=M3 I и D шины раздельные, I может с флеша читать пока D в оперативу лезет, так профита поменьше. А вот M0 с одной шиной, там интереснее.

В каком смысле «интереснее»? В смысле, что сложнее из-за того что DMA и ядро мешают друг другу ещё сильнее, чем на M3? Ну есть такое, но это опять не в пользу выбора M0.

>> Отож, просто их необходимость быстрее обнаруживается.
> Ошибки CRC там не отменяли.

Это да, но задержка при обнаружении такой ошибки (и последующей перепосылке) куда меньше, чем время реакции TCP/IP на потерянный/битый пакет. Понятно, что так-то можно и не по TCP передавать, и таймауты крутить, но как-то всё-таки USB выглядит удобнее. Ну да ладно, это всё частные случаи.

>> В том-то и претензия, что не такой он и большой.
> 480 мбитов - приличный уже.

Ну вот опять про максимальный, да что ж такое. Я уже говорил, что между 12 и 480 Мбит/с есть ещё много интересных значений и этот провал не особо есть чем заполнить.

> И еще требует 480МГц (!!!) PLL. В разы превосходит остальные частоты в чипе. Возможно требования к техпроцессу повышало? F1 дизайнили ~10 лет назад все же.

Это да, это существенная проблема. Даже глянул по даташиту: только до 148 МГц разрешено выжимать из PLL3 на F1xx.

>> Помнится мне, даже прямо в даташите подобные примеры рассматриваются (типовая конфигурация для даталогера/плеера с флешкой).
> Это в каком шите? Из F1xx плеер - "не очень". Там M4F какой-нибудь уместнее, для жирных котов^W аудиокодеков. Или чего им плеить? ADPCM? :)

Воу-воу, не надо грязи, целочисленных реализаций кодеков (особенно MP3) более чем достаточно в природе. Конечно, на какой-нибудь эквалайзер или эффекты может и не хватить мощности (но это не точно, помню один проект…), но уж просто декодирование там с большим запасом помещается. А уж если заморочиться с фиксированной точкой, вообще ух! И да, как тут не процитировать reference manual на F1xx:
> A single 25 MHz crystal can clock the entire system and all peripherals including the

Ethernet and USB OTG FS peripherals. In order to achieve high-quality audio performance,
an audio crystal can be used. In this case, the I2S master clock can generate all standard
sampling frequencies from 8 kHz to 96 kHz with less than 0.5% accuracy.
For more details about clock configuration for applications requiring Ethernet, USB OTG FS
and/or I²S (audio), please refer to "Appendix A Applicative block diagrams" in your
connectivity line device datasheet.

Но, да, комментарий «но производителю главное продать :) а потом не его проблемы» тут очень уместен.

> А, про формальное обозначение. Так вроде и на 1.х надо же сертифицироваться чтобы usb logo юзать? Это никак не фича usb 2.0, оно и до этого было IIRC.

Да, оно и раньше было. Просто у меня такое ощущение, что для CM0 и USB 1.1 у конторы RPi уже все бумаги были и они очень не хотели тратиться на что-либо новое ради этого проекта.

Ответить | Правка | Наверх | Cообщить модератору

315. "Проект Raspberry Pi представил плату Pico на основе собствен..."  +/–
Сообщение от Аноним (315), 26-Янв-21, 14:49 
> буфер подставлять. Правда, у меня с USB знакомство больше с колокольни
> всяких 8051, поэтому довольно специфичный взгляд.

Я на STM32 к usb пока тоже только прицеливаюсь, сложный гад: ftdi по жизни проще прилепить. Но на F1xx там есть некий выделеный буфер железки под это. Туда можно сложить добро, настроить что-то типа дескрипторов, железка сама по тому описанию будет таскать когда приспичит. Это без всякого DMA. А стеб в том что F1xx зачем-то сделали буфер общим для usb и can. Желающие сколхозить usb2can адаптер дико матерятся на этот фак(т).

> F100 — маркетологический огрызок, физически в F100~F103 один и тот же кристалл
> и всё там есть, разве что на заводе не тестировалось или не прошло тесты (по словам ST).

Именно F100 вроде все же физически другой. То что F101-103 одно и то же я просек. Там даже RAM и флеша одинаково везде вроде. Или вы хотите сказать что я в F100 даже usb найду? А куда он там разведен? Как в F103?

Почему я думаю что F100 другой кристалл? Вышел позже и F100 умеет некоторые вещи которых в F101-103 не было. Например, PLL можно сделать DIV+MUL, от 2 до 16 и синтез частоты там куда более продвинутый. Да, это всего лишь небольшое лишнее поле в одном из регистров, но я очень сомневаюсь F101-103 так обделили бы. А зачем так возможности чипа сливать? (помножить+поделить намного гибче чем только div/2 + mul как в 103).

> В общем-то, так все делают, но большинство жадных контор ещё и fuse'ами блокируют
> или доступными только из системного режима регистрами (см. PSoC4),

В F10x кстати замечено что-то типа фузов (options byte) в sys area. Конечно не документировано. Что бы это могло быть? Защита от записи system mem?  

> а ST позволяет на свой страх и риск пользоваться. Причём, брать F100 (как и 101 или
> 102) уже давно нет никакого смысла:

Конкретно F100 мне попались за копейки и мне был интересен именно тот момент с MUL+DIV для странных экспериментов с синтезом частоты.

> если поначалу он и был дешевле F103, потом за счёт непопулярности он оказался
> уже даже дороже (цена при штучных поставках сильно выше, чем при больших партиях, в
> итоге получаются вот такие перекосы). Так что не аргумент.

См. выше про один из мелких но неприятных недостатков.

> Ну, он на самом-то деле не совсем постоянный, но набегами и их нужно быстро разгребать,

А чего мешает набеги в RAM скидывать? Особенно если монстрик с внешней шиной.

> т.е. растягивать передачу и обработку до начала следующего набега — не вариант.

Это кмк зависит от характера этого паттерна.

> Я, конечно, тот ещё самоучка с не очень прямыми лапками, но и фильтры,
> и повторители конечно же есть.

Не парьтесь, я из таких же :P. Там не в фильтре трабл а в том что adc заряжает свой кондер с частотой МГц, дико сажает сигнал, откуда конское требование к Rin источника сигнала. Не любая штука легко сэмплируется на мегагерц, увы. А толпа опампов с бандвизом несколько мгц тоже так себе.

> Олсо, 1 Msps — это же всего лишь сигналы до 100-200 кГц, очень скромно с т.з. аналоговых цепей.

По найквисту таки до 500.

> Шум на пару LSB присутствует, конечно,

Там и не пару LSB может быть если забыть про R источника.

> но как-то в моём манямирке получается лучше передать вместе с этими битами и потом
> эту информацию в обработке учесть (накопление, осреднение, программная фильтрация, вот
> это вот всё), чем отрезáть заранее.

Я вообще сделал это в IRQ от DMA c 2-буфером. У микрочипа есть дешевое и сердитое усреднение которое им ок даже для пика было.

>> А вот M0 с одной шиной, там интереснее.
> В каком смысле «интереснее»?

Профита от отсутствия команд вызывающих копирование больше. Смысл действа увеличивается. С флешом на I-bus он параллельно работал, профита меньше. Правда в шину DMA все-равно никогда не упрется, он же процу после трансфера цикл оставляет чтобы тот не встрял.

>> Ошибки CRC там не отменяли.
> Это да, но задержка при обнаружении такой ошибки (и последующей перепосылке) куда
> меньше, чем время реакции TCP/IP на потерянный/битый пакет.

Кому оно важно сроду юзают UDP, именно поэтому. Он к тому же сильно проще заодно.

> что между 12 и 480 Мбит/с есть ещё много интересных значений
> и этот провал не особо есть чем заполнить.

В принципе то да. Но все же.

> Это да, это существенная проблема. Даже глянул по даташиту: только до 148
> МГц разрешено выжимать из PLL3 на F1xx.

А кто такое PLL3? В F103 это вообще не заявлено, там формально только 1 PLL. Это чье? И в 103 оно физически есть? :D

> Воу-воу, не надо грязи, целочисленных реализаций кодеков (особенно MP3) более чем достаточно
> в природе. Конечно, на какой-нибудь эквалайзер или эффекты может и не
> хватить мощности (но это не точно, помню один проект…),

А что, хватает на декодирование мп3 в нормальном виде? Так, а урл примеров с таким нельзя? И сколько оно там мгц хотит?

>> A single 25 MHz crystal can clock the entire system and all peripherals including the
> Ethernet and USB OTG FS peripherals.

...и как это к MP3 относится? Это лишь к синтезу частот и ошибкам оных видимо.

> Но, да, комментарий «но производителю главное продать :) а потом не его
> проблемы» тут очень уместен.

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

> и они очень не хотели тратиться на что-либо новое ради этого проекта.

Возможно. В первом пи они ж сэкономили на прямо системном проце, хоть это и идиотство было.

Ответить | Правка | Наверх | Cообщить модератору

317. "Проект Raspberry Pi представил плату Pico на основе собствен..."  +/–
Сообщение от n80 (?), 26-Янв-21, 17:33 
> Я на STM32 к usb пока тоже только прицеливаюсь, сложный гад: ftdi по жизни проще прилепить.

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

> Именно F100 вроде все же физически другой. То что F101-103 одно и то же я просек. Там даже RAM и флеша одинаково везде вроде. Или вы хотите сказать что я в F100 даже usb найду? А куда он там разведен? Как в F103?
> Почему я думаю что F100 другой кристалл? Вышел позже и F100 умеет некоторые вещи которых в F101-103 не было. Например, PLL можно сделать DIV+MUL, от 2 до 16 и синтез частоты там куда более продвинутый. Да, это всего лишь небольшое лишнее поле в одном из регистров, но я очень сомневаюсь F101-103 так обделили бы. А зачем так возможности чипа сливать? (помножить+поделить намного гибче чем только div/2 + mul как в 103).

Ааа, похоже, я осёл, перепутал с F101. Это F101 является «как бы без USB», но на самом деле — F103 после маркетологического урезания. А вот чьим аналогом является F100 — надо посмотреть. С другой стороны, я уже натыкался на пример, когда более поздний чип заменял более ранние, но документацию у ранних не меняли, конечно. Например, продаваемые сейчас STM8S003 на самом деле с большой вероятностью являются STM8S103 или даже STM8S903 (у этого внутренний источник референсного напряжения есть).

DIV+MUL у PLL есть у F105/F107 (107 = 105 + Ethernet), кстати. Возможно, F100 является их урезанной версией, но это надо про него почитать (а в сохранённой документации что-то он у меня ещё не упоминается), спасибо за наводку.

>> В общем-то, так все делают, но большинство жадных контор ещё и fuse'ами блокируют
>> или доступными только из системного режима регистрами (см. PSoC4),
> В F10x кстати замечено что-то типа фузов (options byte) в sys area.
> Конечно не документировано. Что бы это могло быть? Защита от записи system mem?

Сам с полгода назад натыкался на пачку недокументированных фьюзов (характерные пары байт, где второй является инверсией первого), лежащих рядом с документированными. Что они значат — самому любопытно, но исследований пока не находил на эту тему. Вообще, там область, которая записывается в процессе производства (калибровки АЦП, документированный размер флеша и т.д.), есть подозрение, что она вся является флеш-памятью (а не смесью из мелких кусочков flash и OTP) и какие-то из битов защищают её после записи заводских значений. Но это совсем уж догадки.

>> Ну, он на самом-то деле не совсем постоянный, но набегами и их нужно быстро разгребать,
> А чего мешает набеги в RAM скидывать? Особенно если монстрик с внешней шиной.

По всякому можно выкрутиться, это да. Но то что между USB FS и HS из промежуточных вариантов только Ethernet (если не считать извращений, типа (Q)SPI через FTDI) — всё-таки та ещё заноза.

> Там не в фильтре трабл, а в том что adc заряжает свой кондер с частотой МГц, дико сажает сигнал, откуда конское требование к Rin источника сигнала. Не любая штука легко сэмплируется на мегагерц, увы.

Там и ещё одна грабля есть, от которой дико бомбит у некоторых начинающих: если каналов использовать больше одного, заряженный конденсатор ADC может потом разряжаться в следующий канал и устраивать там заметный прыжок (особенно при большой частоте переключения между каналами), ну или ямку, если у предыдущего канала напряжение ниже было. У него, конечно, ёмкость пикофарадами измеряется, но для кого-то это может быть сюрпризом. Причём, на каком-нибудь AVR это тоже было, но там они этого не замечали из-за существенно невысокой частоты переключения и скорости оцифрения.

> А толпа опампов с бандвизом несколько мгц тоже так себе.

К счастью, нынче это довольно доступное удовольствие. Хотя считать и мерять нужно, конечно. Да ещё и при разных температурах, как показал опыт.

>> Олсо, 1 Msps — это же всего лишь сигналы до 100-200 кГц, очень скромно с т.з. аналоговых цепей.
> По найквисту таки до 500.

Там же всё-таки речь идёт про ограничение снизу на частоту дискретизации, да и на входе совсем не синус идеальный. Так что частоту среза у фильтра явно стоит с запасом предусматривать.

> А кто такое PLL3? В F103 это вообще не заявлено, там формально
> только 1 PLL. Это чье? И в 103 оно физически есть?

Connectivity line же, F105/F107. У меня это основная линейка, поэтому только . У 103 и правда всё куда проще, но.

> А что, хватает на декодирование мп3 в нормальном виде? Так, а урл примеров с таким нельзя? И сколько оно там мгц хотит?

Рабочего примера под рукой не нашлось (сам не собирал), так что придётся зайти издалека:
https://github.com/espressif/ESP8266_MP3_DECODER https://github.com/earlephilhower/ESP8266Audio (у 8266 производительность всё-таки так себе, так что почему бы и нет?)
http://keyj.emphy.de/minimp3/ (заброшено слегка и имеет проблемы с точностью) -> https://github.com/lieff/minimp3 (поддерживается, но хочет плавающую точку)
(поискал ещё чуть-чуть)
https://github.com/jiangrunwu/Helix_STM32 -> https://github.com/ultraembedded/libhelix-mp3
Вот это уже выглядит совсем близко, даже на EFM32 запускали: https://www.silabs.com/documents/public/application-notes/an...

>>> A single 25 MHz crystal can clock the entire system and all peripherals including the Ethernet and USB OTG FS peripherals.
> ...и как это к MP3 относится? Это лишь к синтезу частот и ошибкам оных видимо.

Ну там предлагается прикладной пример, где одновременно I²S и USB работает (и даже Ethernet, если надо). С USB вряд ли ADPCM они предлагают слушать, на скоростях FS-то. Но, конечно, лучше открывать оригинал, а не мою копипасту.

> Возможно. В первом пи они ж сэкономили на прямо системном проце, хоть это и идиотство было.

Вот, да, уже второй раз вижу напоминание об этом в этой теме. И ведь правда очень странное решение, да и в следующих ревизиях RPi у них странное было. Так что это уже больше похоже на традицию.

Ответить | Правка | Наверх | Cообщить модератору

325. "Проект Raspberry Pi представил плату Pico на основе собствен..."  +/–
Сообщение от Аноним (-), 27-Янв-21, 19:33 
> FTDI, сволочь такая, дорогой негуманно.

232RL терпимо, и у меня не миллионные тиражи, 1-2 бакса не принципиальны. Но вообще CP210x от силабсов напрашивается попробовать.

> И, что ещё хуже, его клоны совсем не являются полноценной заменой,

Я покупаю у нормальных саплеров, клонопроблемы не е..т. А так я линух юзаю и "ftdi patches" только как 1-апрельская шутка там были.

> да ещё и маскируются под оригинал усиленно.

А налаженные цепочки поставок у фирм - таки работают. Они не стесняются вывесить такие вещи на сайтах, хинт!

> Поэтому приходится смотреть в сторону всякого странного.

Например чего?

>> (помножить+поделить намного гибче чем только div/2 + mul как в 103).
> Ааа, похоже, я осёл, перепутал с F101. Это F101 является «как бы
> без USB», но на самом деле — F103 после маркетологического урезания.

Про это я в курсе. Вот эти и правда вроде 1 чип. Но я имел в виду F100, вышедший немного позже и потому имеющий более продвинутый PLL. На него даташит отдельный.

> А вот чьим аналогом является F100 — надо посмотреть.

ИМХО ничьим, "F10x lite". По таймлайну после 10x - вторым вышел вроде. Соответственно облегчен относительно оных, usb нет, памяти меньше, ADC 1, 24МГц макс (зато все симметрично, без waitstates, 1 глобальный лимит на всё). И вот PLL до кучи попродвинутее 101-103, предделитель поставили нормальный. В 101-103 был только div/2, что намного менее интересно чем 2...16.

> С другой стороны, я уже натыкался на пример, когда более поздний чип заменял
> более ранние, но документацию у ранних не меняли, конечно.

Чипмейкеры чипы собирают, типа конструктора из кубиков. У амд в amdgpu хорошо разрисовано как они это делают, блоки по вериям разложены. Остальные тоже это делают. Просто не все афишируют.

И анализ отличий чипов удобно делать вот в таком контексте. У L1 - GPIOv2, у F1/2 - v1. Ну вот разные железки, одно apb, второе ahb, конфигурация по регистрам разная, у V2 AFIO другой, до 15 функций кроме gpio (поле 4 бита, выбор ремапа).

> Например, продаваемые сейчас STM8S003 на самом деле с большой вероятностью
> являются STM8S103 или даже STM8S903 (у этого внутренний источник референсного
> напряжения есть).

Увы, про STM8 я не в курсе. STM32 я в линухе обычным gcc'ом програмлю. С stm8 так не катит вроде, да и зачем мне 8-битники? Я когда-то атмеги прогал, но все уже забыл, у F10x железо намного круче.

> DIV+MUL у PLL есть у F105/F107 (107 = 105 + Ethernet), кстати.

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

> Возможно, F100 является их урезанной версией, но это надо про него
> почитать (а в сохранённой документации что-то он у меня ещё не упоминается),

У него отдельные DS и TRM. Субъективно F10x-lite. Код может работать на F10*, я на 100 и 103 один блоб гонял, если только 1-й ADC юзать и младшие номера периферии вообще. Есть ли там 2й - а вот хз, не сканил. Могу какой-нибудь характерный паттерн по адресу поискать, если у каких-то регистров дефолт подходящий.

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

Да-да. Еще смущает какой-то непонятный reserved в флешконтроллере, врядли случайность :)

> документированный размер флеша и т.д.), есть подозрение, что она вся является флеш-памятью

100%. Господа снимавшие фузы декодировали структуру даже. И смогли стереть только фузы, экранировав УФ от остального массива бумажкой. Я бы не отказался на свое горе научиться скажем стирать STшный бут в пользу своего :). Не то чтобы сильно мешает, но...

А вообще, вот https://www.aisec.fraunhofer.de/content/dam/aisec/ResearchEx...
https://github.com/JohannesObermaier/f103-analysis

> (а не смесью из мелких кусочков flash и OTP)

Option bytes и flash разные структурно: флеш блочно стирается. Option это не катит, они более гранулярные. Но вот именно "otp" это часть ... наверное все же option. Где они физически см выше, или рядом по ссылкам, у вон тех было.

> и какие-то из битов защищают её после записи заводских значений. Но это
> совсем уж догадки.

Я тоже так думаю что вон те option-bytes типа могут лочить сегмент, например. Или он пишется через вон тот reserved, а магические константы для разлока не сказали.

> и HS из промежуточных вариантов только Ethernet (если не считать извращений,
> типа (Q)SPI через FTDI) — всё-таки та ещё заноза.

Лично мне такие потоки как-то особо не требовалось. Хотя возможно нечто типа usb-осцила сделать и прикольно, но для такого наверное F30x лучше...

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

Я сделал себе сетап каналов с временами сэмплирования и поэкспериментировал с разными. Понял как не бомбит. А потом почитал как adc реально сделан и понял почему так.

> предыдущего канала напряжение ниже было. У него, конечно, ёмкость пикофарадами измеряется,
> но для кого-то это может быть сюрпризом.

Порядка 8 пф. Но если что-то слаботочное, на мегагерц такое меряет...

> Причём, на каком-нибудь AVR это тоже было, но там они этого не замечали из-за существенно
> невысокой частоты переключения и скорости оцифрения.

И битов меньше. А так у STM'а прикольный ADC, отдельные LSB хорошо видно, если не идиотничать.

> К счастью, нынче это довольно доступное удовольствие. Хотя считать и мерять нужно,
> конечно. Да ещё и при разных температурах, как показал опыт.

Ну просто это и поле для грабель и плата разлапистей, и дороже. Иногда проще подкостылить/притормозить.

> и на входе совсем не синус идеальный. Так что частоту среза
> у фильтра явно стоит с запасом предусматривать.

Ну, там смотря что надо. Меня обычно реакция волновала. А какая форма - не сильно интересно.

> Connectivity line же, F105/F107. У меня это основная линейка, поэтому только .
> У 103 и правда всё куда проще, но.

А я в основном 100..103, еще L1 для lowpower сенсоров, но это относительно фоново. Немного и с другими пересекался.

> Рабочего примера под рукой не нашлось (сам не собирал),

Эх, стремные монстрики. В последних вижу флоаты и *alloc. Первому вроде *alloc таки оборвали и даже вроде integer only, интереснее уже. Но все равно здоровый, гад. Мне то плеер не надо, скорее прикидываю катит ли так системные анонсы/мсг пожать.

> так что придётся зайти издалека:

Спасибо.

> Ну там предлагается прикладной пример, где одновременно I²S и USB работает (и
> даже Ethernet, если надо). С USB вряд ли ADPCM они предлагают слушать, на скоростях FS-то.

44100 * 2 = 88.2 кило в секунду (1 канал CD-quality). Ну пусть 2 (stereo), менее полутора мегабитов. Вроде не проблема при 12 у FS? Они точно что-то декодили?

> Но, конечно, лучше открывать оригинал, а не мою копипасту.

А они там сорц прошивок дают? А то вон на солнечный инвертер с странным преобразователем - "contact nearest sales department". Блин, троллфэйс какой, сорц на апнот настолько зажать.

> Вот, да, уже второй раз вижу напоминание об этом в этой теме.
> И ведь правда очень странное решение,

Я так понял что в 1й версии они реюзнули чип для DVD плееров, те стали малопопулярны, а тут вот такой sink для лежака придумали. Это объясняет почему ARM до кучи, а videocore - их все :)

> да и в следующих ревизиях RPi у них странное было. Так что это уже больше похоже
> на традицию.

А в новых видимо уже "для совместимости" и "зачем сильно переделывать?". Но под напором конкурентов нормальный ARM все же поставили.

Ответить | Правка | Наверх | Cообщить модератору

326. "Проект Raspberry Pi представил плату Pico на основе собствен..."  +/–
Сообщение от n80 (?), 28-Янв-21, 07:52 
> 232RL терпимо, и у меня не миллионные тиражи, 1-2 бакса не принципиальны.

Ну, разница уже на сотенных тиражах ощутима. А ещё жаба душит банально: FT232RL ~ $3, STM32F072 ~ $2, STM32F042 ~ $1. Отдавать 3 бакса (впрочем, мне почему-то запомнилась ещё более высокая цена, давно не следил) за железку с такой ограниченной функциональностью — ну не поднимается рука как-то, хоть и должно обилие готовых библиотек как-то вразумлять.

> Но вообще CP210x от силабсов напрашивается попробовать.

Да, эти в своё время очень понравились, хоть универсальности ещё меньше FT232, кмк.

> Я покупаю у нормальных саплеров, клонопроблемы не е..т.
> А так я линух юзаю и "ftdi patches" только как 1-апрельская шутка там были.

Я тоже, внезапно, на нём. Хотя не всегда это можно сказать про заказчиков.
Но так-то тут опасения не столько из-за драйверов, сколько из-за лагов и разъезжающихся таймингов, если нарваться на программный клон на базе какого-нибудь МК.

> А налаженные цепочки поставок у фирм - таки работают. Они не стесняются вывесить такие вещи на сайтах, хинт!

Да можно, всё можно. Но как-то в итоге так я и прошёл мимо FTDI.

>> Поэтому приходится смотреть в сторону всякого странного.
> Например чего?

Тут идёт моё сплошное ИМХО (и я не просто так говорю слово «странное»). Если нужен чисто UART, однозначно CH340 (впрочем, у него ноги слабо тянут, так что если нужен UART с значительно более мощными выходными драйверами, CP210x спасёт, а ещё у силабсов есть большой плюс в плане наличия в отечественных магазинах, ну и почему-то их подделывают мало). Если неспешно дрыгать ногами с быстрым накидыванием прототипного софта, CH341. Если GPIO у CH341 не хватило, да и хочется странного и более оперативно ногами дрыгать, CH55x (но это прошивку писать придётся). Если же возможностей CH55x не хватило, пора браться за STM32F042, F072 или F103 (или ещё кого пожирнее). Где-то когда-то мимо пробегали Cypress FX2 (и его близкие родичи), но тоже недёшево, но всё равно прикольные они, особенно FX3.

Из ультра-бюджетного с USB есть ещё контроллеры STC8H8KxxU, они дороже CH55x, но у них и периферия интереснее. Но читать их даташиты и писать по ним код как-то очень утомительно, так что я это просто как вариант для странного будущего в заметки внёс. Кстати, в свежих ревизиях самых дешёвых контроллеров STC (STC8G1K08 и STC8H1K08) есть заливка прошивки по USB. Т.е. вдуматься только: по USB можно залить прошивку, но периферии такой у контроллера нет, т.е. в своём коде использовать USB на них нельзя. Я сначала думал, что эти извращенцы в бутлоадере реализовали VUSB на 8051 1T и не хотят ни с кем делиться реализацией, но сейчас склоняюсь к тому, что там просто кристалл STC8H8KxxU и программное обрезание функциональности (впрочем, как приедут STC8G1K08A, надо будет попробовать потыкаться по адресам периферии, может и не залочено даже).

> ИМХО ничьим, "F10x lite". По таймлайну после 10x - вторым вышел вроде.
> Соответственно облегчен относительно оных, usb нет, памяти меньше, ADC 1, 24МГц
> макс (зато все симметрично, без waitstates, 1 глобальный лимит на всё).
> И вот PLL до кучи попродвинутее 101-103, предделитель поставили нормальный. В
> 101-103 был только div/2, что намного менее интересно чем 2...16.

Ну вот такой делитель очень уж напоминает F1xx CL (connectivity line, F105/F107).
Возможно, он был их предшественником. Возможно, последователем. Но это надо мануалы сравнивать, конечно, до чего я ещё не добрался.

> Чипмейкеры чипы собирают, типа конструктора из кубиков. У амд в amdgpu хорошо разрисовано как они это делают, блоки по версиям разложены. Остальные тоже это делают. Просто не все афишируют.

Да, это понятно, особенно если был опыт разработки на HDL. Но вот тут не афишируют и приходится догадываться, реверсить.

> Увы, про STM8 я не в курсе. STM32 я в линухе обычным gcc'ом програмлю. С stm8 так не катит вроде, да и зачем мне 8-битники? Я когда-то атмеги прогал, но все уже забыл, у F10x железо намного круче.

Ну, attiny/atmega — кошмар и ужас (совершенно нелепое по нынешним меркам железо по космическим ценам), но когда-то было очень плохо с альтернативами, это я понимаю, но сейчас о них речи не идёт. Что же до STM8, я очень долго считал их совсем бесполезными (особенно с учётом отсутствия поддержки в GCC, что очень больно). Но потом выяснилось несколько нюансов:
1. Они работают в широком диапазоне напряжений. От 3 до 5.5 без внешнего преобразователя — аргумент существенный (да, проект с питанием от 18650 и очень ограниченным пространством, нужно было вписаться в существующий корпус).
2. Они бывают даже в SO-8, что тоже полезно в условиях ограниченного пространства.
3. Хотя шина данных там 8 бит, но архитектура местами вполне 16-битная (почему-то big endian), ну и вообще довольно прикольная.
4. Когда в более старом проекте понадобился расширенный диапазон температур, самым дешёвым вариантом оказался STM8AFxxxx (A — automotive, звучит обнадёживающе). Правда, тогда я в STM8 ещё не умел, так что сказал «НЕТ» и делали в итоге на несколько более дорогом STM32F031F6P7, хоть у него диапазон температур и напряжений послабее, но для соблюдения ТЗ хватило и испытания оно достойно прошло.

> У него отдельные DS и TRM. Субъективно F10x-lite. Код может работать на F10*, я на 100 и 103 один блоб гонял, если только 1-й ADC юзать и младшие номера периферии вообще. Есть ли там 2й - а вот хз, не сканил. Могу какой-нибудь характерный паттерн по адресу поискать, если у каких-то регистров дефолт подходящий.

Да тут и без паттернов, STM всё-таки старается периферию по одним и тем же адресам держать в близких линейках (STC, я смотрю на тебя с большим укором), так что просто взять адрес от F1xx контроллера со вторым ADC, убедиться в том, что у F100 по этому адресу в даташите написано reserved и попробовать поработать с ADC2.

> 100%. Господа снимавшие фузы декодировали структуру даже. И смогли стереть только фузы, экранировав УФ от остального массива бумажкой. Я бы не отказался на свое горе научиться скажем стирать STшный бут в пользу своего :)

Да-да-да, эта возможность прямо очень манит. Правда, бут там всё-таки может оказаться масочным (дороговато всё-таки флеш-память на такое переводить, хотя STM и может такое себе позволить), но это надо смотреть на картинках вскрытых чипов. Хотя, на тех же CH55x бут явно частью флеша является (да и у STC попадался намёк про возможность написания и заливки своего загрузчика) и мне вот прям очень любопытно, как же его туда заливают при производстве (т.к. там, казалось бы, нет JTAG/SWD/SWIM/etc). В даташите CH55x, кстати, есть троллинг насчёт наличия полунедокументированного интерфейса программирования якобы через SPI, многие повелись, но после пристального взгляда становится очевидно, что это пины UART2, работа с которым явно видна в коде штатного бутлоадера (его область можно невозбранно читать, тоже плюсик в карму WCH).

> А вообще, вот https://www.aisec.fraunhofer.de/content/dam/aisec/ResearchEx...
> https://github.com/JohannesObermaier/f103-analysis

Огонь, спасибо!

>> (а не смесью из мелких кусочков flash и OTP)
> Option bytes и flash разные структурно: флеш блочно стирается. Option это не катит, они более гранулярные.

Ну flash (EEPROM) — термин общий и он весьма разный бывает, так что сделать нужный размер страницы (2 байта) для области option можно.

> Лично мне такие потоки как-то особо не требовалось. Хотя возможно нечто типа
> usb-осцила сделать и прикольно, но для такого наверное F30x лучше...

Осциллограф (приёмник отражённых зондирующих импульсов, PLC-модем, etc), логический анализатор (или быстрый ногодрыг на замену FTDI), мостик в систему с ISA (PC/104) или ещё какую не очень медленную и/или широкую шину и т.д. В общем, разные идейки могут возникать.

> Я сделал себе сетап каналов с временами сэмплирования и поэкспериментировал с разными.
> Понял как не бомбит. А потом почитал как adc реально сделан и понял почему так.

Ну я в своё время на статейку с объяснениями наткнулся (ссылку быстро не найду, пожалуй), поэтому удалось почти без блужданий дойти.

>> Причём, на каком-нибудь AVR это тоже было, но там они этого не замечали из-за существенно невысокой частоты переключения и скорости оцифрения.
> И битов меньше. А так у STM'а прикольный ADC, отдельные LSB хорошо видно, если не идиотничать.

Мне просто вспомнилось, как один не очень внимательный персонаж упёрто пытался доказать чатику, что у STM32 АЦП хуже AVR'ного. Такой headdesk (даже не facepalm), просто жуть.

> 44100 * 2 = 88.2 кило в секунду (1 канал CD-quality). Ну пусть 2 (stereo), менее полутора мегабитов. Вроде не проблема при 12 у FS? Они точно что-то декодили?

Хмм, а ведь и правда укладывается. С другой стороны, проекты-то разные всё равно гуглятся.

> А они там сорц прошивок дают?

Конкретно по поводу I²S, USB и Ethernet мне вспоминается только картинка с настройкой тактирования. Демки с таким кодом могло и не быть, но я как-то и не искал.

> А то вон на солнечный инвертер с странным преобразователем - "contact nearest sales department". Блин, троллфэйс какой, сорц на апнот настолько зажать.

Отжигают. Кстати, недавно на аналогичное у Intel наткнулся: https://community.intel.com/t5/Embedded-Intel-Core-Processor...
«I have sent you an e-mail with the isp test application folder to the e-mail address on your account. Intel Atom ISP Test App is free software: and it's under the terms of the GNU General Public License.»

Если оно под GNU GPL, почему нельзя выложить на интеловском git, а нужно каждому отдельно руками на почту слать? Дивные люди. К счастью, кто-то на свой github всё-таки залил.

> Я так понял что в 1й версии они реюзнули чип для DVD плееров, те стали малопопулярны, а тут вот такой sink для лежака придумали. Это объясняет почему ARM до кучи, а videocore - их все :)

Ааа, так вот оно чего. Теперь понятно, откуда там блок MPEG-2 декодера, требующий лицензионного ключа.

Ответить | Правка | К родителю #325 | Наверх | Cообщить модератору

339. "Проект Raspberry Pi представил плату Pico на основе собствен..."  +/–
Сообщение от Аноним (-), 30-Янв-21, 03:40 
> бакса (впрочем, мне почему-то запомнилась ещё более высокая цена, давно не
> следил) за железку с такой ограниченной функциональностью — ну не поднимается
> рука как-то, хоть и должно обилие готовых библиотек как-то вразумлять.

Да я даж не спорю, жаба иногда поддушивает, так что некий пойнт я признаю. С F0 я таки предпочитаю не связываться лишний раз: M0 даже без +, с отсутствующим VTOR меня все же анноит, да и в debian'овском eabit gcc с M0 чудеса бывают, если оптимизацию покруче завернуть.

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

> Да, эти в своё время очень понравились, хоть универсальности ещё меньше FT232, кмк.

Мне от них хватит тупого уарта. А с виндовыми дровами у них грабельно? Мне то похрен, но кастомеры порой маздайку хотят.

>> А так я линух юзаю и "ftdi patches" только как 1-апрельская шутка там были.
> Я тоже, внезапно, на нём. Хотя не всегда это можно сказать про заказчиков.

Ну дык. Поэтому и вопрос см. выше.

> Но так-то тут опасения не столько из-за драйверов, сколько из-за лагов и
> разъезжающихся таймингов, если нарваться на программный клон на базе какого-нибудь МК.

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

> Да можно, всё можно. Но как-то в итоге так я и прошёл мимо FTDI.

Я даже соглашусь что жадная фирма, а с драйвером вообще скотство устроили.

> «странное»). Если нужен чисто UART, однозначно CH340

Увы, не доверяю инженерии чайны. Видел как они usb2rs232 делают, это пц просто, CMOS 5V чип с инвертироваными уровнями 1 на все. Так то в 50% случаев этот "rs232" даже как-то работает. Но не всегда. А чип быстро мрет если ему настоящий 232 попадается, с +/-12V, от этого 5V CMOS довольно быстро кончается.

> выходными драйверами, CP210x спасёт, а ещё у силабсов есть большой плюс
> в плане наличия в отечественных магазинах, ну и почему-то их подделывают мало).

Видимо дешевый и скучный слишком.

> более оперативно ногами дрыгать, CH55x (но это прошивку писать придётся).

Прогать откровенную чайну мне неохота, увы.

> Если же возможностей CH55x не хватило, пора браться за STM32F042, F072 или
> F103 (или ещё кого пожирнее).

Собссно это и есть аргумент для меня освоить usb на нем постепенно :)

> Из ультра-бюджетного с USB есть ещё контроллеры STC8H8KxxU, они дороже CH55x, но
> у них и периферия интереснее.

У меня нет проектов где каждый цент на счету, имхо китайцово - китайцам :)

> как вариант для странного будущего в заметки внёс. Кстати, в свежих
> ревизиях самых дешёвых контроллеров STC (STC8G1K08 и STC8H1K08) есть заливка прошивки по USB.

Говоря за себя - после 32-битного M3 назад в 8-битники просто уже очень неохота =)

> делиться реализацией, но сейчас склоняюсь к тому, что там просто кристалл
> STC8H8KxxU и программное обрезание функциональности (впрочем, как приедут STC8G1K08A,
> надо будет попробовать потыкаться по адресам периферии, может и не залочено даже).

А задампить ром лоадера и изучить не катит? Я правда только для F1 так развлекся, откуда и узнал что там примерно 2048+512 байтов. Если лезть дальше - hardfault прилетает.

> Ну вот такой делитель очень уж напоминает F1xx CL (connectivity line, F105/F107).

Не думаю что это они, слишком фичастые для "F10x lite". У них наверное кристаллы больше и дороже. Хотя с учетом что F101-103 один чип...

> Возможно, он был их предшественником. Возможно, последователем. Но это надо
> мануалы сравнивать, конечно, до чего я ещё не добрался.

"F101-103 lite + prediv к PLL". Под lite подразумевается что-то типа 16КRAM max+128K flash max (физически столько и в младших есть) и меньше железок. Подозреваю что некоторых железок нет еще и просто по причине отсутствия лапок для них.

> Да, это понятно, особенно если был опыт разработки на HDL. Но вот
> тут не афишируют и приходится догадываться, реверсить.

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

> Ну, attiny/atmega — кошмар и ужас (совершенно нелепое по нынешним меркам железо
> по космическим ценам),

Ну да. Я пару партий F10x ухватил сильно дешевле таковых и мне проще эти ставить :)

> 1. Они работают в широком диапазоне напряжений. От 3 до 5.5 без
> внешнего преобразователя — аргумент существенный (да, проект с питанием от 18650
> и очень ограниченным пространством, нужно было вписаться в существующий корпус).

Ну да. Однако я по оказии купил кучу uPower torex XC6xxx в SOT23 за копье, и теперь и F1xx так же могут, а один SOT23 не так уж страшен :)

> 2. Они бывают даже в SO-8, что тоже полезно в условиях ограниченного пространства.

Кстати, STM сделали 32G в таком же корпусе. ИМХО я его возьму если приспичит.

> 3. Хотя шина данных там 8 бит, но архитектура местами вполне 16-битная
> (почему-то big endian), ну и вообще довольно прикольная.

Боюсь без мощи gcc-шного оптимизера это совсем скучно по математике, а я подсел на ряд вещиц.

> диапазон температур и напряжений послабее, но для соблюдения ТЗ хватило и
> испытания оно достойно прошло.

STM32F для automotive бывают, у вас диапазоны круче? Алсо в дш даже на обычные по верхним температурам написано что реально даже больше, если лимитить рассеяние. Или вам в минусы?

> Да тут и без паттернов, STM всё-таки старается периферию по одним и
> тем же адресам держать в близких линейках

Однако GPIOA у L1 и F1 по разным адресам например. Впрочем разные версии железок на разных шинах.

> этому адресу в даташите написано reserved и попробовать поработать с ADC2.

1) RESERVED есть.
2) Я все же попробовал magic, дешево и сердито. И нашел БАГ в TRM!
ADC*_HTR, reset value:
Описание: 0x00000FFF. Таблица: all 0. HW: 0x00000FFF. Баг в таблице.

F103:
ADC1_HTR=00000FFF
ADC2_HTR=00000FFF

F100, тот же бинарь:
ADC1_HTR=00000FFF
ADC2_HTR=00000000 <- увы, но...

> масочным (дороговато всё-таки флеш-память на такое переводить,

Я просто оставлю это здесь...


//Valid for STM32F10x:
//ROM:
    dumpblock((void*)0x1FFFF000, 2048);
//ChipID:
    dumpblock((void*)0x1FFFF7E8, 12);

Вместо 2048 можно 2560 (2048+512). Больше -> hardfault.

> хотя STM и может такое себе позволить), но это надо смотреть на картинках вскрытых чипов.

А уникальный серийник в "mask rom" это как? Там еще калибровки и т.п. бывают. ИМХО пуляют через SWD или JTAG вместе с калибровками и серийником.

> Хотя, на тех же CH55x бут явно частью флеша является

Да и тут вроде бы тоже.

> и у STC попадался намёк про возможность написания и заливки своего загрузчика)

У ST можно сделать начало фирмвари своим бутом, при boot0=0 конечно. Тогда при powerup ремап положит туда флеш, и если начало типа бут - ок. Вроде первые 4К при Level 1 даже readonly делают автоматически. Может быть и sysROM наподобие лочат.

Там именно физически ремап памяти, при boot0=0 флеш в 08000000 и 0. Можно фирмвару с 0 линковать, как нормальный "reset handler". С запуском такой FW из STшного ROM имхо будет облом: он не сможет ее ремапнуть, только ресетом с boot0=0 запустится. В 08 он ее увидит, но если линковано в 0, упс. Я так при кодинге бута обломался, без задней мысли адрес стэка прочел чтобы сам на себя попробовать бутануться. Hardfault! ARM не любит null pointer :). С зеркала в 08 читается конечно.

> штатного бутлоадера (его область можно невозбранно читать, тоже плюсик в карму WCH).

Я у ST слил ROM и даже немного отдизасмил (не полностью).

> Огонь, спасибо!

Там еще рядом 1-2 тематичных доки на том сайте есть.

> Ну flash (EEPROM) — термин общий и он весьма разный бывает, так
> что сделать нужный размер страницы (2 байта) для области option можно.

EEPROM от флеша тем и отличается. Крупноблочный ERASE эффективнее по площади массива. EEPROM с побайтовым доступом меньше и/или дороже. Вот поэтому.

>> usb-осцила сделать и прикольно, но для такого наверное F30x лучше...
> Осциллограф (приёмник отражённых зондирующих импульсов, PLC-модем, etc),

Это чего вы такое в PLC гнать собрались? Так на гитхабе болтается PLC модем, но он прост как топор - гонит 1.8МГц (на радость радиогубителям) PWM модулированный UART, и вылавливает его взад чем-то типа недо-радиоприемника. Я так понимаю что мк унутрях должен все это делать и наружу только данные. Впрочем самой фирвари там нет, только схемы/описание, но идея понятна.

> логический анализатор (или быстрый ногодрыг на замену FTDI),

Собссно ногодрых можно и в фирмвари накодить, куда быстрее и предсказуемее чем командовать им по юсб?

> мостик в систему с ISA (PC/104) или ещё какую не очень медленную и/или широкую шину
> и т.д. В общем, разные идейки могут возникать.

Ох, какая некромансия :)

> Ну я в своё время на статейку с объяснениями наткнулся (ссылку быстро
> не найду, пожалуй), поэтому удалось почти без блужданий дойти.

Я особо не блуждал, доки рулят. А описание ADC - appnote какой-то чтоли. Там разрисован кондер, компараторы SAR и проч.

> Мне просто вспомнилось, как один не очень внимательный персонаж упёрто пытался доказать
> чатику, что у STM32 АЦП хуже AVR'ного.

Чера с два, я им отдельные биты даже с очень странных вещей вижу.

> Хмм, а ведь и правда укладывается. С другой стороны, проекты-то разные всё
> равно гуглятся.

Просто пульнуть raw PCM явно проще чем еще mp3 пытаться попутно декодировать. Так даже крутые звуковухи то обычно не делают, за редким исключением.

> Отжигают. Кстати, недавно на аналогичное у Intel наткнулся:

Ну, интел мне не интересен. А вот что они за странный boost придумали где _две_ катушки и _трансформатор_ на выходе этого, и как они вон тот сигнал своим таймером сделали я бы посмотрел. Впрочем вроде врубился как такой PWM делать. Но теория работы этой штуки остается для меня не полностью прозрачной, впервые вижу такую топологию, boost умудрились в трансформатор загнать, нормальный а не flyback, так что 250 ваттов влезло на раз.

> кто-то на свой github всё-таки залил.
> Ааа, так вот оно чего. Теперь понятно, откуда там блок MPEG-2 декодера,
> требующий лицензионного ключа.

Там еще и VC1 вроде есть. Но я как-то предпочитал другие девайсы. Не нравится мне броадком и boot by GPU

Ответить | Правка | К родителю #326 | Наверх | Cообщить модератору

328. "Проект Raspberry Pi представил плату Pico на основе собствен..."  +/–
Сообщение от n80 (?), 28-Янв-21, 08:49 
Упс, в предыдущем ответе эту часть потерял, так что вторым сообщением дополняю.

> Мне то плеер не надо, скорее прикидываю катит ли так системные анонсы/мсг пожать.

Ну тут я вижу два пути. Во-первых, можно применить более простой кодек, MP3 всё-таки не очень легковесный, да и тут не требуется такое уж качество, получается. Во-вторых, есть всякие микросхемы «аппаратных» MP3-плееров (да и с другими кодеками бывают), сходу находится VS1053, но это точно не самый дешёвый вариант, есть проще.

Ответить | Правка | К родителю #325 | Наверх | Cообщить модератору

335. "Проект Raspberry Pi представил плату Pico на основе собствен..."  +/–
Сообщение от Аноним (335), 29-Янв-21, 20:45 
> Ну тут я вижу два пути. Во-первых, можно применить более простой кодек,

Ну я и применю adpcm имхо. Но при ограниченом флеше его или маловато лезет или надо внешнюю флеху.

> уж качество, получается. Во-вторых, есть всякие микросхемы «аппаратных» MP3-плееров

Да ну их, сложные, дорогие, сравнимы с системным процом, больше фигни на плате и entities в power management. В любом случае спасибо за подборочку.

Ответить | Правка | К родителю #328 | Наверх | Cообщить модератору

247. "Проект Raspberry Pi представил плату Pico на основе собствен..."  +/–
Сообщение от Аноним (-), 24-Янв-21, 22:12 
> Во всяких флешках и переходниках USB-SATA при этом слегка модифицированный 8051 с
> типичной тактовой частотой в 48 МГц вполне себе справляется, даже с
> 3.0 (super speed).

Есть только один мааааааленький нюанс. Он вообще данные не трогает. Там здоровенная кастомная периферия в духе DMA для ворочания этого добра, а 8051 уродец сильно сбоку - вгрузить параметры и отвалить восвояси. Сам по себе этот убогий недомерок вообще ничего из себя не представляет. Приблуда для программирования переросточного DMA автомата, блин.

К тому же - если в системе есть SATA то энергопотребление там уж точно никого не парит, электричества по меркам Cortex M0 там заведомо просто море. А вот ты попробуй SATA от вон той CR2032 запустить? Cortex M0 то заведется. Ну, если с мегагерцами и периферией не борзеть, конечно.

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

Ответить | Правка | К родителю #236 | Наверх | Cообщить модератору

263. "Проект Raspberry Pi представил плату Pico на основе собствен..."  +/–
Сообщение от n80 (?), 24-Янв-21, 22:54 
> Есть только один мааааааленький нюанс. Он вообще данные не трогает. Там здоровенная
> кастомная периферия в духе DMA для ворочания этого добра, а 8051
> уродец сильно сбоку - вгрузить параметры и отвалить восвояси. Сам по
> себе этот убогий недомерок вообще ничего из себя не представляет. Приблуда
> для программирования переросточного DMA автомата, блин.

Во флешках, кстати, точно трогает. Ибо на ком ещё реализовывать трансляцию (обработку переназначений, выравнивание износа и т.д)? Это не отменяет здоровенной приблуды для DMA, но всё же. В переходниках, впрочем, прошивка тоже куда более интересная, чем просто настроить и отвалить.

> К тому же - если в системе есть SATA то энергопотребление там
> уж точно никого не парит, электричества по меркам Cortex M0 там
> заведомо просто море. А вот ты попробуй SATA от вон той
> CR2032 запустить? Cortex M0 то заведется. Ну, если с мегагерцами и
> периферией не борзеть, конечно.

Вот не надо по темам скакать. 8051 был упомянут к тому, что ядро CM0 ну вообще никак не запрещает наличия хотя бы FS USB 2.0 (а не только 1.1), а то и HS.

> Алсо от микроконтроллеров ожидается более гибкое и кастомизируемое поведение нежели приблуда при DMA автомате. Ну и поэтому вот там приходится идти на те или иные компромиссы, для получения в целом сбалансированной системы. Которая и данные на комп немного скинуть может, и батарейку не жрет в три горла, а вот и пачку данных с ADC в вон тот интерфейс DMA контроллером утрамбовывает, пока проц чем-то своим занят...

Про возможности энергосбережения конкретно сабжа ничего пока не могу сказать, но очень слабо верю в его скромный жор, особенно с учётом позиционирования в виде плат с USB и питонопрошивкой из коробки. Да что уж тут, внешняя последовательная флешка (вместо внутренней параллельной) 100% означает большой жор, если только не копировать прошивку в оперативку с последующей отправкой флешки в спячку. Т.е. сабж явно не позиционируется как энергоэффективный. Поэтому применение CM0 (ещё и нестандартного) тут явно ни к селу, ни к городу. Аналогично про USB 1.1 вместо FS USB 2.0. Так что версия насчёт сертификации выглядит куда более обоснованной, чем насчёт оптимизаций.

Ответить | Правка | Наверх | Cообщить модератору

270. "Проект Raspberry Pi представил плату Pico на основе собствен..."  +/–
Сообщение от Аноним (-), 25-Янв-21, 12:51 
> Во флешках, кстати, точно трогает. Ибо на ком ещё реализовывать трансляцию (обработку
> переназначений, выравнивание износа и т.д)?

1) Это делается не на каждый пшик.
2) Проц лично каждый байт ворочать при этом не обязан. Попросил DMA вгрузить от сих до сих, прикинул куда, попросил DMA вгрузить от сих до сих. А проц только параметры сетапил.

> Это не отменяет здоровенной приблуды для DMA, но всё же.

Я лишь про то что весь heavy lifting сделал DMA. Хотя бывают и варианты где так, видимо, не сделано - у которых скорость R/W мег в секунду, ага. Вот оно может и программно, конечно, но радости с такой реализации...

> В переходниках, впрочем, прошивка тоже куда более
> интересная, чем просто настроить и отвалить.

Естественно. Но общая идея остается - без DMA оно если и может то с крайне жалким перфомансом.

> Вот не надо по темам скакать. 8051 был упомянут к тому, что ядро CM0 ну вообще никак
> не запрещает наличия хотя бы FS USB 2.0 (а не только 1.1), а то и HS.

Так то не запрещает. Вопрос осмысленности сочетания. А они там FS не сделали? Или просто объявили его как 1.1?

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

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

> Да что уж тут, внешняя последовательная флешка (вместо внутренней параллельной)
> 100% означает большой жор, если только не копировать прошивку в оперативку
> с последующей отправкой флешки в спячку.

С их объемом RAM вполне можно все в RAM держать, и код и данные. А та внешняя флешка, вообще, хотя-бы замаплена в адреса чтоли? Ну и скорость всего этого даже если оно и - не сравнима с нормальной шиной, так что выполнение из SPI напрямую бывает двух видов - или не работает, или слоупочит сильно.

> Т.е. сабж явно не позиционируется как энергоэффективный. Поэтому
> применение CM0 (ещё и нестандартного) тут явно ни к селу, ни
> к городу. Аналогично про USB 1.1 вместо FS USB 2.0. Так
> что версия насчёт сертификации выглядит куда более обоснованной, чем насчёт оптимизаций.

Сертификаций чего и зачем?

Ответить | Правка | Наверх | Cообщить модератору

274. "Проект Raspberry Pi представил плату Pico на основе собствен..."  +/–
Сообщение от n80 (?), 25-Янв-21, 13:16 
> 1) Это делается не на каждый пшик.
> 2) Проц лично каждый байт ворочать при этом не обязан. Попросил DMA
> вгрузить от сих до сих, прикинул куда, попросил DMA вгрузить от
> сих до сих. А проц только параметры сетапил.

Не на каждый чих. Но это я к тому что аргумент про CM0 — не аргумент.

>> Вот не надо по темам скакать. 8051 был упомянут к тому, что ядро CM0 ну вообще никак
>> не запрещает наличия хотя бы FS USB 2.0 (а не только 1.1), а то и HS.
> Так то не запрещает. Вопрос осмысленности сочетания. А они там FS не
> сделали? Или просто объявили его как 1.1?

FS = 12 Мбит/с, это там точно есть. А вот может ли оно в 2.0 FS (с большими оконечными точками и обычной скоростью) — непонятно.

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

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

> С их объемом RAM вполне можно все в RAM держать, и код и данные.

Помнится мне, выполнение из SRAM жрёт больше электричества, чем из flash (но и более быстрое). Это так, к вопросу о моём аргументе, что эта железка не позиционируется как энергоэффективная.

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

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

> Сертификаций чего и зачем?

Неудачно выразился, речь про лицензирование. Т.е. нельзя просто так взять и заявлять совместимость с ARM, с USB и т.д., это всё требует существенной оплаты в соответствующие организации, при этом в случае ARM — на каждый тип ядра отдельно.

Ответить | Правка | Наверх | Cообщить модератору

297. "Проект Raspberry Pi представил плату Pico на основе собствен..."  +/–
Сообщение от Аноним (-), 26-Янв-21, 12:08 
> Не на каждый чих. Но это я к тому что аргумент про CM0 — не аргумент.

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

> FS = 12 Мбит/с, это там точно есть.

Ну тогда я не понимаю что там про мышей воняют, это даже через usb3 вроде должно лезть? Те только на low speed обижаются вроде, и то, usb3 хаб это лечит.

> А вот может ли оно в 2.0 FS (с большими оконечными точками и обычной скоростью) — непонятно.

Ох, это уже RTFMать доки надо, мне на броадкома это лень, извините :)

> Жор, о котором я говорю, не столько ядром определяется, сколько частотой, умением
> динамически менять её, ну и нюансами периферии (clock gating, возможность будить
> ядро из спячки по приёму пакета на определённый адрес и т.д.).

Жор при прочих равных таки пропорционален числу переключаемых вентилей. Поэтому при прочих равных чем меньше вентилей тем меньше жрет. И M0 делался с прицелом на что-то такое, настолько что ему даже команды подобрубили.

> Помнится мне, выполнение из SRAM жрёт больше электричества, чем из flash (но
> и более быстрое).

Как минимум из даташитов STM32F следует что это ровно наоборот - флеш кушает больше, и к тому же тормознее по времени доступа, требуя wait states на быстрых камнях. Зато его больше и он энергонезависимый. К тому же в >=M3 он на отдельной I-bus, поэтому code fetch -> Ibus, Data -> Dbus. Параллельно. А если вы из RAM - тогда ВСЕ -> Dbus, и вот тут вопрос чья возьмет, сводится к тому перевесит ли отсутствие wait states возросший трафик шины.

> Это так, к вопросу о моём аргументе, что эта железка не позиционируется
> как энергоэффективная.

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

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

Это не "в духе ESP", а, вообше, довольно распостраненное явление. Которое кажется даже на x86 появилось, еще с заменой FWHUB -> SPI NOR. А заодно и на хреновой куче устройств, особенно китайских. Я это видел на некоем принтсервере с чипом CNS21xx вообще (какой-то кривоватый ARM9 с линуксом на борту).

> Неудачно выразился, речь про лицензирование. Т.е. нельзя просто так взять и заявлять
> совместимость с ARM, с USB и т.д., это всё требует существенной оплаты в
> соответствующие организации, при этом в случае ARM — на каждый тип ядра отдельно.

Ну как бы 1 раз на семейство чипов для чипмейкера наверное это реально сделать. Так что все-таки странно.

Ответить | Правка | Наверх | Cообщить модератору

309. "Проект Raspberry Pi представил плату Pico на основе собствен..."  +/–
Сообщение от n80 (?), 26-Янв-21, 13:27 
> > FS = 12 Мбит/с, это там точно есть.
> Ну тогда я не понимаю что там про мышей воняют, это даже через usb3 вроде должно лезть? Те только на low speed обижаются вроде, и то, usb3 хаб это лечит.

Ой, USB3 — вообще совершенно отдельная вещь в себе (две диффпары вместо одной, другое кодирование и т.д.), в синих разъёмах по сути два независимых порта присутствуют (да, можно подключить два устройства в один порт, если одно из них будет 3, а другое 2.0 или 1.1) и обслуживаются разными контроллерами, пусть иногда и находящимися на одном кристалле, но по сути всё равно отдельными.

> Поэтому при прочих равных чем меньше вентилей тем меньше жрет. И M0 делался с прицелом на что-то такое, настолько что ему даже команды подобрубили.

Да, это помню.

> Как минимум из даташитов STM32F следует что это ровно наоборот - флеш кушает больше

Опачки, и правда. Вообще, утверждение про жор SRAM я в своё время слышал в обсуждении про сравнением STM32 и GD32 (специфичные клоны от GigaDevice, с увеличенным объёмом оперативки и последовательной флешкой вместо параллельной), но вот смысл его уловил криво, видимо. Похоже, тогда на самом деле имелось в виду, что больший объём SRAM увеличивает жор контроллера в целом (ну и менее вылизанный техпроцесс, конечно же), а не сам факт выполнения из SRAM вместо flash.

>> Это так, к вопросу о моём аргументе, что эта железка не позиционируется как энергоэффективная.
> А черт его там знает. Это на самом деле даташит курить надо, но для сабжа я это делать не буду, ну нафиг на таких закладываться.

Аналогично.

> Это не "в духе ESP", а, вообше, довольно распространенное явление. Которое кажется даже на x86 появилось, еще с заменой FWHUB -> SPI NOR. А заодно и на хреновой куче устройств, особенно китайских. Я это видел на некоем принтсервере с чипом CNS21xx вообще (какой-то кривоватый ARM9 с линуксом на борту).

Вроде, обычно на таких железках флешка (точнее, область с загрузчиком) один раз при старте зачитывалась в RAM (на x86 сначала в CAR = Cache as RAM, а потом в DRAM), а вот чтобы прямо с неё было выполнение на протяжении всего времени работы (с отображением в адресное пространство и прозрачным кешированием) я всё-таки впервые увидел на ESP. Аналогично и PSRAM (pseudo-SRAM, динамическая оперативка с последовательным интерфейсом и автоматическим обновлением) Но, возможно, они и правда не были первыми.

Ответить | Правка | Наверх | Cообщить модератору

321. "Проект Raspberry Pi представил плату Pico на основе собствен..."  +/–
Сообщение от Аноним (321), 27-Янв-21, 00:51 
> Ой, USB3 — вообще совершенно отдельная вещь в себе (две диффпары вместо
> одной, другое кодирование и т.д.),

Да я в курсе, EHCI vs xHCI еще. Там просто прикол какой-то есть, типа того что usb3 хаб принципиально не может lowspeed девайс пробросить, чтоли. И вот втыкаешь lowspeed мыша или клаву в 3.0 хаб, а линух и выдает - "error: not enough bandwidth". Видимо более внятный мсг на этот бред спеков они не придумали. Лечится втыканием 2.0HS хаба в это, а вот в него уже мыша. Может и FS катит. Главное чтобы SuperSpeed не встречался с LowSpeed напрямую как я понял. Brainfart какой-то.

> и обслуживаются разными контроллерами, пусть иногда и находящимися на одном кристалле,
> но по сути всё равно отдельными.

Да я знаю. Но самый стеб в том что SS пары отдельно от 2.0 не могут существовать вроде. А там еще typeC появился. Опять полунедосовместимый и сопромат они опять прогуляли, часть тупняков исправили, новых оптом добавили, как и полубэкдорные фичи (дав старт стебным атакам badPowerSupply). В общем USB IF тоже те еще фрукты.

> Да, это помню.

Математика там все же хромает. Продвинутые алгоритмы жирнее, а флеша, по иронии обычно меньше.

> Опачки, и правда. Вообще, утверждение про жор SRAM я в своё время
> слышал в обсуждении про сравнением STM32 и GD32

Вот как оно у гадов я не помню, их шиты я пока по диагонали читал.

> но вот смысл его уловил криво, видимо. Похоже, тогда на самом
> деле имелось в виду, что больший объём SRAM увеличивает жор контроллера в целом

Вот это может быть. Но в STM производитель утверждает что SRAM немного экономичнее. Разница небольшая.

> Вроде, обычно на таких железках флешка (точнее, область с загрузчиком) один раз
> при старте зачитывалась в RAM

А вот это где как. Он часто просто direct mapped в некие адреса, контроллер транслирует чтения этого в операции SPI NOR в железе. Я так SPI флеша с той штуки слил. Тупым md.b uboot'а.

> в адресное пространство и прозрачным кешированием) я всё-таки впервые увидел на
> ESP. Аналогично и PSRAM (pseudo-SRAM, динамическая оперативка с последовательным интерфейсом
> и автоматическим обновлением) Но, возможно, они и правда не были первыми.

Я даже не знаю кто у кого это упер. Но это довольно общеизвестная идея, может быть китайцы даже 1 железку на всю толпу копипастят, кто их там знает. Упомянутый девайс весьма ископаемый, наверное 2000х каких-то, ARM9 на 250МГц, даже не cortex еще. Я не уверен что в лохматые годы его разработки ESP вообще существовал.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру