Compare commits

..

No commits in common. "1fc36d87902ba34301669fe2953936e0b250d275" and "5e3149e170a30d5385cc2b1d1c76d654d0df7eb3" have entirely different histories.

8 changed files with 0 additions and 122 deletions

3
.gitignore vendored
View File

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

View File

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

View File

@ -1,44 +0,0 @@
# 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 :)

View File

@ -1,13 +0,0 @@
# 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 ?

View File

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

View File

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

View File

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

View File

@ -1,44 +0,0 @@
/*
* 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;
}
/* ----------------------------------------------------------------- */