Compare commits

...

4 Commits

Author SHA1 Message Date
tth 1fc36d8790 suite du projet 2021-06-29 09:57:27 +02:00
tth 1c32695589 to be continued... 2021-06-29 08:49:12 +02:00
tth a2d33084f1 to be continued... 2021-06-29 08:38:53 +02:00
tth 55b7f5b85b laser de Gaby, le début 2021-06-29 08:12:55 +02:00
8 changed files with 122 additions and 0 deletions

3
.gitignore vendored
View File

@ -18,8 +18,11 @@ doc/*.ind
functions/*.[oa]
tools/udp-dumper
tools/wait-for-joystick
tools/*.o
Gaby/*.[oa]
specific/joy2laser
specific/asyncburp
specific/*.o

6
Gaby/Makefile Normal file
View File

@ -0,0 +1,6 @@
# ------------------------------------------------------
# Piloter le laser de Gaby
# ------------------------------------------------------

44
Gaby/README.md Normal file
View File

@ -0,0 +1,44 @@
# Le laser de Gaby
Une nouvelle aventure se prépare à Valensole, en voici l'histoire...
## Caractéristiques
Encore très flou, mais où donc est rangée cette doc ?
- position X/Y par deux valeurs analogiques
- niveau RGB par trois signaux PWM
https://en.wikipedia.org/wiki/International_Laser_Display_Association
## Logiciels
Deux composantes : le contrôleur "physique" du laser tournera dans
un Arduino Mega, et sera lui même piloté par un "récepteur" OSC dans
la machine hote. Ces deux parties vont communiquer par le classique
lien série/usb avec un protocole encore à définir.
### Coté hote/OSC
Dans un premier temps, je vais reprendre mon protocole utilisé pour
les joysticks, d'abord pour le positionnement X/Y, et ensuite pour
la gestion du RGB.
### Coté Arduino
Les choses sont moins claires, car j'ignore encore certaines choses comme
la qualité des sortie analogiques de l'Arduino. Il sera peut-être
nécessaire de conditionner les deux valeurs (intégration, gain, offset)
par un matériel approprié.
D'autre part, la fréquence de rafraichissement sera-elle suffisante ?
Et pour finir y aura-t-il assez de mémoire RAM pour stocker des dessins
de taille conséquente ?
## Conclusion
Il faut maintenant envoyer le Gobeti :)

13
Gaby/protocole.md Normal file
View File

@ -0,0 +1,13 @@
# Le protocole
Le lien série-sur-usb de l'arduino est parfois capricieux et souvent
plein de mystères...
Ayant de gros doutes sur sa capacité à transmettre des données binaires,
le choix d'un codage ASCII semble évident.
D'un autre coté, le débit du lien est assez faible, il faut compacter
le plus possible les données transférées. Un encodage type `base64`
est-il la bonne solution ?

6
Gaby/transmit.c Normal file
View File

@ -0,0 +1,6 @@
/*
* +---------------------------------------------+
* | transmission des commandes vers l'arduino |
* +---------------------------------------------+
*/

4
chuck/dessiner.ck Normal file
View File

@ -0,0 +1,4 @@
#
# dessiner par OSC avec le laser de Gaby
#

View File

@ -7,3 +7,5 @@
udp-dumper: udp-dumper.c Makefile
gcc -Wall $< -o $@
wait-for-joystick: wait-for-joystick.c Makefile
gcc -Wall $< -o $@

44
tools/wait-for-joystick.c Normal file
View File

@ -0,0 +1,44 @@
/*
* wait for joystick event
* -----------------------
*
# https://git.tetalab.org/tTh/gadgets-OSC
*
*/
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int verbosity = 0;
/* ----------------------------------------------------------------- */
/* ----------------------------------------------------------------- */
void help(int k)
{
puts("XXX");
exit(0);
}
/* ----------------------------------------------------------------- */
int main(int argc, char *argv[])
{
int foo, opt;
char *device = "/dev/input/js0";
/* parsing command line options */
while ((opt = getopt(argc, argv, "d:hv")) != -1) {
switch (opt) {
case 'd': device = optarg; break;
case 'h': help(0); break;
case 'v': verbosity++; break;
default: exit(1);
}
}
if (verbosity) {
fprintf(stderr, "%s on %s\n", argv[0], device);
}
return 0;
}
/* ----------------------------------------------------------------- */