Régnez avec le SCEPTRE !

Postby abiz » Wed May 12, 2010 12:00 am

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
abiz
 
Posts: 44
Joined: Fri Jan 17, 2014 4:41 pm

Postby abiz » Wed May 12, 2010 12:00 am

info : le numéro de juin d'ELEKTOR décrit une carte d'extension (InterSceptre) de la carte Sceptre.
Ca m'a aidé à identifier les entrées/sorties ainsi que les jumpers car la sérigraphie de la carte n'est pas très explicite et absente sur une face comportant 3 JP.
Le fichier 100174 contient des fonctions supplémentaires liées à la carte InterSceptre.
Question: des mises à jour ont-elles été effectuées par rapport à la version du 26 fevrier ?
abiz
 
Posts: 44
Joined: Fri Jan 17, 2014 4:41 pm

Postby rédaction » Mon May 17, 2010 12:00 am

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
rédaction
 
Posts: 118
Joined: Thu Jan 02, 2014 10:37 am

Postby gibi » Fri May 28, 2010 12:00 am

Je viens de tester ma platine qui vient de me parvenir, la rupture de stock a l'air terminé.

Je viens de faire un premier test avec le preload et flash magic.

J'ai un petit problème, l'accéléromètre reste désespérement figé.
Le thermomètre fonctionne bien, les fichiers s'inscrivent bien sur la carte SD, mais la valeur inscrite est toujours de 999 sur les trois axes.
Ma version de preload est la 20100131.

De plus la capture de données ne s'arrête pas à 30 s mais ne semble pas vouloir s'arrêter.

Avez-vous un conseil à me donner ?

Gibi
gibi
 
Posts: 104
Joined: Fri Jan 17, 2014 4:36 pm

Postby hlaidet » Sat May 29, 2010 12:00 am

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
hlaidet
 
Posts: 61
Joined: Thu Jan 02, 2014 10:44 am

Postby gibi » Sat May 29, 2010 12:00 am

Bonjour Henri,

Merci pour ton aide, effectivement j'avais oublié ce détail.
Cela fonctionne très bien maintenant.
Pour le module bluetooth, (très délicat à souder) j'ai les deux leds data et link qui clignotent deux fois à la mise en route, puis la link continue de clignoter seule. Normal ?
Le module bluetooth peut-il fonctionner sans antenne ?

Gibi.
gibi
 
Posts: 104
Joined: Fri Jan 17, 2014 4:36 pm

Postby hlaidet » Mon May 31, 2010 12:00 am

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
hlaidet
 
Posts: 61
Joined: Thu Jan 02, 2014 10:44 am

Postby hlaidet » Fri Jun 04, 2010 12:00 am

Bonjour,

J'ai lu dans la doc de l'uart, qu'on pouvait obtenir une meilleure précision du baudrate.

Voici une version de "uart.c" qui utilise le Fractional Divider Register.
Ceci permet une précision meilleure que 0.1% à 115200 bauds.

Cordialement,
Henri
Attachments
uart.c
(18.74 KiB) Downloaded 61 times
hlaidet
 
Posts: 61
Joined: Thu Jan 02, 2014 10:44 am

Postby gdv » Sat Jun 05, 2010 12:00 am

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
gdv
 
Posts: 10
Joined: Fri Jan 03, 2014 1:49 pm

Postby hlaidet » Wed Jun 09, 2010 12:00 am

Bonjour,

J'ai eu quelques problèmes de plantages lors de l'écriture d'une application serveur (via bluetooth).

SOLUTION:
- la taille de pile n'est pas suffisante si on utilise le file systeme et printf.
- dans le fichier "Startup.S", j'ai doublé la taille de USR et SVC
# .set SVC_Stack_Size, 0x00000100 ;//0x00000080
# .set USR_Stack_Size, 0x00001000 ;//0x00000800
- et ajouté un morceau de code remplissant toute la zone stack de '*' ce qui permet de tracer l'occupation

MESURES: avec application dérivée de preload
- zones ABORT, FIQ et UNDEF : inutilisées (dans mon cas)
- zone SVC: reste 116 bytes/256 libres
- zone IRQ: reste 488 bytes/512 libres
- zone USR: dans "main.c"
- après "device_init()", il reste 3444 bytes/4096
- après les printf, il reste 1592/4096
- après les écritures sur disque ("sys_info.txt","sd_info.txt"), il reste 1048/4096
- ensuite plus d'évolution

Lors du grossissement de l'application, je vais contrôler l'évolution des piles et garder une réserve raisonnable (20%).

Cordialement
Henri
Attachments

[The extension s has been deactivated and can no longer be displayed.]

hlaidet
 
Posts: 61
Joined: Thu Jan 02, 2014 10:44 am

Next

Return to SCEPTRE (03-2010)

Who is online

Users browsing this forum: No registered users and 1 guest