Interpretator poleceń. Cięzko cos takiego napisać ?

[BlackJack]

Chciałbym sobie napisać interpretator poleceń, który pozwoli w EEPROM stworzyć coś na wzór pliku Config.sys. Dane zapisane jako znaki ASCII.

Teraz jak to zrobić ?

Na pewno jest mi potrzebna jakaś tablica char, do przetwarzania danych.

Polecenia to tablica stałych, przy czym chciałbym, sobie to nieco uprościć, że np, polecenie zaczyna się i kończy znakiem $. Instrukcja więc wyglądałaby tak:

$F_TSOP$=36000 -> ustaw częstotliwość nośną na 36KHz.

$Motor_1$=2000 -> częstotliwość PWM dla silnika 1 2KHz

Język programowania zgodny ANSI C.

Po co mi to ? Chodzi o to żeby łatwo i szybko dało się przekonfigurować robota, bez dłubania w kodzie programu, tylko wgrywając nowy plik do EEPROM.

[Mechano]

Zerknij na ten projekt, może coś pomoże:

http://leon-instruments.blogspot.com/2011/03/avr-spectrum.html

[MirekCz]

A po co dokładnie Tobie to jest?

Jak masz tylko w eeprom wpisywać jakieś dane to jest sens robić to w tekscie? (ile procesor się namęczy, żeby to rozkodować?)

Nie łatwiej ustalić strukturę z ilomaś unsigned int, gdzie będziesz trzymał wszystkie dane i tylko do niej "zgrywać" dane z eeproma?

Do tego możesz napisać prosty kod pod windowsa do generowania danych do wgrania w eeprom wg. struktury...

[BlackJack]

Tak jak piszesz już kiedyś robiłem, sprawdza się to.

Natomiast forma tekstowa ma pewną zaletę, nie musisz, dokładnie znać wartości dla rejestrów, podajesz tylko parametry, a te są różne 8, 16, czy nawet 24 bitowe.

Po drugie użyjesz dowolnego edytora TXT, do edycji na kolnie parametrów.

Po trzecie, dane do EEPROMa możesz łatwo wgrać choćby przez RS232, w robocie, bez konieczności posiadania programatora pod ręką. Oczywiście warunek że system taką opcję ma.

Zaleta. Przykładowa sytuacja.

Na zawodach chcesz szybko zmienić jakieś parametry systemu. Nie masz lapka. jeżeli masz w robocie rs232, lub nawet USB (coraz popularniejsze), pożyczasz od kogoś na 5 minut lapka, sklecasz nowy plik Config, na kolanie, wgrywasz, i masz gotowe. Nie musisz ze sobą tachać programatora, kodu źródłowego etc.

Owszem, taki translator z TXT, na config sys zajmuje sporo pamięci CPU, ale właściwie tłumaczy dane tylko raz, podczas startu systemu.

Ja chcę rozszerzyć swoją wiedzę i horyzonty, a jak przy okazji powstanie użyteczny podsystem czy nawet RTOS, czemu nie ?

[GAndaLF]

Mi też chodziła po głowie koncepcja zapisywania danych w postaci plików tekstowych z których będzie potem czerpać kod. Koncepcję można wykorzystać na wiele sposobów. Poza skryptami konfiguracyjnymi wczytywanymi podczas działania programu myślałem też o skryptach generujących na podstawie metadanych jakieś pliki .c i .h. Dzięki temu można uniknąć błędów w stylu "zmieniłem kod w 5 miejscach ale zapomniałem o jeszcze jednym i straciłem 5h na debugowanie". Niestety nie miałem jeszcze okazji konkretnie przysiąść do tematu i nie mogę zaoferować gotowych rozwiązań. Myślę jednak, że może zainteresuje Cię coś takiego:

http://www.gnu.org/software/bison/

Podobno jest to narzędzie do tworzenia parserów odczytujących pliki napisane według składni którą sami sobie możemy zdefiniować. Bison jest narzędziem open source, więc zawsze możesz ściągnąć kod i zaczerpnąć tylko niektóre koncepcje.

[BlackJack]

TZN. ja się nie chciałem rozpędzać tak jak kolega wyżej, ale możliwości, robota wyposażonego w taki Shell, mogą być spore, można go np, przeprogramować z Smartfonu czy Tabletu, wysyłając mu plik napisany w notatniku, przez Bluetooth.

Oczywiście stworzenia takiego systemu operacyjnego to juz jest większe wyzwania, niż prosty interpretator konfiguracji.

Co do samego programu to znalazłem trochę kodu z/dla UNIXA. I wg. tej idei stworzenie Shella nawet w BASCOMie powinno być wykonalne.

int main()
{
 char buf[1024], *args[64];

 while (koniec == 0) {

   cout << "Command: " << flush;


   if  (cin.eof()) {
     cout << endl;
     return 0;
   } else {
     cin.getline(buf, sizeof(buf));
   }

   if (strlen(buf) == 0) 
     continue;

   if(buf[0] == "exit"){
       koniec = 1;
   }

   parse(buf, args); //funkcja dzielaca strumien danych na czesci
   execute(args); // funkcja, ktora wykonuje aplikacje w srodowisku Unix/Linux
 } 
}

[OldSkull]

Pomysł jest ciekawy, sam się z czymś takim spotkałem i tam umożliwiało jeszcze tworzenie instrukcji warunkowych, pętli, ładowania danych itd. oczywiście w ograniczonym stopniu, ale jednak. Można np. napisać tak, aby dało się uruchamiać później wybrane funkcje