Arduino.ru

Я в свое время брал FEZ Panda II

Именно потому что C# мне гораздо "роднее" чем C/C++. Это мой основной язык, но....

В итоге так и валяется уже два года. Дальше "помигать диодом", как-то не пошло. Так ни в одном проекте и не применилось.

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

Поддержка шилдов/библиотек - на порядок меньше. Да и само сообщество - не сравнить (а это - ой как важно).

Да и просто те вещи которые в Arduino двумя строчками.... 

Да и, если разобраться, многопоточность не такой уж и благо. Без него все гораздо предсказуемей/проще. Нет проблемы с блокировками, с тем конкрутным доступом и т.п. Вообщем без многопоточности скетч гораздо вероятней "либо работает, либо нет". А с многопоточностью "вроде работет, но это ничего не значит".

По памяти тоже: никогда не знаете сколько у вас ее будет. Когда GC соизволит запуститься (и сколько времени это займет).

Бизнес логику писать. Со всякими абстракциями, паттернами, универсальными решениями - это конечно без вопросов. C# тут рулит. Хоть и обкусанный. Да и возможность подебагать прямо в камешке - слезы умиления вызывает.

Только, может у меня так сложилось, да вот такой сложной бизнес логики, где без мощи C# жить нельзя - ну как-то не придумывается для микроконтроллера. В принципе все что нужно, спокойно хватает средств C/C++

А по памяти... ну на atmega8 было что "не влазит" (и то влезло после "подпила"). А вот что-бы 328-камня не хватило - не помню. Главное что жрет - это строки. А в микроконтроллере - как-то не очень они и нужны. Да PROGMEM никто не отменял (я изначально, обычно их туда не пихаю. А когда "память кончилась", я сразу знаю за кого браться. Если не кончилась, так и делать ничего не нужно).

Оно "память жрет" - на старте. Когда всякие библиотеки подключаешь. А потом память расходуется довольно экономно. Компиляторы нынче умные стали.....

Панда да, смешная штука:) я на нее еще года поллтора назад смотрел, так то с# мне тоже ближе. Собственно свои рабочии задачи на нем и решаю. Вот и стало интнресно. Сечас микро дот нет сильно прожвинулись . Посмотрим, как будет выглядеть мой прожект на с, с#  и под rtos. Этож жутко интересно. :) просто есть ощущение, что то, надчем я копья ломаю по не знанию С месяц, на шарпе я сделаю за день...

А про 328ю, ну так я подключил софтсериал, описал в структуре 10 строк с АТкомандами в массив и привет, 42% ram улители, приписал к массиву  прогмем, стало 38% ...  Куда это годиться? Я еще основной код кодить и не начинал... А мозг уже кончается ;)

То ли дело сортекс м4

>42% ram 

Хе, хе... а как вы это узнали? Возможо и не RAM это вообще был :)

Да и если RAM, не так уж и мало осталось для "собственной логики". Особенно если не пытатся подрубить все что можно и не можно. String там всякие, библиотеки там где одного millis() достаточно и т.п.

>Частота: до 168 МГц

То есть платку, самому, если что сделать будет позабористее.. :)

>Память программ (Flash): 1 МБайт

Да все верно, только расход-то памяти у CLR будет-то побольше. И на уровне самого кода и сам рантайм куда-то упихарить нужно..

Кстати поэтому и те 168 MГц, это совсем не те же самые МГц которые вы бы имели на С++

>Поддержка инструкций DSP и чисел с плавающей точкой

Как вы из CLR будете исользовать эти самые DSP?  До тех же таймеров из CLR добарыться нужно...

Да банально, я честно говоря сильно в глубь не закапывался, но.... скажем описал я struct. Я четко знаю сколько она занимает места. Прочитать из Serial я могу ее банальным Serial.readBytes(&myStuct,sizeof(myStruct_t)); Без распарсиваний типов и т.п.  (то же самое бинарно запихнуть кусок памяти в файл, eeprom и т.п.)  . Скопировать структуру, могу опять-таки memcpy. Вообщем в C/C++ я знаю где лежит и что происходит с каждым байтом.

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

Или тот же самый int. Сколько он у вас в памяти занимает?  А фиг его знает. Нужно еще внимательно смотреть кто он сейчас value значение, или где-то случайно boxing к нему применился.

Или строки. C-шную строку, просто взял и отослал куда тебе нужно. А сишарпную?  Ну для начала вспомнить что она UTF16. (а всякие модули, GPS, модемы врядли про него знают). Так что еще про энкодинги и трасформации в byteArray() не забыть и правильно сделать. Да еще нолик в конце, возможно, не забыть....

Вообщем-то все, конечно, решается. Возможно дело привычки. Когда привыкнешь - все решается само-собой. Только, когда эти проблемки вылазят там где у C/C++ вообще вопросов не возникало - раздражает.

Или вот, скажем простеший ардуино код:

loop(){
  PORTB=1;
  delayMicrosesconds(50);
  PORTB=0;
  delayMicrosesconds(50);
}

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

Вообщем мое IMHO кортекс конечно сила. Только все равно лучше уж C/C++ что-бы выжать из него всю его мощу. Если она требуется. А если не требутся, то зачем он? Для большинства "самоделок", его моща совершено излишня (зато тянет за собой сложность). Для многих, даже mega8/328 излишня. Народ регулярно, после того как отладил на дуинке, впихивает решение в тиньки. 

Или скажем не хватает выводов. Учитывая цену и простоту разводки втыкнуть рядом еще один камушек (тини или mega8) скажем для работы с клавиатурой матричной или энкодить PPM-мы (скажем плата мега-пилот) - не проблема. А второй кортекс? Или брать один кортекс и одину mega?  Можно конечно. Только... два однотипных полюбасу проще будет чем два разнородных.

Так что мне кажется C/C++ для "железных задач", все-таки более подходит. И для 90% самоделок 328 хватает за глаза. Еще 8% - сможет mega1280/2560  (я скажем первой платой тоже купил мегу. что-бы не чувствовать себя "стесненным". по итогу за 3 года, в боевом проекте - ниразу не потребовалась. ни по памяти, ни по количеству выходов).

Возможно во мне говорит "привычка". Думаю на 80% обусловленно "каждый кулик свое болото....". Но вот у меня MF как-то "не пошел".

Как-то заломало разбиратся с этими PortingKit  (при все простоте ардуиновоского boards.txt и variants для поддержки нового камня..) и т.п.

> воткнул туда clr

Кстати, а не дадите ссылочку по какой инструкции делали это? Как в голый камень запихнуть? В свое время одним из стопоров было "в DIP корпусах не бывает, трудно будет самому плату сделать". Но вот, на днях, жизнь заставила учится своими криворучками пересадить 32u4 в VQFN корпусе с платы на плату (это у короторого ножек вообще никаких нет). Так что TQFP меня теперь совсем не пугает. Я теперь смелый :). Возможно, с вашей подачи, все-таки смогу заново полюбить "не оправдавшего надежд".

P.S. Поискал у нас, скажем ATSAM4SA16B что-бы хоть цену глянуть.... вообще нет. Отладочные платы еще можно найти, а голый камень.... :(

P.S.S. Пришло таки в голову куда панду можно заюзать (раз все равно валяется). Можно попробовать из нее осцыл сделать. Одна из немногих задач где "чем больше памяти тем лучше".

Пожалте сцылку :)

http://singularengineer.com/stm32f4-discovery-board-running-net-microfra...

Я не говорю, сто C# это выбор полковника, мой выбор скорее всего (ПОКА НЕ ПРОБОВАЛ ПРАВДА ), это RTOS  на кортекс (есть кстати платки и с А9, туда хоть винду можно поставить :) )  просто уж очень охото помучать зверька с шайпеем :) Особонно заценить работу с железом, в моих то задачах тру тайминг не так то и нужен, да "время принятия решения :) " от секунды :) 

Да и некто не отменял работу с stm23 на С\С++, кроиме того есть занимательный проект MAPLE, точная копия ИДЕ адруины со свеми гвонокотылями, типа DigitalWrite, AnalogRead ...

198 Мгц на С# превратятся в 47КГц, это уже проверяли... 

> хе, хе... а как вы это узнали? Возможо и не RAM это вообще был :)

AVR студия так смне говорит, и новая IDE от ардуины,  1.5, тоже умеет сразу говорить, скока места занято...на флеш и в раме...

>Нужно мне было как-то тупо выдать на ногу пульсы с нужной частотой. С тестовыми целями. А второй ардуины небыло под рукой. >Только панда... Уж не помню деталей, но на .net для этого таки пришлось гугл помучать. И вот так "лобово", так и не нашел >решение (таймер там пришлось заюзывать и т.п.).

вот классика блинкинга :)

public static void Main() {

OutputPort led = new OutputPort(Cpu.Pin.GPIO_Pin1, false); //PA1 on discovery board

while (true) {

led.Write(true);

Thread.Sleep(500);

led.Write(false);

Thread.Sleep(500); }

}

тут же сразу и многопоточность в чистом виде, поддерживаема кортексом на уровне ядра..

За ссылку - спасибо. Только как я понял, она предполагает наличие платы Discovery. У которой, как я понял уже на борту есть куча железа... в том числе и программатор встроенный (ST-link). А вот как "с нуля", голый... Сделать что-то типа "минимальная ардуина", только на STM32U4 - я пока не понял (впрочем не очень и старался, скорее "обзорное любопыство").

>вот классика блинкинга :)

Угумс. Да только у меня-то delayMicrosesconds(). Я ведь, из вредности, не случайно не delay() использовал :)

 Да прямой вывод в порт. А это значит, что была возможность ОДНОВРЕМЕННО выставить состояние нескольких пинов. А ситуации когда это требуется, хоть и не часты, но вполне жизненны (лично сталкивался).

Понятно, что в итоге "все возможно", но... мозг хмурить для этого нужно :(

> гвонокотылями, типа DigitalWrite, AnalogRead ..

По сути согласен, но уже чисто из формализма, как тогда вы назовете "new OutputPort(Cpu.Pin.GPIO_Pin1...". Если уж то "говнокостыли", то что это? И ведь фунционально, это даже не digitalWrite. В него еще совместимость между разными камнями запрятана. А у вас тут Cpu.pin, так что, для того что-бы сделать "функционально аналогично", нужно еще один слой абстракции над этим навернуть.

>тоже умеет сразу говорить, скока места занято...на флеш и в раме... 

Честно говоря, я себе не представляю как можно это сразу сказать, без умения засылать темпоральные зонды в будущие. Так что либо это, все-таки не про RAM речь идет. Либо это метритка типа "плюс/минус" пол километра.

Вы не очень старайтесь меня переубедить. В душе-то я C# люблю ;)  Один дебагинг - бальзам на душу. Вот только... если смотреть с точки зрения "инвестиций времени", по крайней мере пока, ROI от MF достаточно низок (если не ноль). Работу/заказы, если что - шансов найти мало. Так что только "для души". Но IMHO идеально это когда "для души", при потребности, может кормить.

Так и оказалось.

"Global variables use 151 bytes (5%) of dynamic memory, leaving 2,409 bytes for local variable"

Что вообщем-то как-то объемом RAM назвать трудновато. В лучшем случае "часть его". Но польза от этого - весьма не велика. В лучше случае позволит отлоивить ГРУБУЮ ошибку, что-то типа попытки объявить массив типа byte ar[1024][512];

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

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

Про костыли, я больше про MAPLE, по сути копию Wiring тока под stm32, уних даже есть своя нано:) в том же формфакторе, и основная плата в формфакторе Уно. Даже шелды ордуновские подходят вроде. Но есть и свои. 

ТО, что написанно в C# это есно абстракция абстракций :) 

>Угумс. Да только у меня-то delayMicrosesconds(). Я ведь, из вредности, не случайно не delay() использовал :)

ну так то там и не  ардуиновский делей, там как раз тормаджится один из потоков, не мешая другому коде, если он естсь.. это законно в C# :)

Если разберете вот как их ОДНОВРЕМЕННО использовать. Где нужно (доступ к железу) - нативный, где логика вернего уровня C# - раскажите. 99% что это возможно, но мне "побырику" это не удалось.

Ну, для примера, скажем TLC5940:

С# - TLC5940 Driver for Netduino - Source Code

C++ - Tlc5940.cpp - tlc5940arduino - An Arduino Library for the TI TLC5940 16-Channel PWM Chip - Google Project Hosting

Сравнение конечно "не совсем корректное". C++ вариант по полному юзает аппаратные таймеры (но и софтовый вариант там тоже есть. "два в одном"), а C# скорее софтовое (и не спроста. в камне-то они есть, а вот добраться до них из CLR еще попробуй).

Да и в C++, как на мой вкус много где "ну нафига так заковыристо?", но общие представление составить можно.

Угу. Вот про это и речь. Как бы своих "тараканов в голове" при переезде в новый город с собой не перевезти. Привычки большого PC на камушки малые. В этом голый C и слабый камушек и хорош. ЗАСТАВЛЯЕТ в этом монастыре креститься так как тут принято, а не тащить свои привычки :)

Расширить кругозор ;)

>>Если разберете вот как их ОДНОВРЕМЕННО использовать. Где нужно (доступ к железу) - нативный, где логика вернего уровня C# - раскажите. 99% что это возможно, но мне "побырику" это не удалось.

не претендуя на оригинальность, DDL ??

А что это?  

Если имелли ввиду .DLL, то... это же не ответ. Понятно что все в итоге у нас .DLL только разные же они :) И весь этот маршилинг и т.п.... взрывается мозг.

В качестве оффтопика:

Использовать STM32F4, чтобы запустить .Net - да я бы застрелился, уж тогда лучше брать сразу машинку с линухом и не парить себе одно место. Типа таких: http://starterkit.ru/html/index.php (надеюсь не убьют за рекламу, у меня этим знакомый занимается).

Хотя лично я не имею желания скрещивать МК и линукс - это не для меня, мне интересней быть поближе к нарожелезу :) Ногодрыг, периферия (DMA,SPI и т.п.). Но это моё, люди же играются с линухом на МК.

Я ненавижу линукс, не знаю за что :)

А что плохого в дотнете на Кортексе :) , я писал, можно платку , размером  меньге МЕги с А8 взять, за 50 баксов... 

Я пот счас как раз нативный код С++ использую что бы oneware далласы подключить, может скоро заработает... и да, ближе к жезезу оно так, оно на МК и нужно так... он же, МК перефиреекй управляет, а не в воздухе как макетка висит...

кста, на кортексе int 4 байта, как и long, это одно и тоже, и есть long long, 8 байт :)

> Понятно что все в итоге у нас .DLL только разные же они :)

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

Может у нас разные понятия о "несложности".

Я вот читаю что-то типа Using Interop in the .NET Micro Framework V3.0 - Embedded Musings - Site Home - MSDN Blogs и офигеваю от количества телодвижений нужных для того что-бы банально к памяти доступиться (а что будет когда мне функции, с параметрами передавать вызвать захочется туда/обратно? да callback разные :()

Не, когда "очень нужно", то можно пройти весь этот квест. Но когда хочется "побырику новый датчик пощупать (возможно этот код через пол часа выбросится за ненадобностью), а библиотек MF-фовских для него нет", то.... три раза подумаешь, нужно ли оно тебе. Или, в крайнем случае забъешь на все эти "12 таймеров", DMA, набортные I2C и т.п. и будешь софтверно ногами дрыгать. Авось частоты хватит и вытащим все это грубой силой.

У GHI, правда есть какая RLP, предназначенная для общения с Navie Documents - RLP - GHI Electronics

Выглядить попроще в юзании

Но, насколько эта фишка именно Вендор-специфик я не очень понял. Плюс там в примерах используются какой-то левый тулчейн/IDE. Не очень понятно чем обусловлено его использование. Платностью VisualStudio или только он имеет поддержку этого RLP.

Вот я счас качаю SDK от это GHI, под VS и кортекс М4, жа посмотрим, какой это кортекс...

В общем, тепловой насос уже запущен, а контроллера итаки нет :)  приходиться игры с stm32 отложить и продолжить мазохизм с 328 :)

вот шо ми меем

#include "leOS2.h"
#include "pt.h"
#include "DS18B20.h"
#include "OneWire/OneWire.h"
#include "EEPROM.h"
#include "SoftwareSerial.h"

#define LC_INCLUDE lc-addrlabels.h

#define NUMITEMS(arg) ((unsigned int) (sizeof (arg) / sizeof (arg [0])))

#define DEBUG true
#define ENABLE_GPRS true

#define _interval_gprs_conenction 10000
#define _interval_sensors_reset_values 1000
leOS2 scheduler;
SoftwareSerial SimSerial(8, 7);
  const char* mesg = "fucking test ";
	typedef struct
	{	const char* command;
		const char* reply;
		int delay;
	} c_GPRS;
  const c_GPRS c_gprs_commands[]  = {
	
			{"AT+SAPBR=3,1,\"CONTYPE\",\"GPRS\"","OK",1000},
			{"AT+SAPBR=3,1,\"APN\",\"internet.beeline.ru\"","OK",1000},
			{"AT+SAPBR=3,1,\"USER\",\"beeline\"","OK",1000},
			{"AT+SAPBR=3,1,\"PWD\",\"beeline\"","OK",1000},
			{"AT+CIPSTART=\"TCP\",\"46.47.194.2\",\"34567\"","OK",1000},
			{"AT+SAPBR=2,1","OK",1000},
			{"AT+SAPBR=1,1","OK",1000},
			{"AT+SAPBR=2,1","OK",2000},
			{"AT+CIPSEND","OK",7000},
			{mesg,"OK",1000},
			{"\032","OK",1000},
			{"AT+SAPBR=0,1","OK",3000},
			{"AT+SAPBR=2,1","OK",3000},
		{"AT+SAPBR=2,1","OK",3000}
			
	};


uint8_t _iterval_gprs_check = 0;
uint8_t _iterval_sensors_check = 0;
uint8_t _set_iterval_gprs_step = 0;

static struct pt pt1, pt2, pt3;

static int _main(struct pt *pt, int interval) {
	static unsigned long timestamp = 0;
	PT_BEGIN(pt);
	while(1) {
		PT_WAIT_UNTIL(pt,millis() - timestamp > interval );
		timestamp = millis();
	Serial.println(1);
	}
	PT_END(pt);
}

static int _console(struct pt *pt, int interval) {
	static unsigned long timestamp = 0;
	PT_BEGIN(pt);
	while(1) {
		PT_WAIT_UNTIL(pt, millis() - timestamp > interval );
		timestamp = millis();
	    Serial.println(2);
		
	}
	PT_END(pt);
}
//-------------------------------------------------------------------------------
uint8_t i = 0;
c_GPRS _command;
uint8_t reply = 3;
char buffer[64];	// buffer array for data recieve over serial port
uint8_t count=0;     // counter for buffer array


static int _module(struct pt *pt, int interval) {
	
	PT_BEGIN(pt);
	
		while(1){
			
	    PT_WAIT_WHILE(pt,_iterval_gprs_check == 0 && ENABLE_GPRS);
		
		if(DEBUG) Serial.println(3);
		

		for (i ; i <= NUMITEMS(c_gprs_commands); i++ ){

	    while( SimSerial.available() > 0) SimSerial.read();	

		      _command = c_gprs_commands[i];
			 
			  SimSerial.println(_command.command);
			 
			  scheduler.modifyTask(set_iterval_gprs_step, scheduler.convertMs(_command.delay));
			 _set_iterval_gprs_step = 0;
			
			  while(SimSerial.available())         
			  {
				  buffer[count++]=SimSerial.read();   
				  if(count == 64)break;
			  }
			  
			  if(DEBUG)  Serial.write(buffer,count);   

			  if (strstr(buffer, "ERROR") == NULL)
			{
				return 0;
			}
								
			if (strstr(buffer, _command.reply) != NULL)
			{
				reply = 1;
			}
			if (strstr(buffer, _command.reply) == NULL)
			{
				reply = 0;
			}
		
		 PT_WAIT_WHILE(pt, _set_iterval_gprs_step == 0 || reply == 3);
		
			  count = 0;
			  reply = 3;
			 
			  
	    } //for
		 scheduler.modifyTask(set_iterval_gprs_check, scheduler.convertMs(_interval_gprs_conenction));
		_iterval_gprs_check == 0;
	  
	}//while
		
	PT_END(pt);
	}


void setup()
{
	Serial.begin(19200);
	scheduler.begin();
	scheduler.addTask(set_iterval_gprs_check, scheduler.convertMs(_interval_gprs_conenction));
	scheduler.addTask(set_iterval_gprs_step, scheduler.convertMs(1000));
	
	SimSerial.begin(115200);              
	delay(500);
  	SimSerial.println("AT+IPR=19200");    
	delay(500);
	SimSerial.begin(19200);               
//	delay(1000);
//	SimSerial.println("ATV0");
//	delay(500);
   
	
	PT_INIT(&pt1);
	PT_INIT(&pt2);
	PT_INIT(&pt3);
	
}

void loop()
{
	
	_main(&pt1, 2000);
	_console(&pt2, 1000);
	_module(&pt3, 2000);
	
	
}


void set_iterval_gprs_step ()
{
	_set_iterval_gprs_step = 1;
	
}
void set_iterval_gprs_check()
{
	_iterval_gprs_check = 1;
	
}

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

Пошла "тяжелая артиллерия", пора отсюда валить :) Теперь это leOS, Protothreads. Выглядит как студенческий суп, положили всё, что есть в холодильнике. Наверное можно так использовать систему, но бесплатные грабли обеспечены. А что именно не работает? Зачем делать такой замес из RTOS & Protothreads? Почему нельзя всё сделать в одной системе, либо там либо там?

Да не, леос просто шедулер,который не занимает системные таймеры, (у меня 6 ШИМов) а использует таймер вочдлога.

А протопотоки они настолько легковесны, что можно сказать их и нет... 2 байта на поток :)

Так что, ниче тяжелого... И почему суп ? ну можно было считать интервалы типа  ((millis() - previous) < _command.delay

так и было, но разницы то нет особо ... 

а с флешем .... глупая какая то ошибка, счас снова сделаю и выоложу, может увидите...

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

	

		for (p_Index ; p_Index <= NUMITEMS(c_gprs_commands);p_Index++ ){

		lp_Ptr = (uint8_t *)pp_Data;
		
                for( uint8_t i = 0; i < sizeof(c_GPRS); ++i, lp_Ptr++ )
		{
	(*lp_Ptr) = pgm_read_byte( ((uint8_t *)&(c_gprs_commands[ p_Index ])) + i );
			
		
		}


	    while( SimSerial.available() > 0) SimSerial.read();	

		    //  _command = c_gprs_commands[p_Index];
			 
			  SimSerial.println(pp_Data->command);
			 
			  scheduler.modifyTask(set_iterval_gprs_step, scheduler.convertMs(pp_Data->delay));
			 _set_iterval_gprs_step = 0;

ну это же бред... выводит ахинею, что понятно

Одно не понимаю, зачем наступать столько раз на одни и те же грабли? Кто сказал, что во Флеше можно хранить указатели на ОЗУ? Я же пример приводил (в другой теме, откуда всё началось, вряд ли найду), если не ошибаюсь, что отдельно массив строк, а отдельно структура со ссылками на строки из этого массива.

Лично я как делаю. Мне нужно решить задачу. Я мысленно разделяю её на элементарные части, которые можно проверить раздельно и каждую обкатываю на примерах, пробую, чтобы всё получилось и, самое главное, я понял, как это всё работает. А уже потом соединяю всё это в одно велико творение, в единый говнокод, так сказать.

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

Вы правы :)

Я зачем то у TI заказал пару плат с Ethernet на борту (TM4C129), правда что то долго отгружают, надеюсь к отпуску привезут.
А если по теме, то как же там проще с флешем, написал const и забыл, что оно во флеше, а здесь столько гемора с этим.

Хотя есть хорошая на эту тему басня Крылова. В смысле если руки не из того места растут, то хоть Texas, хоть STM, хоть Ардуино ;) Это я вцелом, философски, а не про Вас.

