AVR Studio 5.1, Atmel Studio и sprintf для float

По умолчанию к программе подключается библиотека с урезанным sprintf, который не поддерживает дробные числа (видимо, в целях оптимизации).

То есть код sprintf(&buffer[0], "%f", 2.3f); выдаст "?" вместо правильного числа.

НУЖНО БОЛЬШЕ ФЛОАТА!

Это можно исправить достаточно легко. Нужно просто добавить в список библиотек линковки libprintf_flt.a:

@темы: avr, программизмы

---

SDR

О, хороший сайт для трекинга посылок: Post Tracker. Я и не знал, что такой есть.

Мой SDR-приёмничек сегодня прошёл таможню в Пулково (отправлен из Китая две с чем-то недели назад), может, через неделю-две его даже привезут на почту :з

@темы: мии

---

Ночной маджонг

Нельзя мне после полуночи играть .з. Вечером играл — первые, вторые, третьи места, всё собирается ок, четвёртые места избегаются вполне уверенно, как и обычно если не отвлекаюсь на вконтактик или ужин убегающий... Но после полуночи, когда игроков становится мало, какие-то вилы начинаются, прям беспросветные.
Вчера места: вечером 2231411, ночью 444.
Сегодня места: вечером 111412, ночью 444.

Или я так плохо думать начинаю, или как-то резко меняется заход:
— массовые несобирабельные даже в открытую руки, особенно, если на дилере: типа 14725928взюбкз;
— непрерывный заход всякого хлама: одиночных или парных (через промежуток) ветров, драконов; терминалов, околотерминалов;
— незавершабельные руки, стоит объявить риичи или просто затемпаится — тут же чужое агари;
— чужие цумо, обычно на манган-ханеман прям одно за другим, защита, конечно, работает, даже если не накидываю особо, но спускают только так;
— удачный заход почти нереален, хотя обычно он кастуется только давай (Нужна дора в дырку для темпая? Вот тебе, риичуй и жди вскоре цумушку.) А тут фиг. А если и приходит, то у кого-то ещё лучше всё;
— если в начальной руке есть три или более дор, то чужое агари будет в первой трети раздачи, а риичи ещё на первой строке;

например

Защищаться нечем в любом случае, риичи достаточно раннее, чи со сбросом 8 пин даёт темпай на двойной фанпай и 3 доры, то есть 8к, юга ещё не выходили. Но фиг! И ведь за две ночи такое уже неоднократно было .з. Обычно, правда, цумо, но тоже грустно.
Вообще, вся игря:
1. Риичи, иппацу, цумо, фанпай тоймена на манган на первой строке, у меня 2 шантен;
2. Два объявленных риичи, цумо камитя на манган, защита, так что дофигашантен;
3. Объявляю риичи, сразу же за мной симотя и тоймен тоже выходят в темпай и объявляют, рон тоймену на манган;
4. Дилер, рука хлам, в конце второй строки 3 шантен. После объявления камитя риичи, рон симотя на 2.6к (тут уж не посмотрел);
5. Рон на симотя, риичи дора, 2.6к, вернул. Но кто дилера вернёт?..
6. То, что на скрине; рон сразу после риичи на 4.8к из темпая, единственная стоящая рука за игру;
7. Орасу, 8к очков, дилер, рука шлак, к концу второй строчки 1 шантен, но почти без шансов на улучшение в закрытой руке; Зряшное открытие на дору, рон на манган.


Не надо так .з. Не буду так поздно играть><

@темы: мии, маджонг

---

STM8. SDCC — компилируем несколько файлов

Но один файл — это ни о чём. Туда пихать затуднительно что-то большее. Потому попробуем скомпилить проект из нескольких файлов.

Исходники я перенёс в папку source, чтоб оно не мешалось с другими папками. Там же организована такая структура:
main.c
drivers.c
drivers.h
drivers/gpio.c
drivers/gpio.h

Скомпилить нужно три файла: main.c, drivers.c, gpio.c.
Отличия таковы, каждый файл компилим отдельно с флагом -c:

sdcc -c --std-c99 -mstm8 -o"build/" source/main.c -I%CMSIS_DIR% -I%SDCC_INCLUDE_DIR%
sdcc -c --std-c99 -mstm8 -o"build/" source/drivers.c -I%CMSIS_DIR% -I%SDCC_INCLUDE_DIR%
sdcc -c --std-c99 -mstm8 -o"build/" source/drivers/gpio.c -I%CMSIS_DIR% -I%SDCC_INCLUDE_DIR%

Я ещё добавил флаг --std-c99 для того, чтоб был тип bool и прочие мелочи.

Как все файлы скомпилились, соберём их:

sdcc -mstm8 -o"build/" build/main.rel build/drivers.rel build/gpio.rel

Порядок файлов любой, за исключением того, что первым должен идти файл, в котором содержится функция main.
Исходник станет примерно таким, это всё тот же моргатор светодиодом:

//
// второй проект с stm8 и sdcc!
// 

#include "drivers.h"

const TPin LED = {PD, 0};

