Forum

Je viens de reçevoir une carte carte Sceptre... comme beaucoup ... car la carte est paraît-il déjà en rupture de stock !
Pourquoi ne pas ouvrir, dès maintenant, sur le forum une vraie rubrique dédiée à ce système de prototypage 32 bits.
Les questions vont certainement fuser (j'en ai personnellement un beau petit stock en réserve...)
Pour info, avant de disposer de la carte, j'ai pu compiler quelques exemples avec production d'un .HEX en mode ARM et en mode THUMB mais avec de nombreux warning (en cause la bilbliothèque ?) à confirmer
Encore merci à l'équipe d'ELEKTOR pour la publication de ce passionnant projet

Oui, la bibliothèque du Sceptre contenu dans le téléchargement a été mise jour également (rajout du watchdog, quelques petites modifications). Chaque article concernant le Sceptre (3 jusqu'à maintenant) est accompagné de la toute dernière version de la bibliothèque sceptre. Pas mal de fonctions ont été rajoutées au moment de la publication du deuxième article.

Lisez le fichier "readme.txt" contenu dans le téléchargement pour connaitre les modifications.

Cordialement,
Clemens

Bonjour Gibi,

Je viens aussi de faire les premiers essais avec la carte sceptre.

As-tu pensé à polariser VREF ( strapp entre 1 et 2 de K6 )?

Cordialement
Henri

Bonjour,

BLUETOOTH:
- avec l'applic preload, la led link clignote quand le btm222 est en attente de connexion.
- une fois connecté, link reste allumée et data s'allume à chaque reception.
- je n'ai mis aucune antenne

MODIFICATIONS BLUETOOTH:
- afin de choisir le baudrate, j'ai modifié "bluetooth_init"
qui programme l'uart1, interroge btm222 sur son baudrate.
si pas de réponse (baudrate uart différent du btm222), on essaie avec un autre baudrate
(4800, 9600, 19200, 38400, 57600, 115200).
lorsque dialogue avec btm22 est possible, programmation de son baudrate.
ainsi au prochain reset, le baudrate sera bon.

MODIFICATIONS UART:
- en stressant un peu la com ( "uart0_putc" via "printf" ), j'ai eu quelques problèmes:
1/ perte de données émises (lorsque le buffer de 512 est plein)
solution: ne plus utiliser "uart0_putc" directement mais "OutputChar"
sans oublier les appels de printf dans "write_r.c"->uart0_putc
#bool_t OutputChar(uint32_t ch)
#{
# if (uart0_putc(ch)==true) // send OK
# return true;
# timer_wait_ms(50); // wait for enough room in buffer
# if (uart0_putc(ch)==true) // try again
# return true;
# uart0_flush_buffers();
# return false;
#}

2/ quelques fois il y a inversion de 2 octets émis.
solution: dans "uart0_putc" on est en irq uart valides.
- si le test "if (uart0_buffer.tx_fifo_empty==true)" est faux
et que le buffer[512] est vide
- si une irq uart0->IIR_THRE claque avant la mise en pile
alors notre caractère est dans la pile sans etre tiré par uart0->IIR_THRE
donc le prochain appel de "uart0_putc" place le caractère dans l'uart
et c'est uart0->IIR_THRE qui tirera celui qui a été mis en pile avant lui.
ce qui aboutit à croiser 2 caractères.

ce cas arrive rarement mais arrive surtout quand on émet des caractères avec un débit (de production) variable.

contournement du problème:
#bool_t uart0_putc(uint32_t ch)
#{
# if (uart0_buffer.tx_fifo_empty==true)
# {
# uart0_buffer.tx_fifo_empty = false; // Mark fifo as no longer empty.
# U0THR = ch; // Send character right away.
# return true;
# }
# else
# { bool_t res;
# res = uart_buffer_putc(ch,&uart0_buffer.tx); // Put character in tx buffer.
# if (uart0_buffer.tx_fifo_empty==true) // HLA irq->IIR_THRE arrived before char in buffer
# {
# if (uart_buffer_getc(&ch,&uart0_buffer.tx)==true)
# {
# uart0_buffer.tx_fifo_empty = false; // Mark fifo as no longer empty.
# U0THR = ch; // Send character
# }
# }
# return res;
# }
#}

EN VRAC:
- ajout "uart1_set_baudrate" ( necessaire à "MODIFICATIONS BLUETOOTH" )
- modification calcul baudrate uarts (arrondi et non troncature)
on passe à 115200k de 1.7% à 1.35% d'erreur
j'ai cru au début que c'était la cause des problèmes de perte de caractère.


PROBLEMES PERSISTANTS:
- j'ai des blocages avec "uart1_putc" et la liaison bluetooth
contexte:
- hyperterminal_1 sur uart0 (via USB FT232RL jp15 et 16 ouverts)
- hyperterminal_2 sur uart1 ( btm222 sur sceptre et adaptateur USB Bluetooth sur PC )

avec l'applic "app_preload" ça fonctionne bien car les caractères sont frappés au clavier.
ils sont donc émis plus vite qu'ils sont produits.
ceci qui autorise l'invocation de "uart1_putc" avec "right_now"=true.
maintenant si on veut du débit (c'est mon cas) et profiter du buffer[512] de uart1,
on doit laisser "right_now"=false.

dans ce cas là, le dialogue se fait bien et puis d'un coup, blocage de la communication sur la voie uart1.
si on expédie 1 caractère avec "right_now"=true, la com se débloque et le buffer[512] se vide.

***** je ne comprend la raison de ce blocage *****

le but de ces tests est l'écriture sur sceptre d'un petit serveur permettant
à un client sur PC de lire et écrire sur la carte SD (un browser)
et celà sans connexion filaire (bluetooth).
le browser est en cours sur uart0 et je me sers de uart1 (bluetooth à 57600) pour debugger.
a terme, les uarts seront croisés (debug=uart0 applic=uart1).

je mettrai mon projet en ligne dès que possible.

Cordialement
Henri

Bonsoir

Juste un détail,
ne pas oublier de ponter JP11 et JP12 (sur la face carte SD sous le BTM 222) pour que la communication avec le module Bluetooth fonctionne sinon il ne reçoit ni Rx ni Tx du micro