Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Ср апр 24, 2024 05:04

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 37 ]  На страницу Пред.  1, 2, 3
Автор Сообщение
 Заголовок сообщения:
СообщениеДобавлено: Вт ноя 27, 2007 11:54 
Не в сети
Аватара пользователя

Зарегистрирован: Чт июл 20, 2006 11:31
Сообщения: 2168
Откуда: Екб
Благодарил (а): 0 раз.
Поблагодарили: 41 раз.
nicka писал(а):
...И всё. Работы минут на десять.

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

_________________
С уважением, chess


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вт ноя 27, 2007 13:15 
nicka писал(а):
И по этому интерфейсу(кстати, какой топологии: лично с каждым, кольцо, общая магистраль с арбитражем)

Предпочитаю деление на блоки с общей магистралью и одним ведущим внутри блока. Т.е. дерево :) . Преимущество - опять-же таки проще отладка.

nicka писал(а):
на скорости 1кбайт/с будем гонять тристокилобайтную картинку?

На кой? По шине гоняется уже результат обработки картинки. Самой картинке там делать нечего.
Кстати, для обработки картинки Spartan - самое оно ;) .

nicka писал(а):
Подумайте о топологии и логике межпроцессорного взаимодействия.
Пара-тройка каких-нибудь SPI интерфейсов потребует 6-9 ног от каждого микроконтроллера, а программный 1-wire одновременно с 20ШИМ пишите сами.

Я уже говорил - между процессорами два провода (можно использовать UART).
Программный 1-wire (почти ;) програмный) для Тини25 на неделе закончу. Кроме него там еще один шустрый PWM и один АЦП (МК на 8 ног). Как ты понимаешь, все три процесса друг другу не мешают.

ЗЫ. Да, забыл сказать - тактовая 1МГц.
nicka писал(а):
(при тираже 1шт наверняка выйдет дороже, чем кит с ФПГАшкой)

Вот розничный прайс...
http://www.efo.ru/doc/Atmel/price.pl


Последний раз редактировалось ArtemKAD Вт ноя 27, 2007 18:21, всего редактировалось 1 раз.

Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вт ноя 27, 2007 13:55 
nicka писал(а):
Понятно что задача "в принципе решается", но решение получается громоздким и малорасширяемым.
Кстати, если 1мс поделить на 250 дискретов и на 16 каналов, то получится 4операции на частоте 16МГц.

Р-р-р... Вы че, программно считаете времянку для каналов :shock: ? Не удивительно, что м32 для Вас не хватает...
Делаешь так:
Делишь 20мс на 8 = 2,5мс. Это времянка для прерывания по компаратору ICR1 (40000 при 16МГц тактовой) . Из них первые 0,8 мс на принятие решения, а че-же делать и последние 0,3 мс "запаса". Настраиваешь 1-й таймер в режим 12 (CTC по icr1) .
Импульсы будут формироваться парами по одному на PB и PC. Начало импульса на нужном канале на обеих портах формируется в прерывании ICF1 (хоть сдвигом единички прочтенной из PORTx). Длительность устанавливается в OCR1a и OCR1b. В прерываниях OCR1a и OCR1b порты PB и PC DDR-ами переводятся в 3-е состояние (т.е. если все сделать аккуратно, то не надо сохранять даже SREG) чем и обеспечивается задний фронт при сохранении в регистре порта текущего формируемого канала.

Возможные сложности - импульс 1мс делится не на 250 дискретов, а на 16000, что надо учесть в куске (в основном цикле) готовящем данные для PWM-ов.

Громозкости не вижу абсолютно. Кода там на много меньше 500 слов (даже меньше 250 слов ;) ).


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт ноя 29, 2007 23:55 
Не в сети

Зарегистрирован: Вс ноя 25, 2007 22:53
Сообщения: 29
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
Kopa писал(а):
Например тогда не существовал бы проект С-- компилятора, и всевозможных расширений Си ( например, для разных ОS часто необходимо применение ассемблера ) Плохо ложащихся случаев, на самом деле много, т.к. архитектуры ядер контроллеров весьма разнообразны Даже ядро Linux компилируется на Си, с определенными расширениями языка. У меня наверное крайний случай, нужно ужиматься в потреблении, и как один из вариантов применять как можно меньшую частоту.


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

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

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


"мы можем сделать быстро, дёшево, качественно. Выберите любые два." :)

