Проблема состоит в том, что у меня контроллев F2013, соответственно у него 2к памяти. Для преобразования напряжения с АЦП в температуру используется полиномы 6й и 9й степени.
Что бы не потерять точность необходимо использовать формат с плавающей точкой, но при его использовании и совершении операций над ним библиотеки умножения занимают минимум 700 байт. Вообщем это слишком жирно.
Пробовал сделать свой формат, тоже плавающий, но умножать на 2в степени. После того как перемножал два int, получал long, потом сдвигал вправо до int и увеличивал степень. Но при этом точность падала. В некоторых случаях стала неудовлетворительной.
Предложите, чем можно заменить, как обойти.

А что вы дальше с температурой делаете? если посылаете на компьютер или записываете куда, тогда можно так и оставить, а перерасчёт оставтиь компьютеру.

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

Не понял: 700 байт флеши жалко?
Или 700 ОЗУ? - /не верю, многовато что-то/

Вообщем то жалко и даж очень. Тут еще должно быть много чего. И протокол Modbus RS485 с перестройкой скоростей и опрос АЦП и получение температуры холодного спая от внутреннего сенсора, и еще куча параметров, стандартных для датчиков температуры.
А 700 байт это на вскидку. Реально при линковании еще больше пойдет...

1) Кусочно-линейная аппроксимация в целых числах не поможет? Я именно так и делаю. Одно значение long на один градус, правда датчик NTC.
2) Теоретически все можно перевести в целочисленную математику, только диапазоны нужно тщательно проверять.

Какую же точность по температуре и в каком диапазоне Вы пытаетесь получить на выходе, что приходится пускаться в такие тяжкие? Неужели характеристика датчика (какого?) и преобразователя до такой степени нелинейна, что не позволяет обойтись какой-либо кусочной аппроксимацией с 1-байтовой коррекцией? имхо, целочисленной 2-байтовой арифметики с промежуточными результатами в 3-байтовом виде вполне достаточно.
Ну и методическая ошибка - утаптывать задачу в приглянувшийся контроллер, а не подобрать контроллер под задачу.

На счет ошибки согласен. Но контроллер был выбран до того как поручили развели плату и сделали. Осталось писать код и подстраиваться под условия.
Точность по температуре надо 0.25% в диалазоне -50-1250. Сигнал обрабатывается от термопары(ТХА). Там для преобразования напряжения в температуру используются полиномы 6й и 9й степени. Вот и выходит что числа слишком большие выходят.

Если не нужна точность (в пределах +- 1градус) и небольшой диапазон температур, то можна обойтись и заданием температуры в виде таблицы, т.е. каждому значению АЦП - соответствующая температура с таблицы.
Итого, при диапазоне в 100 град, получится таблица в 200 байт, что очень экономно.
Удачи!!!

+1. Причем cаму таблицу можно вынести в отдельную м/с EEPROM, которую при необходимости (для снижения энергопотребления) запитать прямо от пина MSP430.

В MSP не копенгаген, но неужели нет pin2pin и функционально совместимого контроллера с 4 КБ флеша?

На память не надеюсь, но грызут меня сомнения насчет точности ТХА в диапазоне >500 C. И коэффициенты в полиноме аппроксимации ТХА, по-моему, присутствуют все, а не только 6-й и 9-й степени.
Варианты:
1) кусочно-линейная аппроксимация (с большой кучей кусочков);
2) аппроксимация 2-й степенью (на меньшем числе кусочков).
При этом Вы уложитесь в целочисленную 3-4-байтовую арифметику.
При желании внутри каждого кусочка операцию разбиения можно повторить до достижения требуемой точности аппроксимации. Н-р, первая кусочно-линейная нарезка выполняется с 1% точностью, вторая кусочно-линейная нарезка обеспечивает требуемые 0.25%; результат соответствует параболической аппроксимации, считается быстрее (на одно умножение), но таблиц будет чуть больше (с другой стороны, эти таблицы можно будет свести вообще к 1-байтовым).

Пин-ту-пин с бОльшим объемом Flash нету. Мне, если честно, тоже непонятен выбор такого МК с учетом наличия в устройстве RS485. У MSP430F2013 нету аппаратного модуля USART или USCI, поддерживающего функцию UART. Имеющийся у него модуль USI поддерживает только синхронные интерфейсы SPI и I2C.

Приглянулась мне мысль насчет кусочно линейной апроксимации после того как построил эти полиномы. Поделив на кусков 50 и записать во флеш-инфо коэффициенты, должно получиться. Спасибо за дельные советы
А насчет выбора контроллера, так вышлоо, потому что не подумали. Делали схему. Кто то сказал:"я подобное в 1к помещал" так и порешили(((

А вы на чем пишете? Судя по всему на С.
Попробуйте функции программной реализации RS-485, переделать на asm-e. Я думаю, что в этом случае, существено уменьшиться код программы и все влезет в 2 кБ, без всякой апроксимации термопары.



Но зато у данного контроллера есть 16-битный АЦП с усилителем, наверняка когда данное устройство делали, то преждевременно думали о преобразовании сигнала с термопары. А если использовать внешний 16-битный АЦП + операционник + контроллер, то схема увеличивается как по стоимости, так и по размерам.

Ну так и флаг ему в руки!
Не надо однако забывать, что в 1к флеши в 8 и 16-битных контроллерах разное количество инструкций влезает...

Код "раздувается" от включения в него библиотеки с "плавучей" арифметикой. Я не так давно тоже на это напоролся, модифицируя старый код под MSP430F2001. Включение в исходник всего одной операции деления числа float увеличило получившийся код примерно на 800 байт и он перестал влазить в этот кристалл. Тогда я вспомнил о причинах отказа от вычислений во float и переделал выражение на целочисленку. Все влезло и еще осталось. Только не нужно меня убеждать переписать весь тот проект на ASM Там коррекция всего в одной формуле была.
Ну да. Скорее всего так и было. TI что-то тут лопухнулась и в другие кристаллы этой серии с бОльшим количеством пинов и бОльшим объемом Flash модуль SD16A почему-то не включила. А зря.

Ну дык и производительность этих команд тоже разная. Там где 8-ми битнику нужно три команды на сложение 2-х байтных числ, 16-и битник выполнит ее за одну команду. Но это так... всего лишь попутное замечание. Затевать очередную локальную войнушку 8-бит МК vs 16-бит МК я не собираюсь

А эта идея с кусочно-линейной аппроксимацией ВЕЩЬ. Погрешность от полинома составила менее 0.1 градуса и места минимум надо, при том что коэффициенты во флеш-инфо спрятал.Благодарю за советы

Надеюсь, Вы сделали кусочно-линейную аппроксимацию собственно НСХ (номинальной статической характеристики) термопары ХА (Type K), а не другой её (полиномиальной) аппроксимации? В сомнение меня ввел расчет Вами погрешности кус.-лин. аппроксимации относительно полиномиальной аппроксимации.

+1. Я думал только у меня такое сомнение. ГОСТовская табличка-то немаленькая, иначе зачем бы я про отдельную EEPROM упоминал? А в область INFO только 32 4-х байтных числа помещаются.

Всю таблицу забивать в ЕЕПРОМ нужды нет - НСХ у ТХА, если склероз не изменяет, наиболее линейная по сравнению с другими типами термопар и, соответственно, ее кус.-лин. аппроксимация дается меньшей кровью.
Опуская качество выполненной автором кус.-лин. аппроксимации, остаются вопросы компенсации холодного спая (еще одной ТХА или более другим датчиком? если более другим (точность датчика?), то желательно иметь аппроксимацию T->U для предполагаемого диапазона температур холодного спая) и калибровки под конкретный экземпляр ТХА (без этого 0.25% погрешности останутся в области благих пожеланий даже при идеальной остальной схемотехнике).
Ну и совершенно неразумное предположение (надеюсь, что не так): автор выполнил кус.-лин. аппроксимацию для всего заявленного диапазона -50..+1250 С только по полиному для диапазона 0..+500 С, не учитывая, что за границами 0..+500 С этот полином даст среднюю по больнице цену на дрова.

Мда, Вы правы, я сделал аппроксимацию двух полиномов(0..+500, 500..1200 С). Можете кинуть ссылку на эти таблицы напряжений термопар, что нибудь исправлю.
Насчет сенсора холодного спая, то это внутренний датчик SD16_A в F2013. Показания он відает стабильнее, только надо его грамотно откалибровать будет. Также производится калибровка напряжений термопары для температуры холодного спая и для максимума шкалы. Так что с калибровкой не должно быть проблем.

См. выше - НСХ (номинальная статическая характеристика) термопары ХА (Type K). НСХ по ГОСТ в тырнете мне на глаза не попалась, но не думаю, что она сильно отличается от NIST-овской (в Ваши требования по точности отличия уложатся).

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

NIST-овская єто какая, что єто такое???

Напряжение смещение АЦП для внутреннего сенсора и коєффициент преобразования предполагается калибровать. Вот только, т.к. два параметра, то и две температурі надо бы брать. С этим не знаю как выйдет.

NIST - National Institute of Standards and Technology, http://www.nist.gov. НСХ для термопары ТХА (aka Type K) я предлагал Вам взять с http://srdata.nist.gov/its90/download/type_k.tab, т.к. это проще, чем искать советский ГОСТ с аналогичной информацией.

Я пытался обратить Ваше внимание на другой момент: скорее всего для получения требуемой точности придется побороться за обеспечение равенства температуры холодного спая и датчика, эту температуру измеряющего. В случае с датчиком внутри контроллера эта задачка несколько усложняется.
О калибровке. Если мультипликативная погрешность встроенного датчика температуры на краях диапазона температур холодного спая (считается по характеристикам датчика из даташита) не превышает разумной доли суммарной погрешности, то можно будет калиброваться и по одной точке в середине диапазона; если превышает, и/или характеристика датчика имеет существенную нелинейность, то придется калиброваться по 2-3-... точкам. Про всякоразные стабильности пока просто не вспоминаю.
Мне представляется, что озвученная погрешность 0.25% (какие у нее будут основные составляющие?) - это пока из области пожеланий, и никто в Вашей команде бюджетом погрешностей прибора еще не занимался.

Вопрос Автору.
Как Вы понимаете пресловутые 0.25%?
Это от максимума 1250 С? Или от текущей измеряемой температуры?
В первом случае требования к правильному измерению температуры "холодного спая" довольно легкие - 3 градуса, во втором...при, скажем, 50 градусах... сами прикиньте.

Уже прикидывал и думал об этом. Спросил у старших сотрудников говорят, что отвсего диапазона.Но при этом относительная погрешность в начале диапазона будет дейтвительно серьйозной. Но при использованой методике измерей надеюсь на погрешность в 0.2 градуса, особенно при малых значениях. Для этого потребуется точность кусочно-линейной аппроксимации, АЦП и датчика холодного спая.
За первое не волнуюсь при использовании ГОСТовской таблицы. Второе можно качественно настроить, А вот с датчиком холодного спая может быть гемор. Особенно если учесть то что написал xemul (правда я еще не все понял)




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

Мне вот кажется..., что 0.2 градуса таким способом ну никак не получится. И погрешность определения внутренней температуры кристалла, где расположен датчик, больше, и обеспечить равенство этой температуры и того места платы, куда приходит термопара, тоже непросто. И забудьте думать, что эта компенсация будет работать при 80 градусах. Никогда.
А еще огорчу - при высокой температуре (да и при не самой высокой) может потребоваться реальная калибровка термопары... Не обольщайтесь - хотя по формулам и таблицам можно вычислить температуру с точностью 100 знаков, реальная термопара обычно не знает, что должна подчиняться этим таблицам и формулам - у нее своя жизнь. Может помочь... либо если Вы сами делаете термопары из большой бухты, или купите готовые, которые сделаны также из одной партии проволоки.
Тогда может один раз одну можно прокалибровать, а остальные только проверять в одной или паре точек. И, возможно. корректировать.