Skyduino:~#
Articles
tutoriel

[How to] Utiliser la carte « bus pirate » en toute situation

Bonjour tout le monde !

Aujourd’hui je vais vous montrer comment utiliser la carte « bus pirate » quelque soit le probléme !

Tout d’abord qu’est ce que la carte « bus pirate » ?

Pour faire simple cette carte permet de tout faire,
voici les protocoles de base qu’elle supporte avec le firmware officiel :
– 1-Wire
– I2C
– SPI
– Asynchronous serial
– MIDI
– HD44780 LCD
– 2 et 3-wire + « bitwise pin control »
– mode « raw binary » sur les modes bitbang, 1-Wire, I2C, SPI, et UART
çà fait du monde 😉

Concrètement on s’en sert pour quoi ?
Et bien pour discuter avec un module, faire une analyse de signaux, faire du « Reverse engineering » sur une carte inconnu, etc …
Les possibilités sont infinies, la seul chose qui peut brider ses possibilités c’est l’imagination de son utilisateur.

Le principe de fonctionnent du bus pirate est le suivant :
– un prise mini-usb relié sur un CI FT232 (module usb série de FTDI)
– un pic 24FJ64GA
– un peu d’électronique pour faire l’interfaçage.

Ce qui faut savoir c’est que le pic au coeur du « bus pirate » est bootloadé ce qui signifie que vous pouvez mettre à jour, changer de firmware, etc … via le port usb sans aucun autre matériel.
Sur ce principe des projets de firmware alternatif on vu le jour, programmateur de fpga, d’avr, analyseur logique, mini oscilloscope, module jtag, …

Pour ce tutoriel nous allons rester sur le firmware officiel, et utiliser uniquement les fonctions de base.
Ce dont vous aurez besoin :
– une carte « bus pirate », de préférence la v3b (ici)
– un câble « bus pirate probe » de seeedstudio (ici)
– un câble mini usb

Pour la partie UART :
– un lecteur de carte RFID série de parallax (ici)
– un tag RFID compatible avec le lecteur ci dessus

Pour la partie I2C :
– un module RTC (horloge) de sparkfun (ici)

Pour la partie SPI :
– un 74HC595 (ici)
– 8 leds et 8 résistances de 330ohms

Pour la partie LCD :
– un adaptateur lcd « bus pirate » de seeedstudio (ici)
– un écran lcd 2×16

Pour la partie analogique :
– un potentiomètre ou un joystick

Vous n’aurez normalement besoin d’aucun autre fils ou matériels 😉

Vous êtes prêt ? Let’s GO !

oui mais non ! STOP !
Avant de foncer tête baissé, le code des couleurs du câble de seeedstudio :


(Prendre en compte la couleur du CÂBLE, et non des pinces !)

Pour débuter avec votre carte bus pirate rien de plus simple ! Branchez le cable mini usb sur votre ordinateur et sur votre bus pirate, si la led PWR s’allume c’est ok !
Si vous avez les drivers FTDI l’installation devrait ce faire toute seul, sinon ils sont disponibles ici, et si vous êtes sous linux ils sont installés de base (c’est beau la vie sous linux hein ;)).

Ne reste plus qu’as ouvrir un terminal sur le port série qui correspond au bus pirate avec votre logiciel préféré (moi j’utilise tera term).
Pour les spécifications du port série:
115200 bauds, 8 bit de données, pas de bit de parité, 1 bit de stop et pas de controle de flux.
Si tout est bon en faisant « entrer » sur votre clavier vous devriez voir un « HiZ> » apparaitre.

Tous d’abord les commandes et la syntaxe de bases :

? - affiche le menu d'aide (en anglais)
=X - converti la valeur de X
|X - inverse la valeur de X
~ - test de bon fonctionnement comme celui effectué en usine
# - redémarre la carte
$ - passe en mode bootloader (dans le cas d'une mise à jour)
& - fait une pause de 1 us
% - fait une pause de 1 ms
a A @ - gère l'état de la broche AUX (a -> LOW, A -> HIGH, @ -> lit l'état)
b - sélection de la vitesse du port série (défaut 115200)
c/C - permet de choisir si a/A controle la broche AUX ou la broche CS (par défaut c -> AUX)
d/D - mesure la tension présente sur la broche ADC (d -> prise de mesure unique, D -> prise de mesure en continu (il faut appuyer sur un touche pour quitter))
f - mesure la fréquence du signal présent sur la broche AUX
g/S - g génère un signal pwm sur la broche AUX, S génère un signal de controle pour servomoteur sur la broche AUX
h - affiche l'historique des commandes précédente
i - affiche les informations, numéro de version et statut du firmware
l/L - choix de l'ordre d'envoi des bit l -> MSB, L -> LSB
m - permet de changer de mode (hiz, i2c, ...)
o - permet de choisir le mode de fonctionnement de sorties (LOW, HIGH, HIZ)
p/P - désactive/active les résistances de pull-up software
s - moteur de scripting (langage de type basic)
v - affiche les voltages présent sur les différentes broches du bus pirate
w/W - désactive/active l'alimentation de la carte "fille" relié au bus pirate via GND et +3v3 ou +5v

(0) - affiche le menu des macro pour le mode en cours
(x) - exécute la macro numéro x
[ - envoie un bit de start
] - envoie un bit de Stop
{ - envoie un bit de start suivit d'une lecteur d'un octet
} - ferme la lecture
"abc" - envoie un chaine de caractères au format ascii
123 - envoie un nombre (forme décimal)
0x123 - envoie un nombre (forme hexa)
0b110 - envoie un nombre (forme binaire)
r - lit un octet
/ - place la broche CLK à HIGH
\ - place la broche CLK à LOW
^ - envoie un pulsation d'horloge sur la broche CLK
- - place la broche DAT à HIGH
_ - place la broche DAT à LOW
. - lit l'état de la broche DAT
! - lit un bit
: - répète un commande x fois (exemple r:10 => lit 10 octets)
. - lis l'état de DAT en la plaçant en mode HIZ (haute impédance)

Maintenant que vous connaissez les commandes de bases nous pouvons vraiment commencer !

1er tutoriel : le mode UART
Partons du principe que nous connaissons le fonctionnement de notre lecteur RFID, que celui ci fonctionne en 2400 bauds et que son câblage nous est connu.
Partant de là nous pouvons câbler notre lecteur RFID ainsi :

lecteur RFID -> Bus pirate
SOUT -> MISO
ENABLE -> AUX
VCC -> +5v
GND -> GND

Bien, nous savons que notre lecteur RFID fonctionne via le port série, passons donc en mode UART :

HiZ>m (m minuscule)
1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. 2WIRE
7. 3WIRE
8. LCD
9. DIO
x. exit(without change)

(1)>3 (mode UART)
Set serial port speed: (bps)
1. 300
2. 1200
3. 2400
4. 4800
5. 9600
6. 19200
7. 38400
8. 57600
9. 115200
10. BRG raw value

(1)>3 (2400 bauds)
Data bits and parity:
1. 8, NONE *default
2. 8, EVEN
3. 8, ODD
4. 9, NONE
(1)>1
Stop bits:
1. 1 *default
2. 2
(1)>1
Receive polarity:
1. Idle 1 *default
2. Idle 0
(1)>1
Select output type:
1. Open drain (H=Hi-Z, L=GND)
2. Normal (H=3.3V, L=GND)
(1)>1
Ready
UART>

A partir de maintenant la led « mode » doit s’être allumé car nous somme sortit du mode de sécurité « Hiz » (haute impédance = toute broches en l’air = non connecté).

Maintenant que nous avons câblé notre lecteur RFID, que tout à bien était vérifié (pas d’inversion +5v/gnd, etc …) nous pouvons allumer l’alimentation du bus pirate.
Pour ce faire il faut exécuter la commande « W » (w majuscule).
La led « vreg » doit s’allumer pour signifier qu’as partir de maintenant le circuit en cours de test est alimenté (= attention pas de câblage sous tension).

Le lecteur RFID est allumé, la led est verte signe que celui ci est en mode « sleep », avant de pouvoir l’utiliser il faut le mettre en mode « on » en plaçant la broche AUX à l’état BAS.
Pour ce faire il faut exécuter la commande « a » (a minuscule).

Le lecteur RFID est désormais prêt à être utilisé, maintenant il nous faut récupérer les octets correspondant au tags RFID que capte le lecteur.
Si vous faite « r:10 » par exemple pour lire 10 octets vous allez vous retrouver avec une erreur comme celle ci :
UART>r:10
READ: -f 0x00 FAILED, NO DATA0x00 FAILED, NO DATA0x00 FAILED, NO DATA0x00 FAILED, NO DATA0x00 FAILED, NO DATA0x00 FAILED, NO DATA0x00 FAILED, NO DATA0x00 FAILED, NO DATA0x00 FAILED, NO DATA0x00
UART>

Le probléme est que nous ne savons pas quand le lecteur rfid envoie quelque chose, il nous faut donc placer le bus pirate en mode lecture continu (mode « monitor ») pour avoir un affichage en continu des données reçu.
Pour ce faire il faut exécuter la commande « (2) » (parenthèse ouverte 2 parenthésée fermé), pour les curieux vous pouvez regarder les macro disponibles via « (0) ».
A partir de là votre bus pirate vous répond :
UART>(2)
Raw UART input
Any key to exit

signe que le mode lecture continu est en marche, passons un tag RFID sur le lecteur pour voir le résultat :
2600D6F1A8

C’est bon nous avons reçu les octets correspondant à l’identifiant du tag RFID ! Epik Win !

Maintenant stoppons la lecture en continu, éteignons l’alimentation et repassons en mode « haute impédance » pour le prochain tutoriel :

(espace pour quitter le mode "monitor")
w (w minuscule)
m (m minuscule)
1 (choix 1 = Hiz)

1er tutoriel : le mode ADC
Partons du principe que nous avons un joystick (ou un potentiométre), nous voulons savoir la tension qu’il génère suivant la position sur laquelle il se trouve, nous n’avons pas de multimètre sous la main, ni même d’oscilloscope ou autre, mais tout n’est pas perdu ! Nous avons notre bus pirate !
Notre joystick est alimenté en 0/5v le bus pirate peut AU MAXIMUM mesurer des tensions de 6 volts, c’est donc tout bon !

Je passe trés rapidement sur le câblage :

joystick -> bus pirate
GND -> GND
VCC -> +5v
VERT -> ADC

Maintenant il va falloir passer en mode « DIO », pour ce faire « m » (m minuscule):

HiZ>m
1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. 2WIRE
7. 3WIRE
8. LCD
9. DIO
x. exit(without change)

(1)>9 (mode DIO)
Ready
DIO>

On allume l’alimentation avec « W » (w majuscule) et c’est tout bon !
DIO>W
Power supplies ON
DIO>

Pour mesurer une tension 3 options :
– utiliser « d » (d minuscule) pour faire une mesure seul,
– utiliser « v » (v minuscule) pour afficher les tensions global de la carte bus pirate en faisant une mesure,
– utiliser « D » (d majuscule) pour passer en mode voltmètre.
Exemple :

DIO>d
VOLTAGE PROBE: 2.06V
DIO>v
Pinstates:
1.(BR) 2.(RD) 3.(OR) 4.(YW) 5.(GN) 6.(BL) 7.(PU) 8.(GR) 9.(WT) 0.(Blk)
GND 3.3V 5.0V ADC VPU AUX CLK MOSI CS MISO
P P P I I I I I I I
GND 3.32V 5.02V 2.06V 0.00V H H H H H
DIO>D
VOLTMETER MODE
Any key to exit
VOLTAGE PROBE: 2.06V (NB: la valeur varie au cours du temps)
DIO>

Maintenant quittons le mode voltmètre, éteignons l’alimentation et repassons en mode « haute impédance » pour le prochain tutoriel :

(espace pour quitter le mode voltmètre)
w (w minuscule)
m (m minuscule)
1 (choix 1 = Hiz)

