Ещё один программный таймер

Решил тоже поучаствовать в конкурсе «у кого таймер проще» :)
Это даже не велосипед, а так, самокат :)

Времени расписывать особо нет, поэтому буду краток.
Да и пояснять особо нечего.
typedef enum eTimerStatus
{
	etsTimerIDLE = 0,
	etsTimerCount,
	etsTimerEvent
} eTimerStatus;

typedef struct stTimer
{
	volatile ShortTimer *Count;
	volatile eTimerStatus Status;
} stTimer;

Это базовые определения. Теперь функционал:

#include "Timers.h"

/**
*	\brief Пул таймеров
*/
static ShortTimer volatile TimersPool[eTimersNumber];
static eTimerStatus volatile TimersStatusPool[eTimersNumber];

void TickTimers()
{
	for(int i=0; i < eTimersNumber; i++)
	{
		if(TimersPool[i] > 0)
		{
			TimersPool[i] --;
			if(0 == TimersPool[i])
			{
				TimersStatusPool[i] = etsTimerEvent;
			}
		}
	}
}

void StartTimer(eTimerIndex timer, ShortTimer period_ms)
{
	TimersPool[timer] = period_ms;
	TimersStatusPool[timer] = etsTimerCount;
}

eTimerStatus GetTimerStatus(eTimerIndex timer)
{
	if(etsTimerEvent == TimersStatusPool[timer])
	{
		TimersStatusPool[timer] = etsTimerIDLE;
		return(etsTimerEvent);		
	}
	else
	{
		return(TimersStatusPool[timer]);
	}
}

ShortTimer GetTimerCount(eTimerIndex timer){
	return(TimersPool[timer]);
}


Ну и пример использования.
typedef unsigned int ShortTimer;

typedef enum eTimerIndex
{
	eADC1Timer = 0,
	eADC2Timer,
	eADC3Timer,
	eADCProcessTimer,
	eChanDiapSwitchDelayTimer,
	eModbusTimer,
	eTimersNumber
} eTimerIndex;

void SysTick_Handler(void){

	TickTimers();
}

void main(){
    ...
    StartTimer(eADCProcessTimer, 5);

    while (1){
	...
	if(etsTimerEvent == GetTimerStatus(eADCProcessTimer)){
	    ProcessADC();
	    StartTimer(eADCProcessTimer, 5);
	}
        ...
    }
}


Если что непонятно (что вряд ли), спрашивайте, добавлю.
Главное удобство в простоте использования. Нужен ещё один таймер — добавили имя в enum eTimerIndex и можно пользоваться.

PS: Сейчас глянул ещё раз — а зачем мне вообще stTimer? Наверно, изначально что-то другое задумывал. Ну да ладно.

Игра на миллион

Ничего не буду от себя добавлять, читаем, смотрим, вносим посильный вклад.
А вдруг новые панфиловцы получатся. Или русский Wargaming :)



Оторвитесь ненадолго от беспощадного ЛУТа!
Две недели решат судьбу проекта.

PS:
Таки добавлю дескрипшн.
А то, похоже, многие осуждают, не читая.
Каждый из нас задумывался, как сложилась бы судьба нашей страны, если бы Александр Невский не победил на Чудском озере, или если бы большевики не пришли к власти. Как бы мы жили, если бы Горбачев не развалил СССР, или если майдан в Киеве был бы предотвращен. Теперь у вас есть реальный шанс узнать это! В нашей новой игре каждый от мала до велика сможет примерить на себя роль Верховного Правителя, лично управлять Россией, и повлиять на её историю и исход всех значительных исторических событий на протяжении столетий. Я предлагаю вам вместе сделать эту хорошую и полезную игру.

Наша игра построена на принятии решений. В самом начале игроку нужно выбрать кампанию: период в истории России и соответствующего ему правителя. Вместе с властью на игрока сваливаются и проблемы – будь то война или революция, тяжелое внешнеполитическое положение или внутренние проблемы в стране. Для решения проблем у игрока в распоряжении будут иметься различные ресурсы – военный, экономический, социальный и так далее. Помогать в решении сложных вопросов игроку будут советники – генералы, министры и прочие значимые исторические фигуры.

В ходе игры, будут происходить исторические события, на которые игрок должен отреагировать — принять то или иное решение. В зависимости от наличия ресурсов, лояльности советников и многих других факторов (в том числе и от предыдущих решений!) у игрока будет набор вариантов того, что он может сделать.

Простых решений в «Империи» не будет

PGA своими руками

Сколько раз ни пытался применить готовые PGA (усилитель с программируемым Ку), ни разу не мог подобрать подходящий. Либо сетка коэффициентов не устраивает, либо (в основном) высокая цена, а часто особенности схемотехники. В результате пришлось изобрести свой.

Казалось бы, чего проще — операционник и коммутатор в цепи ОС, переключающий резисторы нужных номиналов.
Типа:


Как известно, Ку такого усилителя будет определяться соотношением Ку = R2..R5 / R1, выбор задается по адресным входам А0, А1. Вроде все ничего, но есть одно но. Как правило, КМОП-ключи имеют некоторое внутреннее сопротивление, и оно редко меньше 1 Ом, а может достигать и десятков. При этом однозначно нормировать его нельзя, т.к. этот параметр может изменяться как от экземпляра к экземпляру, так и от внешних условий — температуры, амплитуды сигнала и т.д.

Чем это грозит? Тем, что сопротивление ключа вносится в Rос и изменяет Ку. Если требования к точности невысокие и ключ достаточно низкоомный, можно пренебречь внутренним сопротивлением или взять типовое значение из даташита. Однако, если речь идет о прецизионных измерениях, закрывать на это глаза уже нельзя.

Что же делать? Нужно попытаться вынести добавку «за скобки». К счастью, нам повезло :) и коммутатор оказался двухсекционным. Легким движением руки…

… получаем усилитель, не зависящий от капризов природы.

Что произошло? Теперь при подключении любого из резисторов обратной связи мы берем выходное напряжение не с выхода операционника, где оно содержит добавку, обусловленную падением на ключе, а непосредственно с Rос, которое в точности определяется первоначальной формулой, ибо входной ток через R1 уравновешивается выходным через Rос, и напряжение на Rос зависит только от соотношения резисторов. Добавка, обусловленная дополнительным сопротивлением ключа коммутатора, на нем же и осталась.

Эту схему я придумал сам, некоторое время ощущая себя в определенном смысле гением :) пока не наткнулся на описание схемотехники китайского RLC-метра, который срисовали со старинного agilent. Ну и там увидел свой «велосипед». То есть, это вполне стандартный трюк, которым я с удовольствием и делюсь с уважаемым сообществом.

Дополнительный бонус обнаружился при разводке данной конкретной схемы. Кто попробует, поймет, о чем я :)

Спасибо за внимание, успехов в творчестве.

Не так страшен makefile

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

Итак, makefile — сценарий сборки для процедуры GNU make, являющейся неотъемлемой частью любого GCC-тулчейна.

Я мог бы цитировать главы из документации по GNU make или пересказать своими словами замечательную статью Владимира Игнатова, однако не хочу да и не вижу особого смысла, ибо все это любой заинтересованный читатель может изучить самостоятельно. Вместо этого я по пунктам разберу мой рабочий makefile, который с небольшими вариациями служит мне верой и правдой около 5 лет во многих проектах.

Поехали.


Читать дальше

4E4th + TI LaunchPad. В начале было Слово.

После нескольких экспериментов и вводных слов (раз, два) пора переходить к рассмотрению внутренних механизмов нашей учебной форт-системы 4e4th. Иначе, как мне кажется, народу скоро наскучит зажигать светодиоды из терминала и забавляться вывернутой наизнанку логикой стековой машины.

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

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

Это именно то, чего лично мне не хватило несколько лет назад, чтобы вплотную заняться заинтересовавшей меня темой фортостроения, ну и отсутствие на тот момент готового рабочего образа системы под конкретное имеющееся железо.

Таким образом, сегодня рассмотрим строение основополагающего компонента любой forth-системы — слова.



Читать дальше

4E4th + TI LaunchPad. Основы языка Forth

В прошлый раз я представил общественности учебное компактное ядро forth, целиком размещаемое в 8 из 16 кБ флеш памяти MSP430G2553 и полноценно функционирующее, несмотря на смешные по нынешним временам 512 байт ОЗУ, в которых разместился буфер вводимых через UART команд, два стека (данных и возвратов) и пользовательский словарь, в который складываются вновь скомпилированные слова.

Дополнительные возможности (по сравнению с прототипом — CamelForth) дает слово save, которое сохраняет новые слова, введенные пользователем, в флеш память, освобождая ОЗУ.
(На самом деле это слово делает что-то другое, пока точно не разобрался. А слова изначально сохраняются в пользовательскую половину флеш памяти.)

Так как был высказан интерес к теме, продолжим изучение основ фортостроения вообще и особенности конкретной реализации 4E4th.


Читать дальше

Виртуальная машина и скриптовой движок в MSP430G2553 - проще пареной репы. 4e4th + TI Launchpad

Вот и дождался я своего launchpad'a!
Жажда халявы и широкий пеар в узких кругах сделали свое черное дело :)
Ну да ладно, пора к делу.

Итак,

постановка задачи

Дано:
непонятная красненькая плата со штырьками PLS-ок, USB шнурок и… собственно, всё.
Никаких ардуин на компе, никаких иаров, композеров, и даже MspGCC вне досягаемости.

Требуется написать и разместить в памяти контроллера программу, выполняющую какие-либо полезные действия.
С помощью циркуля и линейки, то есть консоли и терминала.
Страшно?!

Возможно, олдфаги мне скажут — «фигня вопрос, мы-то в советские времена ещё и не такое делали». Пожалуй, соглашусь. Было время, рисовал в клетчатой тетради листинги в машинных кодах (!) Z80, а потом забивал в память с помощью простейшего «загрузчика» INPUT-POKE addr-GOTO 10 (ностальжи :)

Однако, отвлекся. Это ещё не все. Определим, что же будет делать наша программа.
Пусть будет джентльменский набор новичка. То есть:

  1. Измерение напряжений на аналоговых входах. Измерение внутренней температуры.
  2. Управление внешними устройствами
  3. Опрос дискретных входов (кнопка S2)
  4. Вывод на индикатор
  5. Форматный вывод в UART
  6. Командный интерфейс через UART

Но и это ещё не всё.

7. Предоставим пользователю возможность переопределять функции по своему усмотрению через тот же терминал, подключенный к UART-у.

Вот теперь всё.


Читать дальше

Тележка от HobbyKing

Годы бегут, никуда не денешься.
Ребенку внезапно уже 10+
Вопросы типа «а что вы мне подарите на новый год — ноутбук или робота лего за 15 тысяч?» несколько шокируют с непривычки.
Ну, что делать… Будем клепать робота. Пусть и не за 15 тысяч (хотя кто знает, что в итоге получится, может и дороже), но уж точно не хуже, чем лего. И главное — своими руками.

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

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

Simple Expandable Robot Chassis (KIT)



Вот как это должно выглядеть до сборки:


Итого: две небольших макетки, два колеса, два моторчика, 4 шестерни, оси (две), отсек для батареек, шаровая опора, стойки плюс мелкий крепеж — и все это за $9.99 за полную стоимость, либо сходу предлагают скидку -$1.

Если кто прошел по ссылке, обратите внимание на цену: $6.31 вместо розничной $9.99 и звездочка сбоку :)
Это скидочный купон. Чтобы его активировать, нужно зарегиться (кто ещё не) и купить.
Насколько понимаю, кто первый, тот и получит скидку. А я получу небольшой возврат на счет ($2.72)

Все, скидки больше нет. Видимо, кто-то уже соскреб.

Оплата — PayPal либо Visa/Mastercard
Расплатился с зарплатной карточки, прошло без проблем. Заодно ужаснулся, несколько быстро и беспроблемно можно обналичить чужую карточку, просто введя то, что на ней самой нарисовано.

Upd:
Рассмотрел повнимательнее, а закрались некоторые сомнения. А именно то, что колеса и шестеренки, вроде как бы независимо вращаемые, сидят на общих осях. Ну да ладно, придумаем чего-нибудь. Главное, дает начальное представление эмбедеру с кривыми от рождения руками, типа меня, как можно организовать механику из говна и палок подручных материалов.

Под это дело заказал у техасцев МСП-шный ланчпад (вот до чего обленился, лень самому сЛУТить), так что в ближайшем времени собираюсь примкнуть к счастливым обладателям. Ну да это совсем другая история…

Собственно, вот.
To be continued, надеюсь.

CodeBlocks :: не просто ещё одна IDE

Видя регулярные холивары «студия vs эклипс» или «programmers notepad против vim», каждый раз собираюсь поведать миру об универсальном инструменте, которым сам пользуюсь в течение уже нескольких лет.
Это многофункциональная IDE для С/С++ разработки Code::Blocks.


CodeBlocks — это свободная кроссплатформенная среда, заполняющая нишу между монструальными и неповоротливыми «взрослыми» системами для больших проектов, типа Eclipse, Visual Studio, Net Beans, и убогими по функционалу, но шустрыми блокнотами типа Scintilla, причем преимущества и тех, и других складываются и позволяют использовать данную систему как для написания небольших проектов для встраиваемых приложений, так и для программирования приложений для РС под Windows, Linux и MacOs.

Основные характерные особенности среды:


  • Кроссплатформенная IDE с открытым кодом, основанная на библиотеке wxWidgets
  • Компактное ядро и расширение функционала посредством множества плагинов
  • Встроенный интерфейс под множество компиляторов и тулчейнов, как свободных, так и проприетарных
  • Множество визардов для быстрого создания шаблона проекта как для разнообразных микропроцессорных архитектур (AVR, ARM, PowerPC), так и для библиотек и тулкитов под РС: GTK, Qt, WxWidgets, OpenGL итд.
  • Компактная и интуитивно понятная структура меню, обеспечивающая быструю настройку среды
  • Огромное количество забавных и полезных рюшечек, которые я до сих пор с удивлением иногда нахожу :)

Данный пост — просто беглый обзор возможностей и особенностей IDE CodeBlocks, который(ая?) незаслуженно обделен вниманием, на мой субъективный взгляд.


Читать дальше

Автогенерация кода или улетные шаблоны в Си

Давным-давно в далекой-далекой галактике попались мне исходники не помню чего, у которых в шапке стояла пометка:
// Generated Automaticaly by xxx, Do not edit

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

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

Cog — это инструмент для генерации исходных текстов программ. Он позволяет вам использовать небольшие фрагменты программ на языке Python в качестве генераторов в вашем исходном коде. Такие генераторы могут создавать любой код, который вам нужен.

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

В целом мне понравилось, но времени (да и особой надобности) не было, чтобы попробовать.
До вчерашнего дня.


Читать дальше