-
По поводу реализации Forth на AVR
Тэги: компьютеры, программирование
Knightmare 
Программирую для камня ATMega128 на C++. Естественно, через какое-то время встал вопрос об эффективном расходе ресурсов. На камне 128K памяти для программ, 4K RAM и 4K - EEPROM.
В погоне за эффективностью наткулся на Forth. О чудо ! такой маленький и такой эффективный. В общем, мне он понравился и я загорелся реализовать Forth на этот камень и прямо в этот камень затолкать компилятор ! НО, есть следующие проблемы: гарвардовская архитектура, (т.е. данные и код - раздельно) и память для программ ограничена на количестов перезаписей - всего 1000 раз и к тому же писать можно только страницами (256 байт). Естественно, встает вопрос - как реализовывать компилирующие слова и ассемблер (в Forthе я новичок) и вообще, возможно ли такое сделать для этого камня ?
В погоне за эффективностью наткулся на Forth. О чудо ! такой маленький и такой эффективный. В общем, мне он понравился и я загорелся реализовать Forth на этот камень и прямо в этот камень затолкать компилятор ! НО, есть следующие проблемы: гарвардовская архитектура, (т.е. данные и код - раздельно) и память для программ ограничена на количестов перезаписей - всего 1000 раз и к тому же писать можно только страницами (256 байт). Естественно, встает вопрос - как реализовывать компилирующие слова и ассемблер (в Forthе я новичок) и вообще, возможно ли такое сделать для этого камня ?
инструменты
Реконструктор
Люди понаделали уже. И не мало. Но я по прежнему упрямо не воспринимаю форт как полноценный язык, близкий к программисткой логике.
На нас глядят в бинокли, в трубы сотни глаз
И видят нас от дыма злых и серых,
Но никогда им не увидеть нас
Прикованными к веслам на галерах!
И видят нас от дыма злых и серых,
Но никогда им не увидеть нас
Прикованными к веслам на галерах!
Реконструктор> Люди понаделали уже. И не мало. Но я по прежнему упрямо не воспринимаю форт как полноценный язык, близкий к программисткой логике. 579080»»»
Ссылку, пожалуйста, если видел. Не воспримаешь как полноценный язык близкий к программистской логике ? Ну-ну...Не воспринимаю подобное рассуждение, как полноценное и близкое к программистской логике
Ссылку, пожалуйста, если видел. Не воспримаешь как полноценный язык близкий к программистской логике ? Ну-ну...Не воспринимаю подобное рассуждение, как полноценное и близкое к программистской логике
Это сообщение редактировалось 30.07.2005 в 13:39
Knightmare> Программирую для камня ATMega128 на C++. Естественно, через какое-то время встал вопрос об эффективном расходе ресурсов. На камне 128K памяти для программ, 4K RAM и 4K - EEPROM.
Knightmare> В погоне за эффективностью наткулся на Forth. О чудо ! такой маленький и такой эффективный. В общем, мне он понравился и я загорелся реализовать Forth на этот камень и прямо в этот камень затолкать компилятор ! НО, есть следующие проблемы: гарвардовская архитектура, (т.е. данные и код - раздельно) и память для программ ограничена на количестов перезаписей - всего 1000 раз и к тому же писать можно только страницами (256 байт). Естественно, встает вопрос - как реализовывать компилирующие слова и ассемблер (в Forthе я новичок) и вообще, возможно ли такое сделать для этого камня ? 579075»»»
Расскажи про разделение кода и данных. Код что, считывать вообще нельзя? Тогда Форт-код придётся хранить в области данных. Но соотношение код/данные 128/4 будет в таком случае категорически не в пользу Форта :-/
Knightmare> В погоне за эффективностью наткулся на Forth. О чудо ! такой маленький и такой эффективный. В общем, мне он понравился и я загорелся реализовать Forth на этот камень и прямо в этот камень затолкать компилятор ! НО, есть следующие проблемы: гарвардовская архитектура, (т.е. данные и код - раздельно) и память для программ ограничена на количестов перезаписей - всего 1000 раз и к тому же писать можно только страницами (256 байт). Естественно, встает вопрос - как реализовывать компилирующие слова и ассемблер (в Forthе я новичок) и вообще, возможно ли такое сделать для этого камня ? 579075»»»
Расскажи про разделение кода и данных. Код что, считывать вообще нельзя? Тогда Форт-код придётся хранить в области данных. Но соотношение код/данные 128/4 будет в таком случае категорически не в пользу Форта :-/
... чтобы понять рекурсию, нужно сперва понять рекурсию ...
Balancer> Расскажи про разделение кода и данных. Код что, считывать вообще нельзя? Тогда Форт-код придётся хранить в области данных. Но соотношение код/данные 128/4 будет в таком случае категорически не в пользу Форта :-/ 579136»»»
Код считывать, конечно можно. Дело в том, что код и данные лежат в разных адресных пространствах. Даже инструкции для считывания и записи для этих пространств - разные, т.е. единого указателя в данной архитектуре нет и камень принципиально не может выполнять инструкции из пространства данных. Хочешь исполнить код - нужно записать его в область кода, и никак по другому. Все это не тяжелые ограничения, а вот ИМХО настоящие "вилы" - то что записывать в пространство кода можно только по страницам (256 байт) и количество перезаписей равно 1000. Так вот вопрос - можно ли организовать для такой архитектуры Forth-машину с компилирующими словами и какие будут ограничения ?
Код считывать, конечно можно. Дело в том, что код и данные лежат в разных адресных пространствах. Даже инструкции для считывания и записи для этих пространств - разные, т.е. единого указателя в данной архитектуре нет и камень принципиально не может выполнять инструкции из пространства данных. Хочешь исполнить код - нужно записать его в область кода, и никак по другому. Все это не тяжелые ограничения, а вот ИМХО настоящие "вилы" - то что записывать в пространство кода можно только по страницам (256 байт) и количество перезаписей равно 1000. Так вот вопрос - можно ли организовать для такой архитектуры Forth-машину с компилирующими словами и какие будут ограничения ?
Knightmare> ИМХО настоящие "вилы" - то что записывать в пространство кода можно только по страницам (256 байт) и количество перезаписей равно 1000. 579168»»»
Записывать-то можно по словам, а уж потом скидывать временный буфер в память. Другое дело, что данные недоступны будут, пока не скинутся. Механизм самостоятельного программирования памяти предназначен для обновления прошивки, хранения массивов данных, но никак не для постоянного хранения и обновления данных, то есть нельзя с фон-неймановскими подходами, надо наоборот Форт под гарвардскую архитекутру докручивать.
В общем, я не понимаю, зачем именно так делать - сливать страницу во временный буфер, модифицировать данные, стирать страницу и снова заливать, тем более на не предназначенной для этого архитектуре.
А вообще, практика показывает, что 1000 перезаписей- не предел, флэш данных живёт и дольше. Негарантированно, конечно ж.
Записывать-то можно по словам, а уж потом скидывать временный буфер в память. Другое дело, что данные недоступны будут, пока не скинутся. Механизм самостоятельного программирования памяти предназначен для обновления прошивки, хранения массивов данных, но никак не для постоянного хранения и обновления данных, то есть нельзя с фон-неймановскими подходами, надо наоборот Форт под гарвардскую архитекутру докручивать.
В общем, я не понимаю, зачем именно так делать - сливать страницу во временный буфер, модифицировать данные, стирать страницу и снова заливать, тем более на не предназначенной для этого архитектуре.
А вообще, практика показывает, что 1000 перезаписей- не предел, флэш данных живёт и дольше. Негарантированно, конечно ж.
Больше не раскалятся ваши колосники. Мамонты пятилеток сбили свои клыки. ©
>> Так вот вопрос - можно ли организовать для такой архитектуры Forth-машину с компилирующими словами и какие будут ограничения ?
А почему кросс-компилер не подходит?
Andrew Sterian
А почему кросс-компилер не подходит?
Andrew Sterian
Knightmare>На камне 128K памяти для программ, 4K RAM и 4K - EEPROM
Если нехватает и того, и другого и третьего - лучше ищи другой процессор. Обычно нехватает ОЗУ, а это лечится прикручиванием к ATMega внешней SRAM -- до 64Кбайт.
ЗЫ. Flash в ATMega-ах гарантировано перезаписывается минимум 10000 раз (по даташиту), ЕМНИП.
Если нехватает и того, и другого и третьего - лучше ищи другой процессор. Обычно нехватает ОЗУ, а это лечится прикручиванием к ATMega внешней SRAM -- до 64Кбайт.
ЗЫ. Flash в ATMega-ах гарантировано перезаписывается минимум 10000 раз (по даташиту), ЕМНИП.
Knightmare>>На камне 128K памяти для программ, 4K RAM и 4K - EEPROM
A.P.> Если нехватает и того, и другого и третьего - лучше ищи другой процессор. Обычно нехватает ОЗУ, а это лечится прикручиванием к ATMega внешней SRAM -- до 64Кбайт.
И другие процессора есть
Но интересно именно для этого камня, уж больно он хорош по рабочим характеристикам, да и недорогой. По поводу внешней памяти - всеравно код записанный в нее нельзя будет исполнить. 
A.P.> ЗЫ. Flash в ATMega-ах гарантировано перезаписывается минимум 10000 раз (по даташиту), ЕМНИП. 579235»»»
И в правду 10 000 раз, спасибо (просто помню - что для программирования через загрузчик - хватает, а для рабочих нужд программы - изотрется быстро) B) . Но всеравно - при добавлении нового слова в словарь перезаписывать целую страницу - роскошь.
A.P.> Если нехватает и того, и другого и третьего - лучше ищи другой процессор. Обычно нехватает ОЗУ, а это лечится прикручиванием к ATMega внешней SRAM -- до 64Кбайт.
И другие процессора есть
Но интересно именно для этого камня, уж больно он хорош по рабочим характеристикам, да и недорогой. По поводу внешней памяти - всеравно код записанный в нее нельзя будет исполнить. A.P.> ЗЫ. Flash в ATMega-ах гарантировано перезаписывается минимум 10000 раз (по даташиту), ЕМНИП. 579235»»»
И в правду 10 000 раз, спасибо (просто помню - что для программирования через загрузчик - хватает, а для рабочих нужд программы - изотрется быстро) B) . Но всеравно - при добавлении нового слова в словарь перезаписывать целую страницу - роскошь.
Это сообщение редактировалось 30.07.2005 в 22:04
>>> Так вот вопрос - можно ли организовать для такой архитектуры Forth-машину с компилирующими словами и какие будут ограничения ?
61284> А почему кросс-компилер не подходит?
61284> Andrew Sterian 579234»»»
Нужно иметь компилятор внутри камня. Поэтому кросс-компилер не подходит. За ссылку - большое спасибо
61284> А почему кросс-компилер не подходит?
61284> Andrew Sterian 579234»»»
Нужно иметь компилятор внутри камня. Поэтому кросс-компилер не подходит. За ссылку - большое спасибо
2 Knightmare
На самом деле в форт-программе кода нет - сплошь данные Код нужен только для базовых слов.
И вообще, можешь сделать один из битов адреса слова флагом, указывающим в какой памяти надо работать
На самом деле в форт-программе кода нет - сплошь данные
Код нужен только для базовых слов.И вообще, можешь сделать один из битов адреса слова флагом, указывающим в какой памяти надо работать
Больше всего мешают развитию те, кто в нем остановился...
Knightmare>>>На камне 128K памяти для программ, 4K RAM и 4K - EEPROM
A.P.>> Если нехватает и того, и другого и третьего - лучше ищи другой процессор. Обычно нехватает ОЗУ, а это лечится прикручиванием к ATMega внешней SRAM -- до 64Кбайт.
Knightmare> И другие процессора есть Но интересно именно для этого камня, уж больно он хорош по рабочим характеристикам, да и недорогой. По поводу внешней памяти - всеравно код записанный в нее нельзя будет исполнить.
579247»»»
Угу, посмотри AT91SAM32 - кажется так стоит чуть дороже, но это уже настоящий 16/32 бит ARM7 (55 MIPS @ 50 МГц) со всеми своими наворотами плюс программирование через UART. )) И пиши себе на C++ ))
Хотя если честно то это изврат какой-то - для контроллеорв такие языки использовать - не эффективно получается. ЧТо C++, что форт очень и очень не фээективны на данной архитектруре, а уж если учесть какие задачи обычно приходится решать так и вообще не ясно ЗАЧЕМ ВСЁ ЭТО ТУТ ?!
A.P.>> Если нехватает и того, и другого и третьего - лучше ищи другой процессор. Обычно нехватает ОЗУ, а это лечится прикручиванием к ATMega внешней SRAM -- до 64Кбайт.
Knightmare> И другие процессора есть
Но интересно именно для этого камня, уж больно он хорош по рабочим характеристикам, да и недорогой. По поводу внешней памяти - всеравно код записанный в нее нельзя будет исполнить. 579247»»»
Угу, посмотри AT91SAM32 - кажется так
стоит чуть дороже, но это уже настоящий 16/32 бит ARM7 (55 MIPS @ 50 МГц) со всеми своими наворотами плюс программирование через UART. )) И пиши себе на C++ ))Хотя если честно то это изврат какой-то - для контроллеорв такие языки использовать - не эффективно получается. ЧТо C++, что форт очень и очень не фээективны на данной архитектруре, а уж если учесть какие задачи обычно приходится решать так и вообще не ясно ЗАЧЕМ ВСЁ ЭТО ТУТ ?!
Sap> Угу, посмотри AT91SAM32 - кажется так стоит чуть дороже, но это уже настоящий 16/32 бит ARM7 (55 MIPS @ 50 МГц) со всеми своими наворотами плюс программирование через UART. )) И пиши себе на C++ ))
Sap> Хотя если честно то это изврат какой-то - для контроллеорв такие языки использовать - не эффективно получается. ЧТо C++, что форт очень и очень не фээективны на данной архитектруре, а уж если учесть какие задачи обычно приходится решать так и вообще не ясно ЗАЧЕМ ВСЁ ЭТО ТУТ ?! 579715»»»
Хех. Если бы дело было только в наворотах. А нужна еще надежность и пригодность для полевых условий , т.е. читай: чем меньше всякой периферии в устройстве - тем оно кошерней. Идеальный случай: камень, питание и развязки для входов/выходов. ATMega приближается к идеальному варианту.
По поводу C++ - не хочу я на нем писать, портабельность требует усилий. И по поводу языков - компиляторы сейчас хорошие делают. Нет особого смысла писать на ассемблере. Ну разве что из любви к искусству, чтобы применить "особые приемы". А вот во времени - запросто можно раз этак в 5 больше потратить. Ну и про переносимость можно забыть, конечно.
стоит чуть дороже, но это уже настоящий 16/32 бит ARM7 (55 MIPS @ 50 МГц) со всеми своими наворотами плюс программирование через UART. )) И пиши себе на C++ ))Sap> Хотя если честно то это изврат какой-то - для контроллеорв такие языки использовать - не эффективно получается. ЧТо C++, что форт очень и очень не фээективны на данной архитектруре, а уж если учесть какие задачи обычно приходится решать так и вообще не ясно ЗАЧЕМ ВСЁ ЭТО ТУТ ?! 579715»»»
Хех. Если бы дело было только в наворотах. А нужна еще надежность и пригодность для полевых условий , т.е. читай: чем меньше всякой периферии в устройстве - тем оно кошерней. Идеальный случай: камень, питание и развязки для входов/выходов. ATMega приближается к идеальному варианту.
По поводу C++ - не хочу я на нем писать, портабельность требует усилий. И по поводу языков - компиляторы сейчас хорошие делают. Нет особого смысла писать на ассемблере. Ну разве что из любви к искусству, чтобы применить "особые приемы". А вот во времени - запросто можно раз этак в 5 больше потратить. Ну и про переносимость можно забыть, конечно.
Это сообщение редактировалось 01.08.2005 в 21:05
Sap>> Угу, посмотри AT91SAM32 - кажется так стоит чуть дороже, но это уже настоящий 16/32 бит ARM7 (55 MIPS @ 50 МГц) со всеми своими наворотами плюс программирование через UART. )) И пиши себе на C++ ))
Sap>> Хотя если честно то это изврат какой-то - для контроллеорв такие языки использовать - не эффективно получается. ЧТо C++, что форт очень и очень не фээективны на данной архитектруре, а уж если учесть какие задачи обычно приходится решать так и вообще не ясно ЗАЧЕМ ВСЁ ЭТО ТУТ ?! 579715»»»
Knightmare> Хех. Если бы дело было только в наворотах. А нужна еще надежность и пригодность для полевых условий , т.е. читай: чем меньше всякой периферии в устройстве - тем оно кошерней. Идеальный случай: камень, питание и развязки для входов/выходов. ATMega приближается к идеальному варианту.
Knightmare> По поводу C++ - не хочу я на нем писать, портабельность требует усилий. И по поводу языков - компиляторы сейчас хорошие делают. Нет особого смысла писать на ассемблере. Ну разве что из любви к искусству, чтобы применить "особые приемы". А вот во времени - запросто можно раз этак в 5 больше потратить. Ну и про переносимость можно забыть, конечно. 579751»»»
Насчтё чем меньше перефирии - это бабушка на две сказала. По такой логике нет ничего лучше старого доьброго 8051 или даже 8049, что конечно не так
Или явас не правильно понял ? у того ARMа и память и все переферия на кристалле, так что из обвязки только кварц и питание. ATMega вещь не плохая, но со снижением цен на на ARMы смысла в ней всё меньше - при той же цене производительность в разы меньше. На ATMELе уже висят пресс-редлизы о сворачивании линейки MEGA.
Температурный диапазон и там и там нормальный, а ядро ARM оно гораздо более обкатаное чем AVR. Про хорошие компиляторы))) Да, если у вас там общая логика работы, то компилятор с оптимизирует, а если нужно подсчёт импульсов с антидребезгом на прерывания >10000 раз в сек сделать, то разница между C ассемблером уже значительное Что конечно не значит, что на ассемблере писаться надо - задачи для ассемблера весьма редкая вещь обычно C всё же за глаза хвататет:)
стоит чуть дороже, но это уже настоящий 16/32 бит ARM7 (55 MIPS @ 50 МГц) со всеми своими наворотами плюс программирование через UART. )) И пиши себе на C++ ))Sap>> Хотя если честно то это изврат какой-то - для контроллеорв такие языки использовать - не эффективно получается. ЧТо C++, что форт очень и очень не фээективны на данной архитектруре, а уж если учесть какие задачи обычно приходится решать так и вообще не ясно ЗАЧЕМ ВСЁ ЭТО ТУТ ?! 579715»»»
Knightmare> Хех. Если бы дело было только в наворотах. А нужна еще надежность и пригодность для полевых условий , т.е. читай: чем меньше всякой периферии в устройстве - тем оно кошерней. Идеальный случай: камень, питание и развязки для входов/выходов. ATMega приближается к идеальному варианту.
Knightmare> По поводу C++ - не хочу я на нем писать, портабельность требует усилий. И по поводу языков - компиляторы сейчас хорошие делают. Нет особого смысла писать на ассемблере. Ну разве что из любви к искусству, чтобы применить "особые приемы". А вот во времени - запросто можно раз этак в 5 больше потратить. Ну и про переносимость можно забыть, конечно. 579751»»»
Насчтё чем меньше перефирии - это бабушка на две сказала. По такой логике нет ничего лучше старого доьброго 8051 или даже 8049, что конечно не так
Или явас не правильно понял ? у того ARMа и память и все переферия на кристалле, так что из обвязки только кварц и питание. ATMega вещь не плохая, но со снижением цен на на ARMы смысла в ней всё меньше - при той же цене производительность в разы меньше. На ATMELе уже висят пресс-редлизы о сворачивании линейки MEGA.
Температурный диапазон и там и там нормальный, а ядро ARM оно гораздо более обкатаное чем AVR. Про хорошие компиляторы
))) Да, если у вас там общая логика работы, то компилятор с оптимизирует, а если нужно подсчёт импульсов с антидребезгом на прерывания >10000 раз в сек сделать, то разница между C ассемблером уже значительное Что конечно не значит, что на ассемблере писаться надо - задачи для ассемблера весьма редкая вещь обычно C всё же за глаза хвататет:)
Sap> Насчтё чем меньше перефирии - это бабушка на две сказала. По такой логике нет ничего лучше старого доьброго 8051 или даже 8049, что конечно не так
Ну иногда это действительно так
Sap> Или явас не правильно понял ? у того ARMа и память и все переферия на кристалле, так что из обвязки только кварц и питание. ATMega вещь не плохая, но со снижением цен на на ARMы смысла в ней всё меньше - при той же цене производительность в разы меньше. На ATMELе уже висят пресс-редлизы о сворачивании линейки MEGA.
Вроде ARMы делают все кому не лень. Не подскажешь ссылку на даташит ARMа у которого есть встроенная флешка ?
Sap> Температурный диапазон и там и там нормальный, а ядро ARM оно гораздо более обкатаное чем AVR. Про хорошие компиляторы))) Да, если у вас там общая логика работы, то компилятор с оптимизирует, а если нужно подсчёт импульсов с антидребезгом на прерывания >10000 раз в сек сделать, то разница между C ассемблером уже значительное Что конечно не значит, что на ассемблере писаться надо - задачи для ассемблера весьма редкая вещь обычно C всё же за глаза хвататет:)
Более, менее обкатанная - это все неизмеримо. ATMega - тоже заслуженные камни. Про дребезг : с такой частотой (10000) лучше сидеть в основном цикле и считать, а не то вся производительнось уйдет на обработку этого прерывания Мои задачи проще по времени - время реакции на события от 0.1 до 1 секунды. Но нужно запускать код на 4 типах платформ и сколько их будет дальше - не понятно. Т.е. желаю минимизировать расходы на портирование
Ну иногда это действительно так
Sap> Или явас не правильно понял ? у того ARMа и память и все переферия на кристалле, так что из обвязки только кварц и питание. ATMega вещь не плохая, но со снижением цен на на ARMы смысла в ней всё меньше - при той же цене производительность в разы меньше. На ATMELе уже висят пресс-редлизы о сворачивании линейки MEGA.
Вроде ARMы делают все кому не лень. Не подскажешь ссылку на даташит ARMа у которого есть встроенная флешка ?
Sap> Температурный диапазон и там и там нормальный, а ядро ARM оно гораздо более обкатаное чем AVR. Про хорошие компиляторы
))) Да, если у вас там общая логика работы, то компилятор с оптимизирует, а если нужно подсчёт импульсов с антидребезгом на прерывания >10000 раз в сек сделать, то разница между C ассемблером уже значительное Что конечно не значит, что на ассемблере писаться надо - задачи для ассемблера весьма редкая вещь обычно C всё же за глаза хвататет:) Более, менее обкатанная - это все неизмеримо. ATMega - тоже заслуженные камни. Про дребезг : с такой частотой (10000) лучше сидеть в основном цикле и считать, а не то вся производительнось уйдет на обработку этого прерывания
Мои задачи проще по времени - время реакции на события от 0.1 до 1 секунды. Но нужно запускать код на 4 типах платформ и сколько их будет дальше - не понятно. Т.е. желаю минимизировать расходы на портирование
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 типах платформ и сколько их будет дальше - не понятно. Т.е. желаю минимизировать расходы на портирование 580267»»»
В основном цикле матиматика с плавающей точкой, протокол обмена и т.п.))
Knightmare> Ну иногда это действительно так
Sap>> Или явас не правильно понял ? у того ARMа и память и все переферия на кристалле, так что из обвязки только кварц и питание. ATMega вещь не плохая, но со снижением цен на на ARMы смысла в ней всё меньше - при той же цене производительность в разы меньше. На ATMELе уже висят пресс-редлизы о сворачивании линейки MEGA.
Knightmare> Вроде ARMы делают все кому не лень. Не подскажешь ссылку на даташит ARMа у которого есть встроенная флешка ?
Sap>> Температурный диапазон и там и там нормальный, а ядро ARM оно гораздо более обкатаное чем AVR. Про хорошие компиляторы
))) Да, если у вас там общая логика работы, то компилятор с оптимизирует, а если нужно подсчёт импульсов с антидребезгом на прерывания >10000 раз в сек сделать, то разница между C ассемблером уже значительное Что конечно не значит, что на ассемблере писаться надо - задачи для ассемблера весьма редкая вещь обычно C всё же за глаза хвататет:) Knightmare> Более, менее обкатанная - это все неизмеримо. ATMega - тоже заслуженные камни. Про дребезг : с такой частотой (10000) лучше сидеть в основном цикле и считать, а не то вся производительнось уйдет на обработку этого прерывания
Мои задачи проще по времени - время реакции на события от 0.1 до 1 секунды. Но нужно запускать код на 4 типах платформ и сколько их будет дальше - не понятно. Т.е. желаю минимизировать расходы на портирование 580267»»»В основном цикле матиматика с плавающей точкой, протокол обмена и т.п.
))
Форт для AVR имеется на http://www.tinyboot.com/ff302.zip
Мне он очень пригодился для создания форта для PDP-11
переработка минимальная для любого контроллера. В качестве примера
мою адаптацию для PDP-11 можно посмотреть на Программирование для контроллеров на процессорах PDP-11 ( 8051, AVR, Motorolla ColdFire
При этом возможно и включить эмуляцию контроллера.
Для AVR набросал черновой вариант.
Если интересно пишите, попробую помочь.
Мне он очень пригодился для создания форта для PDP-11
переработка минимальная для любого контроллера. В качестве примера
мою адаптацию для PDP-11 можно посмотреть на Программирование для контроллеров на процессорах PDP-11 ( 8051, AVR, Motorolla ColdFire
При этом возможно и включить эмуляцию контроллера.
Для AVR набросал черновой вариант.
Если интересно пишите, попробую помочь.
Реконструктор>> Люди понаделали уже. И не мало. Но я по прежнему упрямо не воспринимаю форт как полноценный язык, близкий к программисткой логике. 579080»»»
Knightmare> Ссылку, пожалуйста, если видел. Не воспримаешь как полноценный язык близкий к программистской логике ? Ну-ну...Не воспринимаю подобное рассуждение, как полноценное и близкое к программистской логике 579091»»»
Тут. Compiler/Forth
Knightmare> Ссылку, пожалуйста, если видел. Не воспримаешь как полноценный язык близкий к программистской логике ? Ну-ну...Не воспринимаю подобное рассуждение, как полноценное и близкое к программистской логике 579091»»»
Тут. Compiler/Forth
На нас глядят в бинокли, в трубы сотни глаз
И видят нас от дыма злых и серых,
Но никогда им не увидеть нас
Прикованными к веслам на галерах!
И видят нас от дыма злых и серых,
Но никогда им не увидеть нас
Прикованными к веслам на галерах!
Copyright © Balancer 1997..2010
Создано 30.07.2005
Создано 30.07.2005
- Поиск
- Настройки
- Персональное
- Новости сайта
- Популярные темы
- География форума
-
Сайт работает на сервере ETegro Technologies