_________________
С приветом, Никита.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт ноя 30, 2007 09:00 
Не в сети
Moderator
Moderator

Зарегистрирован: Ср май 10, 2006 15:37
Сообщения: 1132
Откуда: Chelyabinsk ( Ural)
Благодарил (а): 0 раз.
Поблагодарили: 9 раз.
nicka писал(а):
lcc - в принципе интересно. Но.. У него вроде бы довольно слабый оптимизатор, да и я что-то сходу не нашел прямой ссылки, чтоб скачать исходники.


Прямая ссылка:
http://www.cs.princeton.edu/software/lcc/

Да у него довольно слабый оптимизатор, но зато при этом компилятор
не "монстрообразен" и достаточно гибок для экспериментов.
На базе LCC сделан PellesC ( код генерит для PC и ARM ) правда без исходников.
Mihail, в первом приближении, перенес исходники его для SPF Форта.
И соответственно SPF макро-оптимизатор, при соответствующей доработке
может генерировать достаточно эффективный код, правда без соответствующей
переделки SPF, пока только для PC. У Mihaila есть и варианты использования
SPF для контроллеров.

P.S. Интерес с LCC для меня связан, с возможностью использовать его
для генерации промежуточного стекового представления программ
и последующей доводки решения ( с помощью трансформаций )
при генерации кода на конкретную систему команд ядра контроллера.
( Упоминание про это можно найти в соответствующем топике данного
форума связанного с LCC :) Промежуточный стековый код даю на
вход SPF и замеряю его производительность в сравнении с Си и Форт
эквивалентами. В качестве Си использую PellesC.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт ноя 30, 2007 09:11 
Не в сети
Moderator
Moderator

Зарегистрирован: Ср май 10, 2006 15:37
Сообщения: 1132
Откуда: Chelyabinsk ( Ural)
Благодарил (а): 0 раз.
Поблагодарили: 9 раз.
P.S. Прененесенное собщение по LCC оказавшееся после разделения в топике ПЛИС и МК.:)

Kopa писал(а):
nicka писал(а):
Kopa писал(а):
Не лучше т.к. существующие компиляторы не позволят максимально использовать существующую аппаратуру.


Вы, конечно, извините, но мне почему-то кажется, что Вы не умеете использовать эти самые существующие компиляторы. У меня "почему-то" получается порядка 90-120% по скорости и весьма соизмеримо по объёму (в проектах от ~3кб объёмом). Парочку плохоложащихся на си случаев я знаю, но сильно сомневаюсь, что вы сможете их назвать.


Если, задача решается в выбранной конфигурации с заданными средствами
сейчас, то это не значит, как писал "Хищник" - будет всегда:)

Например тогда не существовал бы проект С-- компилятора, и всевозможных
расширений Си ( например, для разных ОS часто необходимо применение
ассемблера ) Плохо ложащихся случаев, на самом деле много, т.к.
архитектуры ядер контроллеров весьма разнообразны:) Даже ядро
Linux компилируется на Си, с определенными расширениями языка.
У меня наверное крайний случай, нужно ужиматься в потреблении,

и как один из вариантов применять как можно меньшую частоту.


Но это все полемика, ближе к теме можете посмотреть, например
проект www.fpgacpu.org/xsoc процессора там в качестве Си используется
LCC и приводится back-end для него. ( архитектура построена на
регистровой модели ).

Что то подобное с использованием backenda для LCC
http://www.homebrewcpu.com/magic-16.htm ( не понял есть ли реализация в FPGA)

Посмотрите еще http://www.ida.liu.se/~chrke/optimist/
( тоже к подборке применения LCC - например к сигнальникам M56 )
есть сравнение применненного подхода для AVR в IAR и их метода оптимизации
и другие статьи)


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн мар 03, 2008 10:32 
Не в сети
Moderator
Moderator

Зарегистрирован: Ср май 10, 2006 15:37
Сообщения: 1132
Откуда: Chelyabinsk ( Ural)
Благодарил (а): 0 раз.
Поблагодарили: 9 раз.
Есть презентация
Dave Wyland
SIFT, FPGAs and Forth ( FIG presentation 3/25/06)

http://davehylands.com/Misc/SIFT/SIFT-Forth.ppt

по использованию FPGA для роботов.

P.S. На сайте тоже много материалов по роботостроению.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 37 ]  На страницу Пред.  1, 2, 3

Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 11


Вы не можете начинать темы
Вы можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB