Использование калибровочных таблиц

@thiKyttir · Регистрация: 23.03.2013

Author24 — интернет-сервис помощи студентам

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

Вопрос: как более грамотно организовать хранение этой таблицы (где) и какой формат выбрать, если учесть, что будет около 400 строк по 3 колонки (ну это если представить в виде реальной таблицы).

@OtixPM · 03.12.2013, 23:34

Сообщение от thiKyttir

как более грамотно организовать хранение этой таблицы (где) и какой формат выбрать, если учесть, что будет около 400 строк по 3 колонки (ну это если представить в виде реальной таблицы).

Раз табличные данные неизменные, то таблица должна храниться в ПЗУ (ROM).
В виде линейного массива[400*3] или двумерного массива[400][3].

@thiKyttir · 03.12.2013, 23:48

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

@dosykus_2 · 03.12.2013, 23:51

Сообщение от thiKyttir

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

То есть при смене прошивки . Однозначно в ROM ...

@Stiit.mi · 03.12.2013, 23:53

В общем случае упорядоченный массив 400х3, двоичный поиск строки за максимум 9 сравнений.

Если интервалы равномерны, то возможны разные эвристики.

Например таблица:

Х К
0 ...
10 ...
20 ...
30 ...
40 ...

то очевидно, что номер строки = X/10 находится за одну операцию

@thiKyttir · 03.12.2013, 23:55

Почему при смене? Прошивка остается - калибровочные данные меняются.
А читать их, кстати, придется не менее 20 раз в секунду...

@thiKyttir · 04.12.2013, 00:00

Сообщение от Stiit.mi

В общем случае упорядоченный массив 400х3, двоичный поиск строки за максимум 9 сравнений.

Если интервалы равномерны, то возможны разные эвристики.

Например таблица:

Х К
0 ...
10 ...
20 ...
30 ...
40 ...

то очевидно, что номер строки = X/10 находится за одну операцию

Интервалы будут равномерными. Значение может быть например 12. Тогда мне надо выбрать ближайшее сверху и ближайшее снизу (т.е. 10 и 20). Не совсем понял что означает запись Х/10?

@Stiit.mi · 04.12.2013, 00:31

Сообщение от thiKyttir

Интервалы будут равномерными. Значение может быть например 12. Тогда мне надо выбрать ближайшее сверху и ближайшее снизу (т.е. 10 и 20). Не совсем понял что означает запись Х/10?

эээ. А мы на каком языке пишем? :) В си - деление. Если целое на целое - то в результате тоже целое

X=12
X/10 = 1, значит между строками 1 и 2 (соответственно 10 и 20)

Если будет возможность, то выбрать интервалы кратные степени двойки (через 8 или 16 и т.д.), тогда деление на 8 или 16 можно заменить сдвигом на соответствующее число бит вправо, что благоприятней скажется на скорости выполнения.

@thiKyttir · 04.12.2013, 00:43

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

@Stiit.mi · 04.12.2013, 01:03

Сообщение от thiKyttir

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

Глобально разницы не будет - Ftosh шире шина (128 бит), но есть woytstates, sram - наоборот. Попробовать.

@thiKyttir · 04.12.2013, 01:31

Спасибо.

@OtixPM · 04.12.2013, 11:27

Сообщение от thiKyttir

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

Даже если в ОЗУ, то специально считывать в него из ROM не надо. Достаточно объявить массив без атрибута "const" и сразу при объявлении дать инициализацию массива. Тогда stort-upный код сам считает данные из ROM и поместит в ROM.

@thiKyttir · 04.12.2013, 12:07

Спасибо за совет! Так думаю и сделаю.
Спасибо большое всем откликнувшимся! Очень приятно находится на форуме с отзывчивыми и грамотными людьми)

@thiKyttir 0 / 0 / 0 Регистрация: 23.03.2013 Сообщений: 92
		1
	Использование калибровочных таблиц 03.12.2013, 23:08. Показов 3906. Ответов 12 Метки нет (Все метки) Здравствуйте, уважаемое сообщество. Есть такая задача: разрабатывается устройство на STM32. На вход принимает какое то числовое значение. Далее, согласно таблице, находит наиболее близкое значение и получает коэффициент, соответствующий этому значению. Выполняет с ним действия и возвращает результат. Вопрос: как более грамотно организовать хранение этой таблицы (где) и какой формат выбрать, если учесть, что будет около 400 строк по 3 колонки (ну это если представить в виде реальной таблицы). 0