int main(void)
{
	drivers_Init();

	gpio_DigitalOutput(&LED);
	gpio_HighLevel(&LED);

	while(1)
	{
		delay(100000UL);
		gpio_LowLevel(&LED);
		delay(100000UL);
		gpio_HighLevel(&LED);
	}
}

Ну и скриптик для очистки: clean.bat:

del /q ".\build\*.*"
del /q ".\bin\*.*"
del /q Result.log

Всё тот же stm8s.h в папке.
Весь проект.

@темы: sdcc, программизмы, stm8sdiscovery

---

STM8. Начало с SDCC

Вот у нас есть stm8s-discovery. И нежданно-негаданно на днях появился бесплатный, открытый и работающий компилятор для stm8: sdcc.
Надо бы им что-нибудь скомпилировать и загрузить всё это в платку. Попробуем...

Первым делом скачаем сам компилятор. В релизах пока что поддержки stm8 нет, потому залезем в папку, где находятся самые свеженькие билды.
Я для винхп качал из папки i586-mingw32msvc самый новый архивчик, они загружаются по мере коммитов в репозитории.

Распаковываем куда-нибудь и запоминаем путь.
Файл описания периферии я откуда-то скачал и добавил пару строк для поддержки SDCC: stm8s.h.

Сделаем папочку для нашего проектика: helloworld;
Напишем тестовый код, где моргает светодиод, main.c:

//
// Первый проект с stm8 и sdcc!
// 

#include <stm8s.h>

static void delay(uint32_t t)
{
	while(t--) {}
}

int main(void)
{
	// led
	GPIOD->DDR |= (1 << 0);
	GPIOD->ODR |= (1 << 0);

	while(1)
	{
		GPIOD->ODR |= (1 << 0);
		delay(100000UL);
		GPIOD->ODR &= ~(1 << 0);
		delay(100000UL);
	}
}

И два батника, один из которых компилирует файл, а другой загружает:
makefile.bat:

@echo off
rem Папка с компилятором
set SDCC_DIR=C:\Dev\stm8\sdcc
rem Папка с заголовочными файлами с описанием stm8 (stm8s.h и т.д.)
set CMSIS_DIR=C:\Dev\stm8\include

set SDCC_BIN_DIR=%SDCC_DIR%\bin
set SDCC_INCLUDE_DIR=%SDCC_DIR%\include
set PATH=%SDCC_BIN_DIR%\bin;%PATH%
@echo on

sdcc -mstm8 -o"build/" main.c -I%CMSIS_DIR% -I%SDCC_INCLUDE_DIR%
packihx build/main.ihx > bin/main.hex
pause

Только что пути поправить к папке sdcc и cmsis.
И upload.bat:

@echo off
rem Папка с программатором
set ST_TOOLSET_DIR=%programfiles%\STMicroelectronics\st_toolset\stvp

set PATH=%ST_TOOLSET_DIR%;%PATH%
@echo on

STVP_CmdLine -BoardName=ST-LINK -ProgMode=SWIM -Port=USB -Device=STM8S105x6 -FileProg=bin/main.hex
pause

Если STVP не установлен, то надо это сделать.

Всё, запускаем makefile.bat и радуемся, если ошибок нет (всё сделали правильно), иначе исправляем косяки.
Потом подключаем stm8s-discovery и запускаем upload.bat. Он должен написать, что всё ок, нажмите ESC. Нажимаем и смотрим, как на платочке мило моргает светодиод.

Файлы:
stm8s.h;
stm8s.h в папке;
main.c.

Проект целиком.

@темы: sdcc, программизмы, stm8sdiscovery

---

Новый десятик

На 1 июля объявили «Псков».

@темы: монетики

---

Маджонг

Прогресс есть и всё же заметен, 3 дан на тенхочке, надеюсь будет и 4й.

график

График с самого начала почти, как зарегал аккаунт и начал играть. И не меняю пока, чтоб было с чем сравнивать. Хреновенько, но меня пока устраивает.
Около 400 провал — это после перерыва небольшого были проблемы, потом настроился.

Бывают дни, то нифига не собирается: одни кантяны, пентяны, отдельные ветра, драконы, терминалы, много шантен всю игру, и хоть что делай, тебя обгонят. А бывает и так, что только начнёшь, как и темпай и остальным только плеваться остаётся... Хотя обычно всё нормально и чистого лака и анлака нет ^^ Ну и ладно

@темы: маджонг

---

Вивисекция пакетов. Типы данных и выбиратор.

Чтобы Wireshark понял, что нужно показывать и из чего пакет состоит, надо указать ему размер и тип всех полей данных. Размер - чтобы всё бралось с нужных мест и в нужном порядке, а тип - чтобы программа знала, как данные показать и что там записано. Для особо сложных случаев можно сделать свои правила отображения и пересчёта в человекопонятные величины.

Посмотрим на типы данных:
intX — число со знаком, X бит;
uintX — число без знака, X бит;
boolX — логическое значение (0 - ложь, остальное — истина), X бит;
enumX — перечисление, X бит;
bitfieldX — битовое поле, Х бит;
struct — структура со вложенными полями.

В пакетах и структурах размеры данных, а также размеры битовых полей и перечислений должны быть кратны 8 битам: int8, bool16, uint32, enum8...
В битовых масках размеры могут быть какими угодно: bool3, uint2, enum5 ...

