По поводу реализации Forth на AVR

 
RU Knightmare #30.07.2005 00:21
+
-
edit
 

Knightmare

новичок
Программирую для камня ATMega128 на C++. Естественно, через какое-то время встал вопрос об эффективном расходе ресурсов. На камне 128K памяти для программ, 4K RAM и 4K - EEPROM.
В погоне за эффективностью наткулся на Forth. О чудо ! такой маленький и такой эффективный. В общем, мне он понравился и я загорелся реализовать Forth на этот камень и прямо в этот камень затолкать компилятор ! НО, есть следующие проблемы: гарвардовская архитектура, (т.е. данные и код - раздельно) и память для программ ограничена на количестов перезаписей - всего 1000 раз и к тому же писать можно только страницами (256 байт). Естественно, встает вопрос - как реализовывать компилирующие слова и ассемблер (в Forthе я новичок) и вообще, возможно ли такое сделать для этого камня ?
 
BG Реконструктор #30.07.2005 00:40
+
-
edit
 
Люди понаделали уже. И не мало. Но я по прежнему упрямо не воспринимаю форт как полноценный язык, близкий к программисткой логике.
 
RU Knightmare #30.07.2005 01:16  @Реконструктор#30.07.2005 00:40
+
-
edit
 

Knightmare

новичок
Реконструктор> Люди понаделали уже. И не мало. Но я по прежнему упрямо не воспринимаю форт как полноценный язык, близкий к программисткой логике. [»]

Ссылку, пожалуйста, если видел. Не воспримаешь как полноценный язык близкий к программистской логике ? Ну-ну...Не воспринимаю подобное рассуждение, как полноценное и близкое к программистской логике
 
Это сообщение редактировалось 30.07.2005 в 13:39
RU Balancer #30.07.2005 08:27  @Knightmare#30.07.2005 00:21
+
-
edit
 

Balancer

администратор
★★★★★
Knightmare> Программирую для камня ATMega128 на C++. Естественно, через какое-то время встал вопрос об эффективном расходе ресурсов. На камне 128K памяти для программ, 4K RAM и 4K - EEPROM.
Knightmare> В погоне за эффективностью наткулся на Forth. О чудо ! такой маленький и такой эффективный. В общем, мне он понравился и я загорелся реализовать Forth на этот камень и прямо в этот камень затолкать компилятор ! НО, есть следующие проблемы: гарвардовская архитектура, (т.е. данные и код - раздельно) и память для программ ограничена на количестов перезаписей - всего 1000 раз и к тому же писать можно только страницами (256 байт). Естественно, встает вопрос - как реализовывать компилирующие слова и ассемблер (в Forthе я новичок) и вообще, возможно ли такое сделать для этого камня ? [»]

Расскажи про разделение кода и данных. Код что, считывать вообще нельзя? Тогда Форт-код придётся хранить в области данных. Но соотношение код/данные 128/4 будет в таком случае категорически не в пользу Форта :-/
 
RU Knightmare #30.07.2005 13:37  @Balancer#30.07.2005 08:27
+
-
edit
 

Knightmare

новичок
Balancer> Расскажи про разделение кода и данных. Код что, считывать вообще нельзя? Тогда Форт-код придётся хранить в области данных. Но соотношение код/данные 128/4 будет в таком случае категорически не в пользу Форта :-/ [»]
Код считывать, конечно можно. Дело в том, что код и данные лежат в разных адресных пространствах. Даже инструкции для считывания и записи для этих пространств - разные, т.е. единого указателя в данной архитектуре нет и камень принципиально не может выполнять инструкции из пространства данных. Хочешь исполнить код - нужно записать его в область кода, и никак по другому. Все это не тяжелые ограничения, а вот ИМХО настоящие "вилы" - то что записывать в пространство кода можно только по страницам (256 байт) и количество перезаписей равно 1000. Так вот вопрос - можно ли организовать для такой архитектуры Forth-машину с компилирующими словами и какие будут ограничения ?

 
RU Серокой #30.07.2005 14:27  @Knightmare#30.07.2005 13:37
+
-
edit
 

Серокой

координатор
★★★★
Knightmare> ИМХО настоящие "вилы" - то что записывать в пространство кода можно только по страницам (256 байт) и количество перезаписей равно 1000. [»]

Записывать-то можно по словам, а уж потом скидывать временный буфер в память. Другое дело, что данные недоступны будут, пока не скинутся. Механизм самостоятельного программирования памяти предназначен для обновления прошивки, хранения массивов данных, но никак не для постоянного хранения и обновления данных, то есть нельзя с фон-неймановскими подходами, надо наоборот Форт под гарвардскую архитекутру докручивать.
В общем, я не понимаю, зачем именно так делать - сливать страницу во временный буфер, модифицировать данные, стирать страницу и снова заливать, тем более на не предназначенной для этого архитектуре.
А вообще, практика показывает, что 1000 перезаписей- не предел, флэш данных живёт и дольше. Негарантированно, конечно ж.
Больше не раскалятся ваши колосники. Мамонты пятилеток сбили свои клыки. ©  

61284

опытный
★★
>> Так вот вопрос - можно ли организовать для такой архитектуры Forth-машину с компилирующими словами и какие будут ограничения ?

А почему кросс-компилер не подходит?

 
RU Alex Privalov #30.07.2005 19:05
+
-
edit
 

Alex Privalov

новичок
Knightmare>На камне 128K памяти для программ, 4K RAM и 4K - EEPROM

Если нехватает и того, и другого и третьего - лучше ищи другой процессор. Обычно нехватает ОЗУ, а это лечится прикручиванием к ATMega внешней SRAM — до 64Кбайт.

ЗЫ. Flash в ATMega-ах гарантировано перезаписывается минимум 10000 раз (по даташиту), ЕМНИП.
 
RU Knightmare #30.07.2005 21:10  @Alex Privalov#30.07.2005 19:05
+
-
edit
 

Knightmare

новичок
Knightmare>>На камне 128K памяти для программ, 4K RAM и 4K - EEPROM
A.P.> Если нехватает и того, и другого и третьего - лучше ищи другой процессор. Обычно нехватает ОЗУ, а это лечится прикручиванием к ATMega внешней SRAM — до 64Кбайт.
И другие процессора есть :) Но интересно именно для этого камня, уж больно он хорош по рабочим характеристикам, да и недорогой. По поводу внешней памяти - всеравно код записанный в нее нельзя будет исполнить. :(
A.P.> ЗЫ. Flash в ATMega-ах гарантировано перезаписывается минимум 10000 раз (по даташиту), ЕМНИП. [»]

И в правду 10 000 раз, спасибо (просто помню - что для программирования через загрузчик - хватает, а для рабочих нужд программы - изотрется быстро) B) . Но всеравно - при добавлении нового слова в словарь перезаписывать целую страницу - роскошь.
 
Это сообщение редактировалось 30.07.2005 в 22:04
+
-
edit
 

Knightmare

новичок
>>> Так вот вопрос - можно ли организовать для такой архитектуры Forth-машину с компилирующими словами и какие будут ограничения ?
61284> А почему кросс-компилер не подходит?
61284> Andrew Sterian [»]
Нужно иметь компилятор внутри камня. Поэтому кросс-компилер не подходит. За ссылку - большое спасибо
 
RU Dem_anywhere #01.08.2005 18:21
+
-
edit
 

Dem_anywhere

аксакал
★☆
2 Knightmare
На самом деле в форт-программе кода нет - сплошь данные :) Код нужен только для базовых слов.
И вообще, можешь сделать один из битов адреса слова флагом, указывающим в какой памяти надо работать
 
+
-
edit
 

Sap

втянувшийся

Knightmare>>>На камне 128K памяти для программ, 4K RAM и 4K - EEPROM
A.P.>> Если нехватает и того, и другого и третьего - лучше ищи другой процессор. Обычно нехватает ОЗУ, а это лечится прикручиванием к ATMega внешней SRAM — до 64Кбайт.
Knightmare> И другие процессора есть :) Но интересно именно для этого камня, уж больно он хорош по рабочим характеристикам, да и недорогой. По поводу внешней памяти - всеравно код записанный в нее нельзя будет исполнить. :(
[»]
Угу, посмотри AT91SAM32 - кажется так :) стоит чуть дороже, но это уже настоящий 16/32 бит ARM7 (55 MIPS @ 50 МГц) со всеми своими наворотами плюс программирование через UART. :))) И пиши себе на C++ :)))
Хотя если честно то это изврат какой-то - для контроллеорв такие языки использовать - не эффективно получается. ЧТо C++, что форт очень и очень не фээективны на данной архитектруре, а уж если учесть какие задачи обычно приходится решать так и вообще не ясно ЗАЧЕМ ВСЁ ЭТО ТУТ ?!

 
+
-
edit
 

Knightmare

новичок
Sap> Угу, посмотри AT91SAM32 - кажется так :) стоит чуть дороже, но это уже настоящий 16/32 бит ARM7 (55 MIPS @ 50 МГц) со всеми своими наворотами плюс программирование через UART. :))) И пиши себе на C++ :)))
Sap> Хотя если честно то это изврат какой-то - для контроллеорв такие языки использовать - не эффективно получается. ЧТо C++, что форт очень и очень не фээективны на данной архитектруре, а уж если учесть какие задачи обычно приходится решать так и вообще не ясно ЗАЧЕМ ВСЁ ЭТО ТУТ ?! [»]
Хех. Если бы дело было только в наворотах. А нужна еще надежность и пригодность для полевых условий , т.е. читай: чем меньше всякой периферии в устройстве - тем оно кошерней. Идеальный случай: камень, питание и развязки для входов/выходов. ATMega приближается к идеальному варианту.
По поводу C++ - не хочу я на нем писать, портабельность требует усилий. И по поводу языков - компиляторы сейчас хорошие делают. Нет особого смысла писать на ассемблере. Ну разве что из любви к искусству, чтобы применить "особые приемы". А вот во времени - запросто можно раз этак в 5 больше потратить. Ну и про переносимость можно забыть, конечно.
 
Это сообщение редактировалось 01.08.2005 в 21:05

Sap

втянувшийся

Sap>> Угу, посмотри AT91SAM32 - кажется так :) стоит чуть дороже, но это уже настоящий 16/32 бит ARM7 (55 MIPS @ 50 МГц) со всеми своими наворотами плюс программирование через UART. :))) И пиши себе на C++ :)))
Sap>> Хотя если честно то это изврат какой-то - для контроллеорв такие языки использовать - не эффективно получается. ЧТо C++, что форт очень и очень не фээективны на данной архитектруре, а уж если учесть какие задачи обычно приходится решать так и вообще не ясно ЗАЧЕМ ВСЁ ЭТО ТУТ ?! [»]
Knightmare> Хех. Если бы дело было только в наворотах. А нужна еще надежность и пригодность для полевых условий , т.е. читай: чем меньше всякой периферии в устройстве - тем оно кошерней. Идеальный случай: камень, питание и развязки для входов/выходов. ATMega приближается к идеальному варианту.
Knightmare> По поводу C++ - не хочу я на нем писать, портабельность требует усилий. И по поводу языков - компиляторы сейчас хорошие делают. Нет особого смысла писать на ассемблере. Ну разве что из любви к искусству, чтобы применить "особые приемы". А вот во времени - запросто можно раз этак в 5 больше потратить. Ну и про переносимость можно забыть, конечно. [»]
Насчтё чем меньше перефирии - это бабушка на две сказала. По такой логике нет ничего лучше старого доьброго 8051 или даже 8049, что конечно не так :)
Или явас не правильно понял ? у того ARMа и память и все переферия на кристалле, так что из обвязки только кварц и питание. ATMega вещь не плохая, но со снижением цен на на ARMы смысла в ней всё меньше - при той же цене производительность в разы меньше. На ATMELе уже висят пресс-редлизы о сворачивании линейки MEGA.
Температурный диапазон и там и там нормальный, а ядро ARM оно гораздо более обкатаное чем AVR. Про хорошие компиляторы :)))) Да, если у вас там общая логика работы, то компилятор с оптимизирует, а если нужно подсчёт импульсов с антидребезгом на прерывания >10000 раз в сек сделать, то разница между C ассемблером уже значительное :) Что конечно не значит, что на ассемблере писаться надо - задачи для ассемблера весьма редкая вещь обычно C всё же за глаза хвататет:)

 
RU Knightmare #02.08.2005 22:28
+
-
edit
 

Knightmare

новичок
Sap> Насчтё чем меньше перефирии - это бабушка на две сказала. По такой логике нет ничего лучше старого доьброго 8051 или даже 8049, что конечно не так :)
Ну иногда это действительно так :)
Sap> Или явас не правильно понял ? у того ARMа и память и все переферия на кристалле, так что из обвязки только кварц и питание. ATMega вещь не плохая, но со снижением цен на на ARMы смысла в ней всё меньше - при той же цене производительность в разы меньше. На ATMELе уже висят пресс-редлизы о сворачивании линейки MEGA.