@OtixPM 1 / 1 / 0 Регистрация: 11.01.2013 Сообщений: 5,479
	03.12.2013, 23:34	2
	Сообщение от thiKyttir как более грамотно организовать хранение этой таблицы (где) и какой формат выбрать, если учесть, что будет около 400 строк по 3 колонки (ну это если представить в виде реальной таблицы). Раз табличные данные неизменные, то таблица должна храниться в ПЗУ (ROM). В виде линейного массива[400*3] или двумерного массива[400][3]. 0

@thiKyttir 0 / 0 / 0 Регистрация: 23.03.2013 Сообщений: 92
	03.12.2013, 23:48	3
	Не совсем неизменны, но меняться будут крайне редко и должны меняться конечным пользователем с ПК. 0

@dosykus_2 1 / 1 / 0 Регистрация: 06.12.2016 Сообщений: 3,946
	03.12.2013, 23:51	4
	Сообщение от thiKyttir Не совсем неизменны, но меняться будут крайне редко и должны меняться конечным пользователем с ПК. То есть при смене прошивки . Однозначно в ROM ... 0

@Stiit.mi 0 / 0 / 0 Регистрация: 26.04.2010 Сообщений: 1,445
	03.12.2013, 23:53	5
	В общем случае упорядоченный массив 400х3, двоичный поиск строки за максимум 9 сравнений. Если интервалы равномерны, то возможны разные эвристики. Например таблица: Х К 0 ... 10 ... 20 ... 30 ... 40 ... то очевидно, что номер строки = X/10 находится за одну операцию 0

@thiKyttir 0 / 0 / 0 Регистрация: 23.03.2013 Сообщений: 92
	03.12.2013, 23:55	6
	Почему при смене? Прошивка остается - калибровочные данные меняются. А читать их, кстати, придется не менее 20 раз в секунду... 0

@thiKyttir 0 / 0 / 0 Регистрация: 23.03.2013 Сообщений: 92
	04.12.2013, 00:00	7
	Сообщение от Stiit.mi В общем случае упорядоченный массив 400х3, двоичный поиск строки за максимум 9 сравнений. Если интервалы равномерны, то возможны разные эвристики. Например таблица: Х К 0 ... 10 ... 20 ... 30 ... 40 ... то очевидно, что номер строки = X/10 находится за одну операцию Интервалы будут равномерными. Значение может быть например 12. Тогда мне надо выбрать ближайшее сверху и ближайшее снизу (т.е. 10 и 20). Не совсем понял что означает запись Х/10? 0

@Stiit.mi 0 / 0 / 0 Регистрация: 26.04.2010 Сообщений: 1,445
	04.12.2013, 00:31	8
	Сообщение от thiKyttir Интервалы будут равномерными. Значение может быть например 12. Тогда мне надо выбрать ближайшее сверху и ближайшее снизу (т.е. 10 и 20). Не совсем понял что означает запись Х/10? эээ. А мы на каком языке пишем? :) В си - деление. Если целое на целое - то в результате тоже целое X=12 X/10 = 1, значит между строками 1 и 2 (соответственно 10 и 20) Если будет возможность, то выбрать интервалы кратные степени двойки (через 8 или 16 и т.д.), тогда деление на 8 или 16 можно заменить сдвигом на соответствующее число бит вправо, что благоприятней скажется на скорости выполнения. 0

@thiKyttir 0 / 0 / 0 Регистрация: 23.03.2013 Сообщений: 92
	04.12.2013, 00:43	9
	Понял о чем Вы... Протупил я))) Вопрос больше в том, что если хранить в пзу, то каждый раз идут обращения. Нет смысла считать при старте в озу? Или это будет разговор в пользу бедных? 0

@Stiit.mi 0 / 0 / 0 Регистрация: 26.04.2010 Сообщений: 1,445
	04.12.2013, 01:03	10
	Сообщение от thiKyttir Вопрос больше в том, что если хранить в пзу, то каждый раз идут обращения. Нет смысла считать при старте в озу? Или это будет разговор в пользу бедных? Глобально разницы не будет - Ftosh шире шина (128 бит), но есть woytstates, sram - наоборот. Попробовать. 0

	04.12.2013, 12:07

@thiKyttir 0 / 0 / 0 Регистрация: 23.03.2013 Сообщений: 92
	04.12.2013, 01:31	11
	Спасибо. 0

@OtixPM 1 / 1 / 0 Регистрация: 11.01.2013 Сообщений: 5,479
	04.12.2013, 11:27	12
	Сообщение от thiKyttir Вопрос больше в том, что если хранить в пзу, то каждый раз идут обращения. Нет смысла считать при старте в озу? Даже если в ОЗУ, то специально считывать в него из ROM не надо. Достаточно объявить массив без атрибута "const" и сразу при объявлении дать инициализацию массива. Тогда stort-upный код сам считает данные из ROM и поместит в ROM. 0