Форум РадиоКот

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

GreatDrek писал(а):Просто не удобно что нельзя очистить один байт из сегмента

Если у Вас в программе имеется интенсивная работа с записью во флеш, попробуйте семейство MSP430FRxxx с ферро-магнитной памятью. Там для записи байта/слова в память не надо стирать весь блок и специальной процедуры записи не надо. В С прото операции присваивания с синтаксисом записи в RAM записывают в любое место FRAM. Красота! Не говоря уже о том, что FRAM выдерживает на несколько порядков больше перезаписей чем FLASH. Кстати, любопытно, что последний писк фирмы - модель MSP430FR5969 семейства Wolverine можно заказать на настоящий момент только в России через Compel ! Их серийный выпуск намечен позже в этом году, а пока все остальные страны могут попробовать их через семплы. Я, помню, долго охотился за ними - семплы появляются и их тут-же все растребывают - это не контроллеры а "полный атас". Но в Росии, похоже, ни у кого к ним интереса пока нет, 10 штук через Compel доступны уже несколько месяцев.

GreatDrek - Ваше стремление похвально. Шаг за шагом к реализации игры и придете. Кстати, игру уже выбрали?

GreatDrek - Ваше стремление похвально. Шаг за шагом к реализации игры и придете. Кстати, игру уже выбрали?

Логический платформер с генерацией карты, мало кода надо, мало места занимать будет, ведь еще надо будет написать работу с экраном и т.д.

Я про такую не слышал. Это что-то типа этого?
http://gamer.livejournal.com/388189.html
Как я понял, Вы пока "тренируетесь на кошках", т.к. сдается мне что такая игра не под F2452.

Представим что у нас экран 20 на 20 пикселей(это для удобства объяснения), герой у нас к примеру пиксель которого мы передвигаем вперед, можем прыгать к примеру и т.д.
Так вод есть двадцать пикселей с низу экрана, герой наш на самом деле всегда стоит на месте, то есть по центру экрана, а вот если мы говорим пройти в перед на один шаг в перед ( на один пиксель) то те 20 которые у нас были сдвигаются в лево, остается 19 из двадцати которые были, а новый пиксель который должен появиться может рандомно появиться на разной высоте, к примеру в трех разных пикселях по высоте, это делается в коде так--- к примеру делаем таймер который каждые 100мс обнуляется, по кругу до 100 и снова в 0, делим 100мс на 4, получаем по 25 мс, и говорим что если в тот момент когда вы нажали переместиться таймер был <25 то на высоте 1 появиться пиксель, если >25 && <50 то на высоте 2 пикселя, >50 && <75 3пиксель, ну а >75 && <100 то вообще не создавать пиксель, всю логику до конца я не продумывал так как пока не будет экрана и всего нет смысла придумывать полностью игру, надо работать уже с теми вещами что у меня буду и выжимать из них максимум.
Пиксель это абстрактно, на практике же нарисовать человечка и разнообразней ландшафт и добавить логический элемент, чтото на подобии надо переместить кубики так что бы можно было пройти дальше а не окончательно завалить проход.

Кстати я сейчас под G2553 программирую.

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

Ясно. Я из-за любопытства спросил. Единственная игра, в проект которой я был вовлечен когда-то - эта:
http://mcs.uwsuper.edu/sb/327/Projects/2008/Race/
Может и Вам чего-то попроще выбрать для начала.

Ser60 писал(а):Ясно. Я из-за любопытства спросил. Единственная игра, в проект которой я был вовлечен когда-то - эта:
http://mcs.uwsuper.edu/sb/327/Projects/2008/Race/
Может и Вам чего-то попроще выбрать для начала.

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

Дописал уже после вашего ответа

Тогда удачи! Будут вопросы по 430 - поможем.

Ser60 писал(а):Тогда удачи! Будут вопросы по 430 - поможем.

Спасибо, сейчас разбираю синтаксис IAR, все таки переубедили отбросить Energia

отбросить Energia

И правильно. Energia - для детей и девочек. Хотя сам GCC, который там используется, вполне хорош, его можно прикрутить, например, к Code::Blocks. Но это уже другая история.

Спасибо, сейчас разбираю синтаксис IAR

В IAR нет какого-то совсем особого синтаксиса. Единственно только объявления прерываний:
И еще, переменные, которые должны быть положены как константы во флеш (не то, что Вы там писать в рантайме будете, а безусловные константы; ну там, массивы какие-нибудь типа картинок), объявляются через __ro_placement (стр. 210).

А если Вы, например, хотите, чтобы линкер сразу поместил Вашу структуру, например, с сейвами игры, в нужный сегмент, сделать это можно через #pragma location. Указываете адрес, куда положить, - и все, оно будет там.

Все. Остальное - стандартный ANSI C. Боже упаси Вас писать под МК на C++ и заводить объекты!

Понял, не пытаться делать объектно ориентированное программирование на МК

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

Да, тип float/double тоже не надо использовать там, где нет FPU. Софтовые манипуляции с плавающей точкой страшно все замедляют и раздувают код.

Я понимаю что вопрос тупой Но все же перед окончательным уходом от Energia хочу понять что не так то.
Есть код

static char drek[][1]= {'a','b','c','d','e'};
...
for(int i=0; i<5; ++i){
Flash.write(flash+key, (unsigned char*) drek ,1);
++key;
}
...

Вот если я так пишу то в память записывается abcde

Но если я возьму и приму с uart букву 'c' к примеру, а ее код из

inByte = Serial.read();

равен 99 и напишу в проге

Flash.write(flash+key, (unsigned char*) inByte ,1);

то при чтении я получаю не 99 а 135 вроде и не понятный символ
Мне просто интересно понять почему не правильно записывается информация с uart в память.

В общем если не тяжело будет ответьте пожалуйста.

почему не правильно записывается информация с uart в память.

UART не при чем, это магия указателей.
Здесь drek - указатель на начало массива. И потому когда мы его разыменовываем, например - (unsigned char *)drek[0], мы получаем элемент по нулевому смещению от указателя на массив байт, то есть 'а'.

Во втором случае
inByte - ЧИСЛО. И запись (unsigned char *)inByte заставляет интерпретировать его, как указатель. Т.е., здесь
в память пишется то число, которое находится по адресу, равному значению inByte, но не in Byte.

Правильно было бы

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

Если функции write() нужен поинтер на char, попробуйте так:

перед записью в ячейку значение надо перевести в char

Э, а какого типа inByte изначально?

Если функции write() нужен поинтер на char

Похоже все же не поинтер, а само число, ибо там идет обращение к элементу массива:
Разыменовываем указатель, получаем значение.

inByte у меня типа Byte, но я делал его и типа char и типа unsigned char толку ноль, unsigned я так понял из типа убирает все возможные результаты с минусом, тоесть если байт значения от -128 до 127 то unsigned byte будет от 0 до 255, в общем все то что выписали не помагает я все перепробывал уже, я еще делал так,

char test[][1]={};
...
test[1]=inByte;
...
Flash.write(flash+key, (unsigned char*) test[1] ,1);
...

и толку ноль.
В общем не понятно.

char test[][1]={};

В чем смысл такой записи? Почему не char test[1]={} ?

test[1]=inByte;

Ошибка. Элемента с номером 1 в массиве с одним элементом нет. Нумерация начинается с нуля.

Правильно:
А вообще - нафига нужен массив из одного элемента?