Remarque: Dans n’importe quel mode vous pouvez faire une prise de mesure de tension, faire commuter la broche AUX ou mesurer/générer un fréquence pwm, le mode DIO est juste un mode qui ne demande pas de configuration ce qui me nous simplifie la vie.

1er tutoriel : le mode I2C
Partons du principe que nous avons un module RTC (real time clock) nous savons qu’il ‘agit d’un DS1307, CI trés connu dans son domaine, nous avons son datasheet mais pas son adresse I2C (zut ;))
Notre but : avoir l’heure actuelle stocké dans le module RTC.

Câblage :

DS1307 -> bus pirate
GND -> GND
5V -> +5V
SDA -> MOSI
SCL -> CLK

Passage en mode I2C avec « m » (vitesse 100KHz), allumage de l’alimentation avec « W », vous savez le faire tout seul maintenant 😉

Regardons un peu les macro disponible :

HiZ>m
1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. 2WIRE
7. 3WIRE
8. LCD
9. DIO
x. exit(without change)

(1)>4
Set speed:
1. ~5KHz
2. ~50KHz
3. ~100KHz
4. ~400KHz

(1)>3
Ready
I2C>W
Power supplies ON
I2C>(0)
0.Macro menu
1.7bit address search
2.I2C sniffer
I2C>

haha! « 1.7bit address search », voila une macro qui pourrait nous être utile ! (je vous rappelle nous ne connaissont pas l’adresse I2C du module)

I2C>(1)
Searching I2C address space. Found devices at:
Warning: *Short or no pull-up

I2C>

hein !? Mais mais mais … j’ai pourtant vérifié mon câblage pourquoi sa marche pas …
Une petite spécificité de l’I2C, c’est un bus fonctionnant avec des entrées/sorties à collecteur ouvert, pour fonctionner il faut leurs appliqué une tension (ici 5v).

Pour que tout marche correctement il faut venir cabler la broche « vpu » du buspirate au +5v et activé les résistances de pull-up, pour ce faire :
on éteint l’alimentation avec « w », on branche la pince du cable « vpu » sur le +5v et on fait ceci :

2C>W
Power supplies ON
I2C>P
Pull-up resistors ON
I2C>v
Pinstates:
1.(BR) 2.(RD) 3.(OR) 4.(YW) 5.(GN) 6.(BL) 7.(PU) 8.(GR) 9.(WT) 0.(Blk)
GND 3.3V 5.0V ADC VPU AUX SCL SDA - -
P P P I I I I I I I
GND 3.32V 5.02V 0.00V 5.03V L H H H H
I2C>

Vous remarquez le « P » (p majuscule) ? Il permet de dire au bus pirate que la tension « vpu » doit être utilisé comme tension pour les résistances de pull-up.

Maintenant retentons notre macro (1):

I2C>(1)
Searching I2C address space. Found devices at:
0xD0(0x68 W) 0xD1(0x68 R)

I2C>

hoho! Quelque chose a était trouvé à l’adresse 0xD0, se pourrait t’il que se soit notre module RTC ?
Et bien oui si vous regarder le datasheet du DS1307 vous verez qu’il s’agit bien de son adresse, pourquoi ne pas l’avoir utilisé des le début ?
Pour vous montrer comment chercher une adresse sur un bus I2C.
De même si vous n’avez pas de datasheet mais que vous avez un circuit utilisant un bus I2C vous pouvez « sniffer » le traffic I2C puis renversé le protocole à la main 😉

Bon maintenant demandons à notre module l’heure actuelle.
L’organisation interne de la mémoire du DS1307 est la suivante :

Comme nous pouvons le voir, il va nous falloir demander 8 octets à partir de l’adresse 0 pour avoir l’heure.
En I2C chaque périphérique a deux adresse, l’adresse d’écriture et de lecture.
Ici 0xD0 pour l’écriture et 0xD1 pour la lecture, l’adresse de lecture est TOUJOURS égale à l’adresse d’écriture + 1.
Pour demander l’heure il va falloir envoyé 0 à l’adresse 0xD0 puis demander 8 octets à l’adresse 0xD1
Allez on est partis !
[ -> bit de start
] -> bit de stop
r:8 -> demande de 8 octets