Вроде ARMы делают все кому не лень. Не подскажешь ссылку на даташит ARMа у которого есть встроенная флешка ?

Sap> Температурный диапазон и там и там нормальный, а ядро ARM оно гораздо более обкатаное чем AVR. Про хорошие компиляторы :)))) Да, если у вас там общая логика работы, то компилятор с оптимизирует, а если нужно подсчёт импульсов с антидребезгом на прерывания >10000 раз в сек сделать, то разница между C ассемблером уже значительное :) Что конечно не значит, что на ассемблере писаться надо - задачи для ассемблера весьма редкая вещь обычно C всё же за глаза хвататет:)
Более, менее обкатанная - это все неизмеримо. ATMega - тоже заслуженные камни. Про дребезг : с такой частотой (10000) лучше сидеть в основном цикле и считать, а не то вся производительнось уйдет на обработку этого прерывания :) Мои задачи проще по времени - время реакции на события от 0.1 до 1 секунды. Но нужно запускать код на 4 типах платформ и сколько их будет дальше - не понятно. Т.е. желаю минимизировать расходы на портирование
 
+
-
edit
 

Sap

втянувшийся

Sap>> Насчтё чем меньше перефирии - это бабушка на две сказала. По такой логике нет ничего лучше старого доьброго 8051 или даже 8049, что конечно не так :)
Knightmare> Ну иногда это действительно так :)
Sap>> Или явас не правильно понял ? у того ARMа и память и все переферия на кристалле, так что из обвязки только кварц и питание. ATMega вещь не плохая, но со снижением цен на на ARMы смысла в ней всё меньше - при той же цене производительность в разы меньше. На ATMELе уже висят пресс-редлизы о сворачивании линейки MEGA.
Knightmare> Вроде ARMы делают все кому не лень. Не подскажешь ссылку на даташит ARMа у которого есть встроенная флешка ?
Sap>> Температурный диапазон и там и там нормальный, а ядро ARM оно гораздо более обкатаное чем AVR. Про хорошие компиляторы :)))) Да, если у вас там общая логика работы, то компилятор с оптимизирует, а если нужно подсчёт импульсов с антидребезгом на прерывания >10000 раз в сек сделать, то разница между C ассемблером уже значительное :) Что конечно не значит, что на ассемблере писаться надо - задачи для ассемблера весьма редкая вещь обычно C всё же за глаза хвататет:)
Knightmare> Более, менее обкатанная - это все неизмеримо. ATMega - тоже заслуженные камни. Про дребезг : с такой частотой (10000) лучше сидеть в основном цикле и считать, а не то вся производительнось уйдет на обработку этого прерывания :) Мои задачи проще по времени - время реакции на события от 0.1 до 1 секунды. Но нужно запускать код на 4 типах платформ и сколько их будет дальше - не понятно. Т.е. желаю минимизировать расходы на портирование [»]
В основном цикле матиматика с плавающей точкой, протокол обмена и т.п. :)))

 

Kopa

новичок

Форт для AVR имеется на Среда для программирования и внутрисхемной отладки AVR и др

Мне он очень пригодился для создания форта для PDP-11
переработка минимальная для любого контроллера. В качестве примера
мою адаптацию для PDP-11 можно посмотреть на * Главная - [RuFIG] kp (bad link)

При этом возможно и включить эмуляцию контроллера.
Для AVR набросал черновой вариант.
Если интересно пишите, попробую помочь.
 
Это сообщение редактировалось 25.01.2014 в 19:15
BG Реконструктор #29.08.2005 15:15  @Реконструктор#30.07.2005 00:40
+
-
edit
 
Реконструктор>> Люди понаделали уже. И не мало. Но я по прежнему упрямо не воспринимаю форт как полноценный язык, близкий к программисткой логике. [»]
Knightmare> Ссылку, пожалуйста, если видел. Не воспримаешь как полноценный язык близкий к программистской логике ? Ну-ну...Не воспринимаю подобное рассуждение, как полноценное и близкое к программистской логике [»]

Тут. Compiler/Forth
 
RU Ethereal #07.08.2012 14:30  @Knightmare#30.07.2005 00:21
+
-
edit
 

Ethereal

новичок
Knightmare>Естественно, встает вопрос - как реализовывать компилирующие слова и ассемблер (в Forthе я новичок) и вообще, возможно ли такое сделать для этого камня ?

Я успешно реализовал Форт для смарткарты AtMega163+24c256.
З.Ы. У моего камня 16 кило флеш. Много меньше чем у твоего. Форт занял меньше половины этого объема. И ОЗУ меньше. И все работает на ура. Словарь я разместил отдельно в 24с256, чтобы его стирать когда приложение доделано. Код во флеш. Данные в ОЗУ. Шитый код подпрограммный. Компилирующие слова перезаписывают флеш. Все пучком.
 
Это сообщение редактировалось 07.08.2012 в 19:47
RU Ethereal #07.08.2012 14:39  @Balancer#30.07.2005 08:27
+
-
edit
 

Ethereal

новичок
Balancer> Расскажи про разделение кода и данных. Код что, считывать вообще нельзя? Тогда Форт-код придётся хранить в области данных.

Почему нельзя ? У меня в Форте примитив DUMP дампит ОЗУ, [F]DUMP дампит флеш, [E]DUMP дампит внутренний EEPROM, [EE]DUMP дампит внешнюю 24с256. Просто ВСЕ приходится делать в четырех вариантах для разных областей памяти : например иметь пару CREATE DOES> и пару [F]CREATE [F]DOES> , определить четыре вида занесения слова ! [F]! [E]! [EE]! , причем [F]! будет перезаписывать флеш. Нужно только код слов [F]! и [F]C! размешать в области бутлоадера. И тогда перезапись в остальном флеш делается на лету.
 
RU Ethereal #07.08.2012 14:50  @Серокой#30.07.2005 14:27
+
-
edit
 

Ethereal

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

Временный буфер НЕ НУЖЕН ! Хотя стирать/писать приходится страницами по 256 байт, но временный буфер не нужен. Страницу можно переписать из самой себя, подменив при этом только один байт или слово. Хотя из даташита на AtMega это и не очевидно.
 
+
-
edit
 

Ethereal

новичок
Dem_anywhere> 2 Knightmare
Dem_anywhere> На самом деле в форт-программе кода нет - сплошь данные :) Код нужен только для базовых слов.

Это если шитый код прямой, косвенный или свернутый. А вот если он подпрограммный, то код есть. Правда выглядящий как rcall rcall rcall rcall ... но все-таки есть.
 
RU Ethereal #07.08.2012 15:12  @Knightmare#30.07.2005 21:43
+
-
edit
 

Ethereal

новичок
Balancer>>Так вот вопрос - можно ли организовать для такой архитектуры Forth-машину с компилирующими словами и какие будут ограничения ?
Можно. Ограничения - имеешь один процессор, который ты будешь сношать постоянной перезаписью флеш во время написания/отладки. А на готовое устройство ставишь нулевый процессор и твое готовое и отлаженное приложение флеш уже сношать не будет. Вот и все ограничения.

Работать с твоим устройством во время отладки придется через терминальную программу и RS-232. Зато отлаживать будет - одно удовольствие. Потому-что через терминал твоим устройством можно будет управлять как хочешь. Включить то, выключить это, запустить такой-то код, посмотреть что в результате получилось в ОЗУ и регистрах. Нашел ошибку - тут-же убрал старый код по FORGET и докомпилировал исправленный, не трогая всего остального. Интерпретатор, компилятор (скорее перекомпилятор на лету) и отладчик на железе в одном флаконе.

Knightmare> Нужно иметь компилятор внутри камня. Поэтому кросс-компилер не подходит. За ссылку - большое спасибо
Именно это я и сделал. Форт систему внутри камня. На будущее планирую применять ее не только в смарт-картах и сделать ее многозадачной методом Раунд Робин. Но это пока в проекте.
 

Kopa

новичок

Balancer>>>Так вот вопрос - можно ли организовать для такой архитектуры Forth-машину с компилирующими словами и какие будут ограничения ?
amForth не то?

P.S. на fforum.winglion.ru ещё есть разработка кросс компилятора для AVR Очередной AVRForth
и страничка автора oco
 
Это сообщение редактировалось 26.01.2014 в 22:26

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru