Comparar commits

..

No hay commits en común. "1fc36d87902ba34301669fe2953936e0b250d275" y "5e3149e170a30d5385cc2b1d1c76d654d0df7eb3" tienen historias totalmente diferentes.

Se han modificado 8 ficheros con 0 adiciones y 122 borrados

3
.gitignore vendido
Ver fichero

@ -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

Ver fichero

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

Ver fichero

@ -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 :)

Ver fichero

@ -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 ?

Ver fichero

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

Ver fichero

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

Ver fichero

@ -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 $@

Ver fichero

@ -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;
}
/* ----------------------------------------------------------------- */