I2C>[0xd0 0 [0xd1 r:8]
I2C START BIT
WRITE: 0xD0 ACK
WRITE: 0x00 ACK
I2C START BIT
WRITE: 0xD1 ACK
READ: 0x28 ACK 0x47 ACK 0x14 ACK 0x02 ACK 0x25 ACK 0x10 ACK 0x11 ACK 0x00
NACK
I2C STOP BIT
I2C>

Qu’est ce que je viens de faire ?
J’ai envoyé un bit de start pour dire aux périphériques du bus I2C que je vais parler, j’envoie ensuite à 0xD0 l’octet 0 puis sans fermé la communication je renvoi un bit de start pour demander à 0xD1 cette fois si 8 octets, une fois les huits octets recu je coupe la communication.

Maintenant interprétons le résultat :
Nous somme le (accrochez vous bien) :
0x28 – 28 secondes
0x47 – 47 minutes
0x14 – 14 heures
0x02 – 2 (mardi)
0x25 – 25 (jours)
0x10 – 10 (octobre)
0x11 – 2011 (années)
Soit en francais : nous somme le mardi 25 octobre 2011, et il est 14 heures, 47 minutes, 28 secondes.
Pour un petit module dont la batterie est là depuis maintenant 5 ans il faut avouer qu’il n’as pas perdu en précision, l’heure est exacte !

Et voila merci petit module RTC de nous avoir données l’heure à la seconde prés !

Maintenant éteignons l’alimentation et repassons en mode « haute impédance » pour le prochain tutoriel :

w (w minuscule)
m (m minuscule)
1 (choix 1 = Hiz)

1er tutoriel : le mode SPI
haa! Le SPI, Serial Peripheral Interface, ce tutoriel va vous faire hérisser le poil j’en suis sur ^^
Partons du principe que nous avons un CI 74HC595 qui est un registre à décalage 8 bits, nous avons câblé sur chaque sortie une led, soit un total de 8 led.
Notre but est d’afficher sur ces 8 led une valeur transmise sous la forme d’un octet via le bus SPI, nous aurions pu utiliser une carte arduino mais cela n’aurez pas était drôle 😉

La câblage :

74HC595 -> bus pirate
DS -> MOSI
ST_CP -> CS
SH_CP -> TCK
GND -> GND
VCC -> +5v
OE -> GND
MR -> +5v

Chaque led est cablé ainsi :
IO -> led -> résistance (330ohms) -> GND


(Ps: je n’est cablé que 4 led 😉 féniasse inside)

Nous allons dans un premier temps utiliser le mode 3wire pour communiquer avec notre 74HC595 puis nous utiliserons le mode SPI.
La différence ? Le premier tourne à basse vitesse, ne demande aucune configuration et est relativement simple, le SPI tourne beaucoup plus vite mais demande énormément de configuration.

Voici comment allumer toute les led puis les éteindre en mode 3Wire:

UART>m
1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. 2WIRE
7. 3WIRE
8. LCD
9. DIO
x. exit(without change)

(1)>7
Set speed:
1. ~5KHz
2. ~50KHz
3. ~100KHz
4. ~400KHz

(1)>1
CS:
1. CS
2. /CS *default

(2)>2
Select output type:
1. Open drain (H=Hi-Z, L=GND)
2. Normal (H=3.3V, L=GND)

(1)>2
Ready
3WIRE>W
Power supplies ON
3WIRE>[
/CS ENABLED
3WIRE>0][
WRITE: 0x00
/CS DISABLED
/CS ENABLED
3WIRE>255][
WRITE: 0xFF
/CS DISABLED
/CS ENABLED
3WIRE>

La même chose en mode SPI :

HiZ>m
1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. 2WIRE
7. 3WIRE
8. LCD
9. DIO
x. exit(without change)

(1)>5
Set speed:
1. 30KHz
2. 125KHz
3. 250KHz
4. 1MHz

(1)>1
Clock polarity:
1. Idle low *default
2. Idle high

(1)>1
Output clock edge:
1. Idle to active
2. Active to idle *default

(2)>2
Input sample phase:
1. Middle *default
2. End

(1)>1
CS:
1. CS
2. /CS *default

(2)>2
Select output type:
1. Open drain (H=Hi-Z, L=GND)
2. Normal (H=3.3V, L=GND)

(1)>2
Ready
SPI>W
Power supplies ON
SPI>[
/CS ENABLED
SPI>0][
WRITE: 0x00
/CS DISABLED
/CS ENABLED
SPI>255][
WRITE: 0xFF
/CS DISABLED
/CS ENABLED
SPI>

Vous remarquerai que la syntaxe pour l’envoi des données est la même dans les deux modes, ce qui change c’est la vitesse et la configuration nécessaire.

Comment ça marche ?
Tout d’abord on allume l’alimentation avec « W », à partir de là le 74HC595 est alimenté.
On exécute la commande « [ » (crochet ouvert) pour mettre CS à LOW, se qui active le 74HC595 qui attend alors un octet.
On envoi nos données sous la forme d’un octet.
Puis on dis au 74HC595 de placer ses sorties selon l’octet qu’on vient de lui envoyer en plaçant CS à HIGH puis à LOW, en faisant cela on dis au 74HC595 que l’envoi est terminé, il place donc ses sortie selon ce qu’on lui a demandé, puis avec le second « [ » on lui dit d’attendre le prochain octet (et ainsi de suite).

1er tutoriel : le mode LCD
J’ai gardé le plus simple pour la fin 😉
Pour ce tutoriel seul des connaissances en lego sont requise.
Le câblage ? Il n’y en a pas ! Vous brancher le câble sur l’adaptateur lcd « bus pirate » et l’autre bout au bus pirate et c’est bon.

Maintenant essayons d’afficher le message « Hello World ! »

HiZ>m
1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. 2WIRE
7. 3WIRE
8. LCD
9. DIO
x. exit(without change)

(1)>8
This mode requires an adapter
Ready
LCD>W
Power supplies ON
LCD>(0)
0.Macro menu
1.LCD Reset
2.Init LCD
3.Clear LCD
4.Cursor position ex:(4) 0
6.Write test numbers ex:(6) 80
7.Write test characters ex:(7) 80

LCD>(1)
RESET

LCD>(2)
RESET
Display lines:
1. 1
2. Multiple

(2)>2
INIT

LCD>(3)
CLEAR

LCD>"Hello World !"
WRITE: "Hello World !"
LCD>

Avouez que c’était pas compliqué 😉

Pour les râleurs (et parce que je vois venir la question a des km à la ronde), quelle est l’utilité de cet adaptateur ?
bus pirate + adaptateur + lcd = afficheur lcd usb pas chére 😉

Et voila j’en est finit avec ce multi-tutoriel, à partir de maintenant vous ne pourrez pas dire que vous ne savez pas utiliser une carte bus pirate.
Je vous aurez bien fait une partie 1-Wire mais le capteur de température que je possédai à rendu l’âme il y a déjà fort longtemps …

Remarque : les modes bitbang (= gestion des entrées/sortie « pure »), 1-Wire, I2C, SPI, et UART peuvent être utilisé en mode « raw byte », le principe est trés simple tout les octets recu sur le port série sont retransmis suivant le protocole en cours et les octets recu via ce même protocole sont renvoyé sur le port série.
Ces modes sont réservés a une utilisation avec des scripts par exemple, pour ne pas avoir à gérer les commandes et les menus, et pouvoir ainsi ce servir directement du bus pirate comme d’un adaptateur usb vers xxx.

Si vous avez des questions n’hésitez pas à les poser 😉

Dans le prochain tutoriels je vous montrerai comment commander votre cafetière à distance par la pensé avec une carte bus pirate, puis comment sans bouger de votre confortable canapé faire venir la tasse jusqu’à vous … malheureusement il faudra attendre car cela n’est pas encore possible, il faudra surement attendre la version 4 du buspirate … 🙂

Discussion

10 réflexions sur “[How to] Utiliser la carte « bus pirate » en toute situation

  1. merci a toi pour ce tuto de qualité ! cela fait un moment que je louche sur cette carte. A t’il possibilité de sniffer un bus i2c ? merci

    Publié par Bertrand | 30 octobre 2011, 12 h 28 min
  2. Bertrand,

    I2C>(0)
    0.Macro menu
    1.7bit address search
    2.I2C sniffer
    I2C>

    Il suffit de lire parfois 🙂

    Publié par schizophrene | 30 octobre 2011, 13 h 54 min
  3. Effectivement je me suis trop precipite :d sur smartphone c’est pas le top 🙂

    Quelle est la difference avec la V4 ?

    http://www.seeedstudio.com/depot/bus-pirate-v4-for-developers-p-740.html?cPath=174

    Publié par bertrand | 1 novembre 2011, 10 h 06 min
    • Tout est dans le titre 😉
      « bus-pirate-v4-for-developers », c’est la prochaine version, sans firmware stable pour le moment et avec un hardware en cours de changement.

      Cette version est réservé au développeur du projet bus pirate, un utilisateur « normal » ne doit surtout pas prendre cette version (sauf si l’utilisateur en question veut aider au dév du projet bus pirate).

      La différence entre v3b et v4 c’est surtout au niveau du pic qui possède un usb natif et beaucoup plus de place en flash = possibilité de faire des pack de plusieurs firmware et du dev usb natif.

      Mais comme je le disait plus haut, aucun support logiciel ni même la garanti que la carte démarre avec les éditions « for developers » 😉
      (C’est même marqué en rouge sur la fiche produit)

      Publié par skywodd | 1 novembre 2011, 11 h 35 min
  4. oui je penser que cette version posséder plus de support au niveau des protocoles. merci pour l’explication.

    Publié par Bertrand | 1 novembre 2011, 17 h 28 min
  5. Merci Skywood pour ce tuto qui m’a fait acquérir ce joujou, que je commence à utiliser.
    J’ai vu sur le site de buspirate que l’on pouvait ajouter des patch (et en particulier un patch pour les signaux PPM en modélisme…). Malheureusement mes recherches sur leur site (ajouté il est vrai a mon niveau d’anglais…inqualifiable) ne m’ont pas permis de comprendre comment rajouter un patch. Bien sur, il s’agit d’un fichier en C, donc j’imagine bien qu’il faille le compiler. Comment ? Et surtout peut-on le compiler indépendemment du projet et l’intégrer ensuite ? Ou doit-on tout recompiler et renvoyer au buspirate ?
    Si tu as des infos la dessus (en français !) ca m’ouvrirait des horizons…
    Continue à nous faire des posts de cette qualité, et merci encore.

    Publié par Jean-Charles Le Tarnec | 19 avril 2012, 15 h 59 min
    • >> Bien sur, il s’agit d’un fichier en C, donc j’imagine bien qu’il faille le compiler. Comment ?
      Il faut récupérer le code source complet du projet buspirate avec un client SVN ( http://code.google.com/p/the-bus-pirate/source/ ) puis inclure le patch dans les sources (avec la commande linux « patch » si c’est un fichier .patch ou sinon à la main) et compiler le code avec un compilateur c pour mplab.

      >> Et surtout peut-on le compiler indépendemment du projet et l’intégrer ensuite ?
      >> Ou doit-on tout recompiler et renvoyer au buspirate ?
      Non les cartes buspirates travail sur une base de micro-contrôleurs PIC, tu dois compiler tout le firmware à chaque fois.
      Puis reprogrammer la carte avec un programmateur de PIC (ponyprog, ICD2, PICKIT, …).

      >> Si tu as des infos la dessus (en français !) ca m’ouvrirait des horizons…
      En français non malheureusement …
      Mais en anglais tu as un tuto complet ici :
      http://dangerousprototypes.com/docs/Compile_the_Bus_Pirate_firmware
      (google trad ;))

      Publié par skywodd | 19 avril 2012, 16 h 23 min

Rétroliens/Pings

  1. Pingback: » Sniffer 433mhz - analyseur logique - 24 juin 2012

Skyduino devient Carnet du Maker

Le site Carnet du Maker remplace désormais le blog Skyduino pour tout ce qui touche à l'Arduino, l'informatique et au DIY.