xmem shield, расширение SRAM

[ALS]

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

Саму идею не критикую - если действительно есть насущная задача, в которой нужен "сверх"-большой (применительно к 2560) объем памяти, то почему бы и нет ?
Но, повторюсь, проблема в том, что такой задачи (не гипотетической, а реальной) пока никто не смог придумать

[Arhat109]

Да ладно.

Задача №1: оцифровка микрофона. ADC способен обрабатывать сигнал за 125мксек. Не густо, всего 8кГц, но для ряда задач - вполне достаточно. Телефонная полоса пропускания 6.3кГц, ваще-то. Слушаем, воспроизводим.

Пока оно 125мксек оцифровывается, контроллер способен исполнить около 1500 команд "средневзвешенной смеси". Можно ли "за это время" справится со SPI_RAM или SD/EEPROM...etc? Вроде бы да.

обратная задача "вывод" через ШИМ, к примеру (ежели DAC нет) - имеем теже самые 125мксек на расшифровке и плюсом аппаратный ШИМ: "плюнул в регистр OCRx и забыл". И опять же "вытащить" следующий байтик даже из SD можно успеть.

... но. ИЛИ имеем гонку "успел/неуспел" с последовательной RAM любого типа ИЛИ при прямом чтении байтика одной командой имеем возможность исполнять ИНУЮ работу в тоже самое время. То бишь, "загрузка" микроконтроллера при оцифровке звука внезапно падает с 50-70% до (62.5*2.5)/125000 = 0.125% (2.5 команды процессора в среднем на операцию) ... есть разница?

2. Вывод инфы на TFT дисплей. Упс ... вот много где уже читал что "не успевает", "задача не для Ардуино" ... с чего это "вдруг"? При наличии прямоадресуемой RAM, да даже в 64к - уже вполне посильная задача.

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

P.S. ну и дополню.

Как-то "странно" всё у современных разработчиков: 16 мегагерцовый проц ... и не способен решать примитивнейшие задачи ... и память ему "не нада ибо тупой" ...

Вопрос: КАК Минск-222М (с которого когда-то начинал) имея ВСЕГО 6-8 КИЛОСЛОВ (правда больших ок 40бит) оперативы умудрялся обслуживать терминальный класс на 8 рабочих мест?
Вопрос2: Д3-28 ("бортовой вычислитель МИГ-17, кажись). Теже 16Мгц. Организация 8/16 разрядов, 32 регистра общего назначения ... ну практически Ардуино, если не считать что система команд "на порядок" компактнее и лучше ... и практически встроенная библиотека "FPU на борту" (вычисление синуса - 13кГц помнится) ... оч. хорошо помню, когда пошли первые 128кб машинки - как все подпрыгивали и хлопали в ладошки... не хватало, однако.

... так может "задач нет" вовсе не потому, что не справляется, а потому что "памяти маловато" и катастрофически, не?

[Arhat109]

Кстати, пофлудить. Тоже вот, занялся Ардуинкой и стал беспокоить такой вопрос:

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

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

[Arhat109]

Посмотрел систему команд ... ко всем регистрам-указателям есть дополнительный байтовый регистр RAMPxx ... который внезапно и теоретически таки позволяет адресовать аж до ... 16 мегабайт оперативы. То есть, при желании, можно даже компилятор научить транслировать адреса на память более 64кб.

[Admin]

Сообщение от Arhat109

Кстати, пофлудить. Тоже вот, занялся Ардуинкой и стал беспокоить такой вопрос:

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

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

У нас слишком высокая себестоимость конечного продукта, ну и все хотят сразу много заработать
Достаточно посмотреть на стоимость Мультиклета, Эльбруса, YotaPhone и др.

[Arhat109]

Мне только кажется, что второе является ПРЯМОЙ причиной первого?

... из этого, к моему сожалению, вытекает лишь только одно следствие: "у нас нет НИЧЕГО", а не только микроконтроллеров. Нация, желающая заработать "сразу и много" - обречена безвозвратно. Увы.

[ALS]

Сообщение от Arhat109

P.S. ну и дополню.

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

ну, с нынешним подходом к программированию, когда "hello, world" или мигание светодиодом занимают до 10% памяти той же меги - да, так оно и есть.
Программили бы по-старинке на асме или на си, но хотя бы без "надстроек над прослойками" - глядишь, и большинство задач решались бы "набортными" средствами. А так... что имеем - то имеем

Простой пример.
Делаю наручные часики. Выпускаю малыми сериями (т.е. все отлажено и работает). Программный код занимает ок. 300 байт (слов).
Тут же кто-то пытается сделать что-то аналогичное, вопрос к сообществу "на чем делать ?" и сходу советы : "бери мегу, запас карман не тянет!" (с)
Можно. А зачем ? И (сорри, конечно) ситуацию с большим объемом памяти не напоминает ?

[Arhat109]

А давайте пофлудим слегка ... я все одно - далече (делать ничё не магу), полезность железяки - тока "для себя любимого" (можно и на макетнике сваять) ... в общем, тема себя изжила.

Да, и с этой стороны тоже. Есть такое.

Ну, скажем, мне - совершенно понятно "зачем" и Мега и память... тут в соседнем подраздельчике "Робототехника", wagan запостил тему про "собираем робота", а поскольку тоже собираю ... вот ему там "подкинул" примерную схемку, что у меня получается с ногами меги как "центрального блока" альтернативного Лего Майндшторм ... маловато ножек-то.

... и ведь движки уже практически "все расписаны"...

Ну и ещё: когда-то много игрался с этим "бортовым вычислителем" ... в т.ч. и в части организации "кластерных" вычислений (как понимаю, даже те МИГи могли совершенно спокойно помогать друг дружке вести цели обсчитывая то, что сосед не успевал)... вот и появилась идейка - в какой габарит "влезет" тот бортовой вычислитель? И можно ли тут сваять его "эмулятор"? ...

[ALS]

Мое мнение: если есть время и желание - делайте.
Пусть даже для "поиграться и положить в стол".

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

[Arhat109]

Ну ... время... его нет конечно же, как обычно ... но антиресна ... А раз есть интерес, значит - "найдется".

К вопросу о памяти:

Вот смотрите, из тех экспериментов что делал совсем недавно:

Есть датчик HC-SR04 - ультразвуковой датчик измерения расстояний. Доработал, приклеив "уши" и заузив ему диаграмму до разумных 3-5 градусов от оси. Поставил его на сервомотор. Делая по 5-7 замеров, могу заузить диаграмму ещё немножко ... получил стабильные 3 градуса.

Теперь, чтобы мне построить "карту расстояний +-90грд", надо поворачивать серву и делать по 5-7 замеров на каждом направлении.

Итого имеем 2 исполнительных устройства (всего!) с состояниями:
1. Датчик:
1.1. Исходно, готов к замеру;
1.2. Замер начат (отправлен свисток);
1.2. Производит текущий замер "ждем начало импульса - ждем прерывание по ICP";
1.3. Производит замер2 "ждем завершения импульса" -- должен быть включен таймаут (ниже)
1.4. Очередной замер произведен, расстояние действительно, идет замер согласно серии.
1.5. Замер завершен, Расстояние усреднено и действительно.

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

2. Сервомотор:
2.1. Собственно текущее положение мотора. Число.
2.2. состояния: "стоит"/"едет к заданной точке". Как выяснилось - поворачивается он далеко не "мгновенно" по меркам скорости исполнения команд, даже на 3 градуса (7-8миллисекунд!).

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

... просто? Угу. А как насчет памяти? 180/3 = 60 чисел расстояний = 120байт. + 10 байт на текущие 5 замеров для усреднения + 1 байт на состояние датчика + 1 байт на положение мотора +1 байт на его состояние + матрица переходов + таймауты + очередь событий + команды исполнения автомату ... может я и не сильно оптимизировал память, но у меня "итого" вылезло в около 500 байт.

И это только два устройства управления. А ещё надо учитывать собственные повороты и перемещения робота в этом пространстве расстояний ... и, как там "с памятью"?

P.S. Ну кстати, мое отношение к железкам и ресурсам примерно следующее: Железка по возможности должна предоставлять максимум ВОЗМОЖНОСТЕЙ, а вот тратить ресурс, в т.ч. и память, и даже в первую очередь её - надо КАК МОЖНО экономнее. В этом отношении, в процессе "воспоминания" - первым делом частично запилил себе собственный Wiring ... с типовым blink уже в ... 490 байт (это если вся таблица векторов).

P.P.S. Ну и ещё немаловажный момент: автомат управления в такой реализации более чем на 90% времени ... тупо простаивает. На смену состояния или запуск действия уходит буквально менее 10 команд. Это к вопросу "а справится ли этот микроконтроллер со всем тем барахлом, которое я на него собираюсь навешать одновременно" - похоже что "легко".