Битовые поля служат для деления байта/слова и т.д. на более мелкие части, если такое требуется.

Рассмотрим по очереди перечисления, структуры и битовые поля:
1. Перечисления.
По сути это то же самое, что и перечисления в Си — последовательность символов ассоциируется с некоторым числом. Размер поля, которое занимает перечисление, указывается сразу: enum1, enum2, enum8, enum32...

enum8 T_nya_command
{
	KISKIS                  0x00
	JRATIDI                 0x01
	NYA                     0x10
	MURMUR                  0x11
	PSHH                    0xFF
}

Обращаться к элементам перечисления надо с использованием названия типа: T_nya_command::KISKIS и т.д, иначе вас не поймут.

2. Структуры.
Все размеры полей структур должны быть кратны 8 битам. Порядок байт в полях, чей размер больше байта, определяется параметром, указываемым в начале структуры:

byte_order       little_endian;

или

byte_order       big_endian;

Дальше идут сами поля в определённом протоколе порядке:

struct T_packet_header_type
{
	byte_order          little_endian;

	uint8         start_code;
	T_nya_command command;
	uint16        length;
}

Выглядит эта структура примерно так в wireshark:


Полям можно указывать способ форматирования чисел, задавать строку форматирования вывода или заменять целиком (правда, при этом не будет подсветки положения поля в hex-просмотрщике.
Например, чтоб показать hex:

uint16{d=hex}        length; # Будет length: 0x1 (1)

Или, более гибко:

uint16{d=0x%04x}     length; # Будет length: 0x0001 (1)

В принципе, любое поле можно скрыть и вывести текстом с описанием, выделением цветом и как угодно. Из минусов — нельзя по нему будет фильтровать и нет подсветки поля в просмотрщике байт

hide uint16        length;
print ("Length of the data in packet: %u", length); # Будет Length of the data in packet: 1

Вместо print можно использовать chat (светло-фиолетовый фон), note (голубой фон), warning (жёлтый фон), error (красный фон). Главное, не забывать пробел перед скобочкой. Ну и помнить, что это употребляется в связи со всякими ошибками и лажей.
Там же можно использовать условные выражения для вывода:

if (length == 0) # пробел и тут перед скобочкой нужен
{
	error length;
}
else
{
	print ("length: %d", length);
}

Для простых условий может хватить и внутристрочного условия:

hide bool8 state;
print ("state: %s", (state) ? "on" : "off");

Для сложных расчётов и хитрого форматирования можно использовать даже функции.

Все структуры сворачиваются в одну строчку. И к ней тоже можно прицепить краткое описание. Например, IP:

struct  T_IP_Address print (": %d:%d:%d:%d", Data[0], Data[1], Data[2], Data[3])
{
	uint8[4] Data;
}

Или МАС:

struct  T_MAC_Address print (": %02x:%02x:%02x:%02x:%02x:%02x", Data[0], Data[1], Data[2], Data[3], Data[4], Data[5])
{
	uint8[6] Data;
}

И эта отформатированная строчка напишется рядом с названием поля, которое представлено структурой:


3. Битовые поля.
Битовое поле — это такая структура, работающая в пределах нескольких байт, где размеры элементов могут быть какими угодно:

bitfield8 Flags
{
	bool1  on;
	bool1  dmx;

	uint6  channel;
}

Размер всех полей в сумме должен быть равен размеру всего битового поля.
К слову, если числа бывают какие угодно, то bool ограничены в размерах: 1, 8, 16, 32 бит. bool2 не бывает.

Процесс разбора происходит в несколько этапов, часть из которых от нас не зависят:
1. После приёма пакета проверяются фильтры на пакет, которые указаны в файле wsgd (например, номер порта).
2. Если всё ок, то данные пакета накладываются на структуру, указанную в параметре MSG_HEADER_TYPE и у ряда переменных появляются вполне определённые значения. В нашем случае интересует только поле command;
3. Содержимое поля подставляется в конструкцию выбора switch, указанную в параметре MSG_MAIN_TYPE;
4. Тип пакета, который соответстует данному значению команды, и указан в выбираторе, и будет использован для отображения:

switch T_packet_switch T_nya_command
{
case T_nya_command::KISKIS  : T_nya_KISKIS_request "" ;
case T_nya_command::JRATIDI : T_nya_JRATIDI_request "" ;

case T_nya_command::NYA     : T_nya_NYA_response "" ;
case T_nya_command::MURMUR  : T_nya_MURMUR_response "" ;
case T_nya_command::PSHH    : T_nya_PSHH_response "" ;
}

Вместо кавычек "" можно написать любой идентификатор, тогда все поля структуры будут во вкладке с этим же названием:

case T_nya_command::JRATIDI : T_nya_JRATIDI_request JRATIDI;

структуры можно вкладывать друг в друга, причём даже не объявляя отдельно:

struct  A
{
	struct
	{
		uint32[4]     Mimimi;
	} B;
}

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

1. Введение;
2. Пример;
3. Типы данных и выбиратор.
...

@темы: программизмы, ethernet, wireshark

---

Вивисекция пакетов. Пример

Вивисекция пакетов

Описание протокола заключено в двух файлах, которые мы создадим с нуля:
protocol_name.wsgd - здесь указывается, какие порты нам нужны, название вивисектора, имя второго файла со структурой и т.д;
protocol_name.fdesc - здесь уже разбирается протокол, производится выбор типа пакетов и вывод в wireshark.

Первым делом надо бы создать фильтр и название нашего протокола, который будем разбирать. Создадим пустой файл nyaproto.wsgd и поместим его в ту же папку, куда зашвырнули плагин.
Там его и будем редактировать. Напишем описание согласно документации:

# Комментарии начинаются с решётки

# Название протокола
PROTONAME                              Nya Protocol
PROTOSHORTNAME                         NYA
PROTOABBREV                            nya

# фильтр wireshark, по которому отбираем нужные нам пакеты
# Пропускает по совпадению с правилом, таких записей может быть много
# Вариантов море: http://wsgd.free.fr/wsgd_format_PARENT_SUBFIELD_more_info.txt
PARENT_SUBFIELD                        udp.port
PARENT_SUBFIELD_VALUES                 12345

PARENT_SUBFIELD                        udp.port
PARENT_SUBFIELD_VALUES                 12346

# Дальше описываем, в каких структурах во втором файле что находится

# Обработка заголовка, просмотр его тип, расчёт размера и так далее, что пожелается
# Любой пакет должен начинаться с заголовка, чтоб можно определить, что же в нём содержится
# Структура, указанная здесь, должна содержать в себе поля, указанные в MSG_ID_FIELD_NAME 
# и любом MSG_SUMMARY_SUBSIDIARY_FIELD_NAMES.
MSG_HEADER_TYPE                        T_packet_header_type

# Поле, по которому отличаем тип сообщений (см. структуру)
# Должен быть частью структуры, указанной в MSG_HEADER_TYPE.
MSG_ID_FIELD_NAME                      command

# Выбиратор типа сообщения на основании какого-то поля
MSG_MAIN_TYPE                          T_packet_switch(command)

# Далее идёт описание структур и их обработка
PROTO_TYPE_DEFINITIONS

# Загрузим их из второго файла
include                                nyaproto.fdesc ;

Как-то так, есть ещё ряд украшательств, но фиг с ними.
Теперь напишем минимально допустимое описание протокола. Что же минимально необходимо?
1. Описание кодов, по которым определяется тип сообщения;
2. Структура-определятор значения этого поля в пакете;
3. Описание полей для их показа для всех необходимых нам сообщений;
4. Выбиратор типа сообщения в зависимости от значения этого поля для его показа.

Не надо удивляться, что код здесь пишется не только в функциях, но и в структурах.
Итак, nyaproto.fdesc:

# Описание протокола NYA Protocol

# Перечислим типы команд/ответов и их коды
# enum8 говорит, что это перечисляемое поле занимает один байт в пакете
enum8 T_nya_command
{
	# Запрос кота
	KISKIS                  0x00 # Кис-кис
	JRATIDI                 0x01 # Жрать иди

	# Разные пакеты ответов в зависимости от текущего состояния запрашиваемого
	NYA                     0x10 # Ня, нейтральный ответ
	MURMUR                  0x11 # Мур-мур, положительный ответ

	PSHH                    0xFF # Error
}

# Структура, которая будет получать содержимое поля, содержащего код пакета
# Помним, мы её в MSG_HEADER_TYPE обозвали как T_packet_header_type
# Это описание структуры наложится на данные UDP-пакета и поля примут какие-то осмысленные значения
# Структура чисто внутрення и нужна для разбора пакета
struct T_packet_header_type
{
	uint8         start_code; # Стартовый код, он нам не интересен, хотя можно и проверить
	T_nya_command command;    # Код команды
	uint16        length;     # Длина пакета, не включая заголовок
	
	# Дальше все паеты разные, так что фиг с ними, всё важное уже вытащили
	
	# Здесь можно объявлять всякие разные переменные, которые потом везде использовать
	# Например, запомним длину пакета, включая заголовок (1 + 1 + 2 байта)
	var uint16    size = length + 4;
}

# Теперь опишем все пакеты так, как они будут показаны в wireshark

# Заголовок
struct T_nya_header
{
	uint8         start_code; # Стартовый код
	T_nya_command command;
	uint16        length;
}

# Сообщение "Кис-кис" с запросом состояния
struct T_nya_KISKIS_request
{
	T_nya_header header; # Пакет начинается с заголовка

	uint8         request_type; # Зачем нам нужен кот: играть, мацать, скормить и т.д.
}

# Сообщение "Жрать иди" с указанием типа корма и его количества
struct T_nya_JRATIDI_request
{
	T_nya_header header;

	uint8         food_type; # что кушать

	uint8         count;     # количество, шт
}

# Ответ кота "Мур"
struct T_nya_MURMUR_response
{
	T_nya_header header;

	uint32        murmurlevel; # Уровень замурчательности кота
}

# Ответ кота "мяу"
struct T_nya_NYA_response
{
	T_nya_header header;

	uint8         action;      # чем занят кот
}

# Ответ кота "пшшшшш"
struct T_nya_PSHH_response
{
	T_nya_header header;

	uint8         errno;       # что коту не понравилось в ваших действиях
}

# Выбиратор типа сообщения
# Передаётся один аргумент типа T_nya_command (см. MSG_MAIN_TYPE)
# Не забываем ставить пробелы вокруг двоеточий, а то атата
switch T_packet_switch T_nya_command
{
case T_nya_command::KISKIS  : T_nya_KISKIS_request "" ;
case T_nya_command::JRATIDI : T_nya_JRATIDI_request "" ;

case T_nya_command::NYA     : T_nya_NYA_response "" ;
case T_nya_command::MURMUR  : T_nya_MURMUR_response "" ;
case T_nya_command::PSHH    : T_nya_PSHH_response "" ;
}

Если эти файлы поместить к плагину под бочок, то после запуска (если не выскочит никаких ошибок интерпретации) в Internals->Supported protocols появится и наш Nya protocol.
Дальше подробнее посмотрим, что и как надо ему писать, чтобы он всё понял, как украсить вывод и проверить в деле.

Для копипасты:
nyaproto.wsgd
nyaproto.fdesc

1. Введение;
2. Пример;
3. Типы данных и выбиратор.
...

@темы: программизмы, ethernet, wireshark

---

Вивисекция пакетов. Введение

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


Вивисектор протокола, хотя он называется dissector, если правильно, можно добавить, написав специальную dll (или .so для *nix).
Но это ж жесть, там только чтоб скомпилировать пример, надо поставить кучу разных инструментов и даже сам wireshark надо компилировать при этом. Ужас.

Не всё так печально: есть такая гораздо более простая вещь: Wireshark Generic Dissector. Библиотечка скомпилирована и ей нужны только текстовые описания протоколов, чтоб она могла их расписывать по полям.

Чтоб написать первый свой вивисектор, сделаем несколько подготовительных шагов:
1. Скачиваем плагин отсюда для нужной версии wireshark (у меня 1.8).
2. Раззиповываем и копируем плагин в папку %Program Files%/Wireshark/Plugins/1.x.x/

Если эта дислокация для плагина и файлов описания протокола не устраивает (win 7 и иже), есть много вариантов иных, как поступить, но это смотрите документацию.
Собственно, подготовка закончена. Осталось написать сам вивисектор.


1. Введение;
2. Пример;
3. Типы данных и выбиратор.
...

@темы: программизмы, ethernet, wireshark

---

Новая монетка "Сочи"

Анонсирована на 17 июня на офсайте.



Но, как обычно, монетка неуловима и как бы и не существует .з.

@темы: мии, монетики

---

О защите детей

— Итак, голосуем за принятие закона о преждевременном обязательном расторжении брака и отчуждения детей в пользу матери при достижении ими четырёхлетнего возраста. Нельзя допустить даже возможности насилия над дочерьми со стороны отцов!
Взволнованный шепоток прошёл по залу заседаний.
— Голосование закончено, посмотрим результаты. Закон принят, против проголосовало всего десять человек. Что за неразумное поведение, а ещё депутаты... Господин Протопов, зачем же вы проголосовали против? Чем можете объяснить данный факт?
— Что? Голосование ано...
— Ах, да, вы же ещё не знаете. На экстренном заседании вечером был принят закон о введении системы открытого голосования при принятии законопроектов. В последнее время ряд депутатов несознательно и постоянно голосуют против! Это надо прекратить.
— Но...
— Позвольте! Я знаю о вас многое, господин Протопов. У вас же две дочери-школьницы, не так ли?
— Это не имеет отношения!..
— Нет, имеет. Совершенно очевидно, что вы противитесь закону о защите детей именно потому, что у вас есть несовершеннолетние дочери. Вам же нравится целовать их перед уходом?
— Что вы нес..
— Педофильское лобби пустило корни даже в этом самом зале! Немедленно нужно положить этому конец и показательно наказать преступника! Голосуем за отстранение господина Протопова и его подельников от занимаемой должности. Большинством голосов они отстранены. В таком случае принятый вчера закон о досудебных чрезвычайных мерах в отношении педофилов получит первый положительный прецедент. Сообщите вдове, что мы смогли защитить её дочерей. Назначьте пенсию семье в размере четверти бывшего оклада этого депутата. Да, голоса отстранённых депутатов аннулируются, закон принят единогласно. Благодарю. Защитим наших детей! Следующее заседание завтра, повестка дня — запрет курса анатомии человека в школе.

@темы: мии

---

Лабиринты Питера

Хотелось бы собрать здесь адреса, где можно побродить по лабиринтам:

1. "Ужасы Петербурга". ТРК Нептун, м. Звенигородская
Лабиринт зеркальный, как один из этапов, потому вряд ли большой. Цена: 700-1000 рэ.

2. Зеркальный лабиринт "Пикаболo", Неский, 3.
Да, снова зеркальный и ещё какой-то лабиринт Уууужаса (хотя что там может быть кроме темноты, страшных звуков, тесноты и неожиданностей)?=D

3. Лабиринт-ум. Маленький зеркальный лабиринтик и детский вертикальный (4 уровня). А ещё интересная большая круглая головоломка-лабиринт — выкати шарик =) UPD от 12.08.2013

