command interpreter

Waarom wil je een command interpreter hebben?
(command interpreter als alrernatief van compiler)

ik wil een board maken waar in de firmware de algemene functies staan.
en een pc applicatie/ GUI moet dan de functies kunnen oproepen.

via usb sturen we dan telken een pakket van 64bytes op.
In deze 64 bytes moet het commando + parameters instaan

Je bedoelt eigenlijk een command parser...

Ik zou voor serieel over usb gaan. Zou dan een arduino nemen. Zijn erg veel voorbeelden te vinden op internet.

Nou dat is nogal makkelijk te bouwen.
Je kent alle commando's en subcommando's plus de bijbehorende parameters.
Door jouw opbouw moeten de parameters overigens wel in een vaste volgorde staan die bij zender en ontvanger bekend is.

Geef nu elk commando en subcommando een waarde die in een byte past.
Vul de waarde van het commando in in byte 1, subcommando in byte 2.
Vervolgens de parameters in byte 3 en verder.
Aangezien je weet hoeveel parameters je gaat versturen is byte0 heel eenvoudig te berekenen: 2 + aantal parameters.

Voor de CRC mag je zelf wat bedenken.

Overigens lijkt de lengte van 64 verdacht veel op een USB Hid packet. Als dat zo is het je maar 63 bytes ter beschikking omdat byte0 al gereserveerd is (0).

Aan de ontvangende kant vlooi je de boel weer uit:
commando, subcommando en dat dan aanroepen met de parameters.

Als het commando is een ADC meting te doen wil je vermoedelijk ook wel wat met het resultaat...same difference

Appeltje, eitje.

Ik doe liever niet meer binary commandos. Gewoon een "command interpreter"!

Ik maak een lijstje met "naam commando" en "functie die dit commando afhandelt". Evt. met een help-text er bij. (een help functie print dan alle commandos in de commando tabel met de helptexten). Dit is ook een vorm van "documentatie", dat je "live" de lijst van commandos kan opvragen.

Er is dan een centrale functie die het eerste woord op de regel als commando interpreteert, de "argv" klaarmaakt en dan de functie aanroept. (die aangeroepen wordt als normaliter een "main", en dus aan argv[1] enz kan refereren. ).

Dit kost iets meer processing power en geheugen van de microcontroller dan een binary protocol, maar dat zijn dingen die je tegenwoordig vaak zat hebt....

Op 21 februari 2017 16:11:55 schreef hadv:
Nou dat is nogal makkelijk te bouwen.
Je kent alle commando's en subcommando's plus de bijbehorende parameters.
Door jouw opbouw moeten de parameters overigens wel in een vaste volgorde staan die bij zender en ontvanger bekend is.

Geef nu elk commando en subcommando een waarde die in een byte past.
Vul de waarde van het commando in in byte 1, subcommando in byte 2.
Vervolgens de parameters in byte 3 en verder.
Aangezien je weet hoeveel parameters je gaat versturen is byte0 heel eenvoudig te berekenen: 2 + aantal parameters.

Voor de CRC mag je zelf wat bedenken.

Overigens lijkt de lengte van 64 verdacht veel op een USB Hid packet. Als dat zo is het je maar 63 bytes ter beschikking omdat byte0 al gereserveerd is (0).

Aan de ontvangende kant vlooi je de boel weer uit:
commando, subcommando en dat dan aanroepen met de parameters.

Als het commando is een ADC meting te doen wil je vermoedelijk ook wel wat met het resultaat...same difference

Appeltje, eitje.

Appeltje, eitje inderdaad

Maar we zitten in de brainstorm/ontwikkelingsfase.
Dus hadden we graag een beginnende documentatie.. bvb welke commando`s bestaan, welke byte wat betekend

En het moeilijke is: hoe schrijf je dit nu op?

Op 22 februari 2017 09:01:28 schreef falaigai:
[...]

Appeltje, eitje inderdaad

Maar we zitten in de brainstorm/ontwikkelingsfase.
Dus hadden we graag een beginnende documentatie.. bvb welke commando`s bestaan, welke byte wat betekend

En het moeilijke is: hoe schrijf je dit nu op?

Gebruik zelf vaak viso voor dat soort dingen. Je kan ook kijken naar b.v. UML tools om het een en ander te documenteren. Daarnaast wil een A3 papierenblad ook goed helpen.

Opschrijven of typen is gemakkelijk.

Je wilt een command interpreter schrijven om, via usb, van een PC commandos te sturen naar de firmware in een nog te maken board?

Vind ik lastig.
Een board koop je, bijv. Arduino of Rasberry. Eventueel gebruik je een losse micro controller. Afhankelijk van wat dat board, en o.a. hoe snel, iets moet doen.

Het eerste idee met binaire data is wel gemakkelijk te decoderen in de microprocessor, maar lastig aan te maken in de PC. Daar wil je namelijk snel even kunnen testen zonder eerst een interface programma te hoeven maken.

Als je commando's text gebaseerd zijn, afgesloten met [Return], dan kun je gewoon een terminal programma openen en commando's intikken. Er zijn nogal wat van die terminal programma's beschikbaar. In arduino IDE zit er ook een ingebouwd.

Zoeken naar standaard commando set is tamelijk zinloos volgens mij. Die zijn per applikatie verschillend en meestal is weinig documentatie beschikbaar.

Voorbeeld voor commando's
"DAC 3,120"
- Zet DAC channel 3 op 120.
"DAC 3 SINUS 1000,20,100"
- Start sinus generator op Dac channel 3, f=1000Hz,Amplitude 20, Offset 100.
"ADC START 4"
- Start Adc conversie op channel 4 en stuur resultaat naar PC
"ADC START 4,10,100"
- Start conversie op Adc channel 4, en herhaal 10 keer elke 100 milliseconden.

Je hebt dan in de micro een parser nodig die 'woorden' en 'getallen' uit een commandoregel kan halen.

heb er zojuist eentje gemaakt voor arduino:

Elk commando is 10 bytes lang:

[commandonr][par1_lo][par1_hi].....[par8_lo][par8_hi][checksum]

Daardoor makkelijk te parsen. Er zijn max 8 parameters, die allen twee bytes beslaan. Commando's zijn er 256, meer dan genoeg. De checksum is een totaal over alle bytes 1-9 en daar de laagste byte van..

afhandeling is een gewoon case statement op het commandonr. Ontvangstbuffer is een fixed-length array...

Wat je zoekt lijkt op RPC (Remote Procedure Call) of ERPC (Embedded Remote Procedure Call)
Oftewel code aanroepen op een "ander" device. ERPC regelt dan alle communicatie voor je. (CRC weet ik eigenlijk niet) Je moet nog wel een seriële poort instellen voor je erpc.

voorbeeld Embedded RPC:
https://github.com/EmbeddedRPC/erpc

Stel je hebt de volgende functie op je controller (server)

uint32_t SetDac1(uint32_t value)
{
  Tresult result = HAL_SetDac(DAC1, value);
  if (result == HAL_OK) {
    return 0;
  } else {
    return 1;
  }
}

Dan kun je die functie gewoon aanroepen op een andere controller of pc (client)

status = SetDac1(1000);

ERPC zorgt er dan voor dat je functie en parameters worden omgezet naar een datastream (via seriele poort) en aankomen op de andere controller. daar wordt de functie aangeroepen en eventuele resultaten terug gestuurd. Die repository genereert ook Python code geloof ik. (makkelijk op de pc)
Een hoop werk om helemaal in te stellen, maar als het eenmaal werkt is het gewoon nieuwe functie toevoegen, erpc opnieuw genereren en klaar. (wel zorgen dat je server en client code in sync blijft)

Uitleg
https://github.com/EmbeddedRPC/erpc/blob/master/doc/introduction.md

Ik heb Excel gebruikt.
In cel 1 komt het commando
In 2 het subcommando
en daarna de parameters

vervolgens schrijf je de documentatie in dezelfde regel.

Deze commando's komen uit mijn USB RGB programma waarbij ik "programma's" op de PC schrijf, die vervolgens door een PIC in een EEProm laat opslaan om ze af te kunnen spelen.

"R", 0, 1, 255 ; zet de pwm waarde voor led 1 rood op 255, geen subcommando
Of, nog generieker
"L", 0, "n", pwm : zet een Led geïdentificeerd door "L" en "n" op waarde "pwm". L is de kleur van de led, n het nummer van de led.
"O", 0,0: zet alle leds uit (pwm = 0)
"W", 0, 1, 32 waarden. zet het programma van 32 waarden op geheugenlocatie 1
"E", 0, 1: wis het programma op geheugenlocatie 1
"E", 0, 255: wis alle programma's
"P", 0, 1: speel programma 1 af

en antwoord geven is even simpel:
"D", 0, 1 ; dump programma 1
antwoord
"D", 0, de bytes van het programma.

@rew: ik heb voor zowel UART als USB monitors die in staat zijn binaire waarden weer te geven. Je kunt er ook binaire waarden mee versturen. Je kunt scripts bouwen met commando's, handig voor tijdens de testfase. Verder kun je het ontvangen resultaat testen tegen een verwachte waarde.

Misschien is dit iets dat je kan gebruiken. Een Arduino library, hierbij een stukje uit de ReadMe.

*******************************************************************

# CmdMessenger v3.5

A serial messaging library for the Arduino and .NET/Mono platform

## Introduction

CmdMessenger is a messaging library for the Arduino Platform (and .NET/Mono platform). Ituses the serial port as it's transport layer**

The message format is:
```
Cmd Id, param 1, [...] , param N;
```

Although the field separator ',' and command separator ';' can be changed

The library can
* both send and receive of commands
* Both write and read multiple arguments
* Both write and read all primary data types
* Attach callback functions any received command

The library supports any primary data types, and zero to many multiple arguments. Arguments can either be sent in plain text (to be human readable) or in binary form (to be efficient).

With version 3.x also comes a full implementation of the toolkit in C#, which runs both in Mono (http://monodevelop.com/Download) and Visual Studio (http://www.microsoft.com/visualstudio/eng#downloads)
This allows for full 2-way communication between the arduino controller and the PC.

\** but it could easily be modified to work over Bluetooth or a web interface.

*******************************************************************

Groetjes,
eSe