Я как то залез в эти Protothreads, прикольно, но есть довольно большие ограничения, да и не совсем тривиально. Короче для простеньких вещей. В общем не прижились они у меня. RTOS пока вообще нигде не нужны были. Конечно в каждом отдельном случае - свои грабли и проблемы, так что понятно, приходится иногда выкручиваться как попало. Чаще всего вместо этого пишется конечный автомат, который эту кучу разгребает. Хотя его отлаживать - еще та гора туалетной бумаги. Впрочем если блок-схему нарисовать заранее, то полегче. Я вон на курсах от Техасса писал по лабораторной один перекресток с тремя светофорами и тремя датчиками, весело было (в смысле нужно заполнять массив состояний и переходов). В конечном итоге сделал, конечно. Еще бы сразу было понятно, что у них совсем по другому светофоры переключаются (пешеходные), а то пришлось поскакать с бубном.

:)

Ну, на досуге я разберусь с ПРОГМЕМом, в моем случае , с массивом АТкомманд он дает экономию в 3 %, так что не до него... оставлю на сладкое, и кстати, данные по датчикам , адреса и метки (имена) я решил писать в ЕПРОМ. Что же касается протопотоков... по моему простейшая штука, позволяющая не накладно стуктуризировать код, примитивная ? конечно. НО а что еще надо ? это же не РТОС, даже не шедулер (я вообще не понимаю, почему каждый , кто навоял примитивный шедулер сразу его нарекает РТОС :) ), это по сути выделенный кусок кода с хитрым применением CASE :) , то что локальные не сохраняются, бесит конечно :)

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

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

А то вы кидаетесь в "прочитать char объеты из массива структур в структуру и развернуть ее членов", а какие подзадачи для этого нужно выполнить - не представляете. Когда вы в структуре пишите объявляете поле типа char* что же в нем хранится явно не понимаете. Поэтому не можете и свою задачу на подзадачи разбить. Потому что "базовые кубики" не освоили.

Это не говоря уже про то, что я например ТОЧНО понять что означает "прочитать char объеты из массива структур в структуру и развернуть ее членов" - не могу. Компилятор - тоже. Вы, в таком же состоянии...

Вообщем заведите себе две переменных:

char* str1="my string";
char* str2;

И поиграйтесь с ними. Скопируйте str1 в str2. Так что-бы они указывали на одну и ту же строку. Что-бы меняя "my string" у вас менялось и то что выводит str2. Потом, наоборот. Что-бы "my string" менялся, после того как его скопировали в str2, а serial.println(str2); по прежнему выводил "my string".

Вообщем разберитесь чем отличает "скопировать указатели", от "скопировать содержимое памяти куда указывает указатель" (соотвесвенно возникнет вопрос "куда копировать будем"). Потом то же самое только str1 в PROGMEM  (заодно и про PSTR узнайте).

А уж потом и внутри структур пользоватся строками учится.

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