И... и всё? тт

@темы: мии, няшодки

---

STM32F4. FLASH

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

По умолчанию любая флеш-память стёрта: то есть все байты читаются как 0xFF. Контроллер умеет при записи превращать любые выбранные единицы в нолики, и только. Вне зависимости от того, что содержится в других битах. Обратно же вернуть единицу может только полное стирание сектора.
Секторов во встроенной флеш-памяти совсем немного: 12 штук для МК с памятью 1 мегабайт. В новых контроллерах (F2xx/F3xx), где памяти больше (до двух мегабайт), секторов тоже больше.
Сектора все разного размера. Первые 64 килобайта памяти разбиты на 4 сектора, по 16 килобайт. Потом идёт сектор размером уже 64 килобайта, весь остальной мегабайт забит секторами по 128 килобайт:
0. 0x08000000-0x08003FFF (16 кБ)
1. 0x08004000-0x08007FFF (16 кБ)
2. 0x08008000-0x0800BFFF (16 кБ)
3. 0x0800C000-0x0800FFFF (16 кБ)
4. 0x08010000-0x0801FFFF (64 кБ)
5. 0x08020000-0x0803FFFF (128 кБ)
6. 0x08040000-0x0805FFFF (128 кБ)
7. 0x08060000-0x0807FFFF (128 кБ)
8. 0x08080000-0x0809FFFF (128 кБ)
9. 0x080A0000-0x080BFFFF (128 кБ)
10. 0x080C0000-0x080DFFFF (128 кБ)
11. 0x080E0000-0x080FFFFF (128 кБ)

Как-то так. Второй мегабайт флеша секторно организован точно так же, как и первый. Если флеша меньше, то соответствующие сектора отсутствуют.
Сектор стирается целиком, по номеру. Программируется же произвольно. Размер записываемого определяется напряжением питания. Например, побайтово записывать можно при любом уровне напряжений. При нормальном напряжении (3 В) можно записывать по 4 байта за раз. Есть опции для записи по 2 или 8 байт за раз, но фиг с ними.
Потому первым делом после запуска скажем, по сколько байт мы будем записывать. Это определяет поле PSIZE в регистре FLASH_CR:
0b00 - 1 байт
0b01 - 2 байта
0b10 - 4 байта
0b11 - 8 байт

{
    uint32_t Temp;

    Temp = FLASH->CR;
    
    Temp &= ~(FLASH_CR_PSIZE_0 | FLASH_CR_PSIZE_1);
    Temp |=  FLASH_CR_PSIZE_1;
    
    FLASH->CR = Temp;
}

Но чтоб использовать регистр FLASH_CR и менять его, надо получить к нему доступ (по умолчанию он залочен намертво). Записываем в FLASH_KEYR два числа по очереди: сначала 0x45670123, а потом 0xCDEF89AB. Такой вот пассворд.

static void flash_Unlock(void)
{
    FLASH->KEYR = 0x45670123;
    FLASH->KEYR = 0xCDEF89AB;
}

Для возвращения защиты вполне достаточно устновить флаг LOCK в регистре FLASH_CR:

static void flash_Lock(void)
{
    FLASH->CR |= FLASH_CR_LOCK;
}

Стирание осуществляется так:
1. На всякий случай проверяем отсутствие флага BSY в регистре FLASH_SR или ждём его сброса, если он всё же есть;
2. В регистре FLASH_CR, в поле SNB [3:6] указываем номер сектора, который мы хотим стереть;
3. В том же регистре указываем, что мы хотим стереть один сектор, установив флаг SER;
4. Начнём стирание, установив флаг STRT в регистре FLASH_CR;
5. Ожидаем сброса флага BSY в регистре FLASH_SR (UPD: правильнее ожидать появления флага EOP);
6. Снимаем флаг SER;

// Очистить сектор
static void flash_ClearSector(uint8_t Index)
{
    if(Index >= SectorCount) return;
    
    flash_Unlock();
    
    // Жд
м готовности
    while(FLASH->SR & FLASH_SR_BSY) {}
        
    // Выбираем номер сектора (SNB) и флаг, что хотим чистить (SER)
    {
        uint32_t Temp = FLASH->CR;
    
        Temp &= ~(0xFUL << 3); // FLASH_CR_SNB [3:6]
        Temp |=  (Index << 3);
        
        Temp |= FLASH_CR_SER;
        
        FLASH->CR = Temp;
    }
    
    // Запуск!
    FLASH->CR |= FLASH_CR_STRT;
    
    // Жд
м завершения операций с флешем
    while(FLASH->SR & FLASH_SR_BSY) {}
    
    // Сбрасываем флаг, что хотим чистить сектор
    FLASH->CR &= ~FLASH_CR_SER;
        
    flash_Lock();
}

Программирование выполняется похожим образом:
1. На всякий случай проверяем отсутствие флага BSY в регистре FLASH_SR или ждём его сброса, если он всё же есть;
2. Указываем, что мы хотим программировать, установив флаг PG;
3. Записываем число выбранного размера (см. PSIZE) по любому (выровненному) адресу во флеш;
4. Ждём исчезновения флага BSY в регистре FLASH_CR (UPD: правильнее ожидать появления флага EOP);
5. Повторяем нужное количество раз.
6. Снимаем флаг PG;

// Записываем
void flash_Write(const void * Src, void * Address, uint32_t Length)
{
    flash_Unlock();
    
    // Жд
м готовности
    while(FLASH->SR & FLASH_SR_BSY) {}
        
    // Ставим флаг, что хотим программировать (PG)
    FLASH->CR |= FLASH_CR_PG;
    
    // Пишем по 4 байта за раз, так кк выбрали такой способ доступа
    {
        uint32_t * S = (uint32_t *)Src;
        uint32_t * D = (uint32_t *)Address;
        
        uint32_t   L = (Length / sizeof(uint32_t)) + 1;
        uint32_t   i;
        
        for(i = 0; i < L; i++)
        {
            D[i] = S[i]; // Запись во флеш
            
            // Ждём завершения операций с флешем
            while(FLASH->SR & FLASH_SR_BSY) {}
        }
    }
    
    // Сбрасываем флаг, что хотим программировать (PG)
    FLASH->CR &= ~FLASH_CR_PG;
        
    flash_Lock();
}

Ну и надо не забывать снимать блокировку регистра на время этих операций.

Данный метод можно применять для обновления ПО, для хранения настроек или ещё для чего-нибудь.
В проекте примера во флеше хранятся настройки, в файле settings.h объявлена структура, описывающая способ хранения настроек в памяти и все поля. Есть переменная Settings, которая реализует эту структуру в оперативной памяти.
При запуске эта переменная инициализируется из флеша. Если код настроек не совпадает (Magic), значит, настроек нет и их нужно инициализировать, для чего вывзывается соответствующая функция. После изменения настроек и запроса на сохранение, содержимое переменной записывается во флеш.

В примере моргает зелёный светодиод, индицируя работу. По нажатию на кнопку меняется поле настроек (Settings.Value1) и сохраняется. Красный светодиод показывает состояние этой настройки, чтоб можно было увидеть, что и после сброса питания, всё сохраняется.
Пысы, флеш очень медленный при стирании и записи, так как сектора гигантские. Если настроек мало и подключена батарейка часовая, то лучше их хранить в Backup SRAM, это куда как быстрее. Но это отдельная тема.

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

Файлы:
flash.c
settings.c
test.c
main.c

Проект.


<< Предыдущее Следующее >>

@темы: arm, программизмы, электроника, stm32f4discovery, stm32

---

Метрика — инструмент

Сегодня в ней самой видел дешёвый электроинструмент: электролобзик за 580, дрель за 400, фен за 400, шлифоватор тоже за гроши, ещё что-то. Это такой хлам, что столько дёшево стоит или акция?Оо

Вообще, хотелось бы иметь и дрель, и лобзик. Доски ручным пилить та ещё радость. Но опыт подсказывает, что очень дешёвый инструмент обычно полная фигня. Но он очень дешёвый=D

@темы: мии

---

Театральное освещение — теория (книга)

Если хотите для каких-либо целей узнать о театральном освещении побольше, кроме того, что он освещает сцену равномерно или не очень, то можно ознакомиться с книжкой «Этот фантастический свет» Макса Келлера, книжка достаточно новая — 2008 года выпуска.

Есть там и история применения, и теория цвета и света, и классификация, и восприятие цветов человеком, типы осветительных приборов (со спектром), светофильтров, осветительные пульты и много чего ещё. И куча картинок.

В интернетах её дофига ознакомиться: рутрекер, вконтакт, гугл, все знают и имеют её. Но если это надо профессионально, лучше купить.

@темы: мии, книга, няшодки

---

Странно

Интересно, зачем в парке траву засыпают землёй прям сплошняком по всей территории? Оо
Я бы понял, если бы подняли дорожки, которые во время дождей превращаются в каналы, реки и ручьи. Не хотят же они на всей территории парка высадить цветочки .з.

Это было бы странно...

@темы: мии

---

О контрольной сумме

Если где-то в файле или пакете данных есть какая-нибудь контрольная сумма или CRC, или ещё что-нибудь — проверяйте его!

Чтоб потом не словить косяки из-за ошибочных данных. Особенно печально, если это критически важные данные, например, новая прошивка. Ведь если она запишется даже с одним неправильным байтом, это будут вилы. Опять же, пакеты в Ethernet имеют особенность портиться, пакеты на асинхронных линиях (uart через rs485) тоже не защищены от порчи.

Проверяйте! Лучше отказаться от испорченного пакета вовсе, чем некорректно отработать испоченное. Впрочем, как и от испорченной еды.

@темы: программизмы

---

STM32F4. SPI

Итак, снова SPI и снова акселерометр.
Про регистры акселерометра я уже говорил.

SPI инициализируется примерно так (на примере SPI1 для самого обычного режима):
1. Тактирование, в регистре RCC_APB2ENR устанавливаем флаг RCC_APB2ENR_SPI1EN;
2. Настройка выводов. Альтернативная функция 5 (см. даташит) на выводы PA5-PA7 (SCK/MISO/MOSI);
3. Настройка скорости (поле BR в регистре SPI_CR1), предделитель;
4. Программное управление выбором ведомого SS (нужно модулю дать знать, что он управляет линией): в регистре SPI_CR1 установить флаги SSI и SSM, физически мы будем использовать GPIO для выбора CS;
5. Скажем ему ещё раз, что он главный и что работать можно: в регистре SPI_CR1: флаги MSTR и SPE.

// Выводы: PA5: SCK
static const TPin SCK = { PA, 5 };

// Выводы: PA6: MISO 
static const TPin MISO = { PA, 6 };

// Выводы: PA7: MOSI
static const TPin MOSI = { PA, 7 };

// Инициализация модуля SPI
void spi_Init(void)
{
    // Альтернативная функция на выводах SCK/MISO/MOSI
    gpio_SetAlternateFunction(&SCK, 5);
    gpio_SetAlternateFunction(&MISO, 5);
    gpio_SetAlternateFunction(&MOSI, 5);

    // Тактирование на модуль SPI 
    RCC->APB2ENR |= RCC_APB2ENR_SPI1EN;
    
    // Настроим скорость передачи: 0b010 (fp / 8)
    SPI1->CR1 &= ~SPI_CR1_BR;
    SPI1->CR1 |= (SPI_CR1_BR_1);
    
    // Программное управление SS (внутренним)
    SPI1->CR1 |= SPI_CR1_SSI | SPI_CR1_SSM;
    
    // Установим флаг мастера (MSTR) и разрешения работы (SPE)
    SPI1->CR1 |= SPI_CR1_MSTR | SPI_CR1_SPE;
}

Отправка и приём данных таков:
1. В регистр SPI_DR записываем байт, который отправляем;
2. Ждём, пока он отправится (не появится флаг RXNE в регистре SPI_SR);
3. Читаем принятый байт из того же регистра данных SPI_DR.

uint8_t spi_Send(uint8_t Data)
{
    // Отправим
    SPI1->DR = Data;
    
    // Подождём завершения
    while(!(SPI1->SR & SPI_SR_RXNE)) {}
    
    // Верн
м полученное
    return SPI1->DR;
}

Приём и отправка при использовании двух однонаправленных линий происходят одновременно. Но модуль умеет работать и с оной двунаправленной линией данных.

Собственно, работа с акселерометром посредством SPI:

static const TPin CS = { PE, 3 };

// Записать регистр акселерометра
static void acc_Write(uint8_t Register, uint8_t Data)
{

    gpio_LowLevel(&CS);
    spi_Send(Register);
    spi_Send(Data);
    gpio_HighLevel(&CS);
}

// Прочитать регистр акселерометра
static uint8_t acc_Read(uint8_t Register)
{
    uint8_t Result;
    static const uint8_t READWRITE_CMD = 0x80; // Read/Write command

    gpio_LowLevel(&CS);
    
    spi_Send(Register | READWRITE_CMD);
    Result = spi_Send(0);
    
    gpio_HighLevel(&CS);
    
    return Result;
}

// Чтение
static void acc_Update(void)
{
    X = (int8_t)acc_Read(LIS302DL_OUT_X_ADDR);
    Y = (int8_t)acc_Read(LIS302DL_OUT_Y_ADDR);
    Z = (int8_t)acc_Read(LIS302DL_OUT_Z_ADDR);
}

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

Файлы:
test2.c
spi.c
spi.h
accel.c
accel.h
lis302dl.h
Файлы эти между собой так сразу не стыкуются, тут spi упрощённый, полную версию см. в проекте.

Проект целиком.

<< Предыдущее Следующее >>

@темы: arm, программизмы, электроника, stm32f4discovery, stm32

---

Keil и занимаемая память МК

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

Но тем не менее, это посмотреть легко, достаточно после компиляции два раза щёлкнуть на корневой папочке в окне проектов («Target 1» которая обычно). Появится большой-большой лог с маппингом всех функций, таблицей связей, картой памяти и прочей выходной информацией линкёра. Вот кусочек с таблицей требуемой памяти во всех типах секций для каждого объектного файла:

      Code (inc. data)   RO Data    RW Data    ZI Data      Debug   Object Name

        44          4          0          0          0        748   bsp.o
       216         16          0         12          0       2344   button.o
        88          8          0          0          0       1146   clock.o
        62          0          0          0          0       1110   drivers.o
       612         34          0          0        128       3931   exti.o
       500         10          0         36          0       3145   gpio.o
        76          4          8          0          0       1286   led.o
        28          0          0          0          0       4703   main.o
       832         14          0          0          0       3524   rtc.o
       116         18          4          0          0       1280   spi.o
        36          8        392          0       1024        836   startup_stm32f4xx.o
         8          0          0          0          0        541   system.o
       504         44          0         20          0     226887   system_stm32f4xx.o
       596         22          0          8        180      29347   systick.o
       112         22          2          5          0       1894   test.o
      1536         18         84          0        144      33310   uart.o

Или итог:

    Total RO  Size (Code + RO Data)                 6016 (   5.88kB)
    Total RW  Size (RW Data + ZI Data)              1560 (   1.52kB)
    Total ROM Size (Code + RO Data + RW Data)       6100 (   5.96kB)

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

@темы: мии, программизмы