Assemblage d’un premier prototype

Nous avons réalisé un boîtier en impression 3D. Nous avons conçu les pièces grâce à freeCad.

Deux branchements sont nécessaires sur le circuit:

  • Branchement à la batterie (avec ajout d’un interrupteur entre les deux)
  • Branchement à l’écran via une nappe.

La batterie a été collée grâce à un scotch double face, au fond du boîtier. Le circuit se positionne alors aisément sur les picots prévus à cet effet. On peut alors fermer le couvercle et démarrer la calculatrice!

05-protoComplet04-circuit

Programmer le pic CMS, pour contrôler le clavier

Nous avons utilisé un pickit2 afin de programmer le pic CMS.

pickit

On programme le pic une fois soudé sur le circuit. On positionne le pickit sur les pins de programmation prévues à cet effet sur le pcb du circuit. Je rappelle au passage comment à été câblé le connecteur de programmation en conformité avec la doc du pickit2 : il s’agit du connecteur P2 ci-dessous.picProg1picProg2

 

Afin d’uploader le programme sur le pic, nous avons suivi les instructions présentes sur la documentation ubuntu.

Continuer la lecture

Souder un circuit CMS à la main, à la maison, sans materiel spécialisé

Cet article vous permettra d’apprendre à souder des circuits cms facilement à la maison. Cela marche pour tous les composants CMS , y compris les BGA simples (testé) et sûrement les QFN (non testé).

Il vous faudra pour cela:

  • Une vieille poêle, que vous ne réutiliserez plus pour cuire des aliments! ^^
  • Une pince à épiler.
  • Un fer à souder pour certains composants, notamment ceux sur la face inférieure.
  • Du flux et du nettoyant pour flux. (se trouve pas cher)
  • De la pâte à braser. (se trouve pas cher)

La vidéo suivante décrit les différentes étapes d’assemblage:

Si on commercialise un jour un kit nous réaliserons bien sur des instructions plus détaillées, et nous peaufinerons la technique afin de simplifier au maximum!

Ecrire un driver linux pour les ecrans sharp basse consomation

Ecran sharp dans son boitier imprimé en 3d
Ecran sharp dans son boitier imprimé en 3d

Pour l’écran, nous avons choisi d’utiliser un module Sharp de la gamme memory lcd, le LS027B7DH01.
Il possède un fort taux de contraste et reste lisible même sans rétro-éclairage, ce qui le rend extrêmement peu gourmand en énergie, 50 microW d’après le site de Sharp.
Il est monochrome, sa résolution est de 400×240 et sa taille de 2,7″.

Continuer la lecture

Linux boote!!!

Nous avons reçu et soudé le circuit.

2014-06-15-120902

Dans un premier temps, nous avons réussi à lancer u-boot sur le circuit, ce qui nous a déjà ravis, car nous avions enfin accès à une console, même si ce n’était pas encore une console linux. Par contre, le circuit semblait très instable. En effet u-boot ne bootait qu’une fois sur quinze :

HTLC
HTLC
HTLCLCU-Boot 2014.01 (Mar 07 2014 – 13:42:07)CPU: Freescale i.MX23 rev1.4 at 454 MHz
BOOT: SSP SD/MMC #0
DRAM: 64 MiB
MMC: MXS MMC: 0HTLCL0x80501002
HTLCL0x80501002
HTLCL0x80501002
HTLCL0x80501002
HTLCLCU-Boot 2014.01 (Mar 07 2014 – 13:42:07)CPU: Freescale i.MX23 rev1.4 at 454 MHz
BOOT: SSP SD/MMC #0
DRAM: 64 MiB
HTLCLCU-Boot 2014.01 (Mar 07 2014 – 13:42:07)CPU: Freescale i.MX23 rev1.4 at 454 MHz
BOOT: SSP SD/MMC #0
DRAM: 64 MiB
MMC: MXS MMC: 0
*** Warning – bad CRC, using default environmentIn: serial
Out: serial
Err: serial
Net: Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot: 0
mmc0 is current device
** No partition table – mmc 0 **
** No partition table – mmc 0 **
Booting from net …
(Re)start USB…
USB0: USB EHCI 1.00
scanning bus 0 for devices… 1 USB Device(s) found
scanning usb for storage devices… 0 Storage Device(s) found
scanning usb for ethernet devices… 0 Ethernet Device(s) found
No ethernet found.
Wrong Image Format for bootm command
ERROR: can t get kernel image!
=> help
? – alias for help
base – print or set address offset
bdinfo – print Board Info structure
boot – boot default, i.e., run bootcmd
bootd – boot default, i.e., run bootcmd
bootm – boot application image from memory
bootp – boot image via network using BOOTP/TFTP protocol
clocks – display clocks
cmp – memory compare
coninfo – print console devices and information
cp – memory copy
crc32 – checksum calculation
dcache – enable or disable data cache
dhcp – boot image via network using DHCP/TFTP protocol
echo – echo args to console
editenv – edit environment variable
env – environment handling commands
exit – exit script
ext2load- load binary file from a Ext2 filesystem
ext2ls – list files in a directory (default /)
false – do nothing, unsuccessfully
fatinfo – print information about filesystem
fatload – load binary file from a dos filesystem
fatls – list files in a directory (default /)
fdt – flattened device tree utility commands
go – start application at address addr
gpio – input/set/clear/toggle gpio pins
help – print command description/usage
icache – enable or disable instruction cache
iminfo – print header information for application image
imxtract- extract a part of a multi-image
itest – return true/false on integer compare
led – [0|all] [on|off|toggle]
loadb – load binary file over serial line (kermit mode)
loads – load S-Record file over serial line
loadx – load binary file over serial line (xmodem mode)
loady – load binary file over serial line (ymodem mode)
loop – infinite loop on address range
md – memory display
mm – memory modify (auto-incrementing address)
mmc – MMC sub system
mmcinfo – display MMC info
mw – memory write (fill)
nfs – boot image via network using NFS protocol
nm – memory modify (constant address)
printenv- print environment variables
reset – Perform RESET of the CPU
run – run commands in an environment variable
saveenv – save environment variables to persistent storage
setenv – set environment variables
showvar – print local hushshell variables
sleep – delay execution for some time
source – run script from memory
test – minimal test like /bin/sh
tftpboot- boot image via network using TFTP protocol
true – do nothing, successfully
usb – USB sub-system
usbboot – boot from USB device
version – print monitor, compiler and linker version
=> pierre
Unknown command pierre – try help
=>

 

Nous avons passé des heures et des heures à dessouder et à ressouder des composants. Nous avons également essayé de booter par USB via mxsldr pour voir ce qu’il se passait. Cela nous a amené à corriger une faiblesse dans mxsldr, qui est désormais présente sur le git officiel.

Continuer la lecture

Second circuit imx233 avec kicad

Étant donné l’échec du précédent circuit, nous avons décidé de recommencer de zéro en suivant les différents conseils qui ont pu nous pu être donnés sur ce thread. Ce nouveau circuit sera en 4 couches afin de faciliter le routage. Nous avons également décidé de passer la ram sur la couche du dessous afin de faciliter le routage.

Nous avons finalement utilisé la même technique qu’olimex concernant les condensateurs de découplage, c’est à dire remplacer les 33uF par plusieurs 22uF qui contrairement à ces derniers se trouvent dans un format 0805.

shemasProto1.2

Cette fois ci, l’adaptation des longueurs de pistes pour la liaison avec la ram a été réalisée grâce au patch de kicad que nous avons nous même développé (voir cette branche kicad , ce rapport de bug kicad, cette vidéo youtube)

Le routage a cette fois ci été réalisé avec beaucoup plus de précautions, notamment :

*Tous les angles sont à 45 degrés.
*Les condensateurs de découplage sont très proches du imx et de la ram et beaucoup mieux agencés.
*Les pistes de puissance sont plus larges là où cela est possible.

La bobine utilisée est désormais une inductance de puissance et non une inductance RF, comme sur l’ancien circuit. Cette fois nous n’avons pas fait l’impasse sur certains condensateurs comme c’était le cas pour le circuit précédent.
circuitProto1.2

Le circuit contient également un clavier de 49 touches, et un PIC 16f722 qui servira de contrôleur clavier. Il sera alimenté par le 3.3v que sort la imx233 et communiquera avec cette dernière en UART. Un interrupteur est tout de même présent entre afin d’isoler le pic du reste du circuit lors de sa phase de programmation.

Nous n’avons pas résisté également à exporter le model 3D généré par les dernières versions de kicad, et faire un rendu avec le tout nouveau moteur de rendu cyclesboard2

Nous envoyons en production. Nous avons hâte de souder ce circuit et espérons de tout notre cœur que linux bootera enfin!

Télécharger les sources du circuit.

Premier boot avec carte Olinuxino et simulateur Ti

Afin de réaliser les premiers tests, nous avons acheté une carte olimex, une oliunxino imx233 micro. Elle utilise le même processeur que celui que nous prévoyons d’utiliser. Nous pourrons donc l’utiliser pour réaliser des tests de fonctionnement de l’écran, du clavier, ainsi que de la partie logicielle (simulateur Ti, distribution linux, drivers…).

Nous avons pu réaliser un premier test de boot avec cette carte, un écran, notre clavier et notre émulateur Ti.

Sur cette vidéo, l’émulateur Ti est particulièrement lent. Je pense que nous allons trouver la solution à cela.

Simulateur libre Ti

A part l’électronique on aime aussi coder !

tiEmuCode

Afin de ne pas déstabiliser les utilisateurs de calculatrices Texas Instruments, nous avons décidé de coder un petit simulateur libre de l’interface d’une Ti-82 stat, avec la bibliothèque SDL. Ce simulateur pourra ainsi s’afficher directement dans le framebuffer linux. Il ne nécessite pas de rom ti propriétaire, et n’émule pas l’architecture z80, car nous avons recordé nous même de zéro le système de zéro afin qu’il fonctionne sur notre architecture et qu’il soit libre (il ne contient aucun travail propriété de Texas Instrument). N’hésitez pas à télécharger le code sur la page Téléchargements.

Au jour d’aujourd’hui, l’état du projet permet de réaliser les calculs les plus courants, d’afficher une courbe, ainsi que d’exécuter certains jeux en ti-basic, y compris des jeux développés par d’autres pour la calculatrice Ti-82, au format .82p ou .83p.

Nous continuerons à développer ce simulateur afin qu’il finisse par avoir toutes les fonctionnalités d’une vraie calculatrice Texas Instruments.

Vous pouvez télécharger les sources sur github:

https://github.com/LibreCalc/ti
tiEmu

 

Réalisation d’une image système pour ARM : U-boot / Linux / Debian

Aujourd’hui, nous allons travailler sur la partie système de notre calculatrice. L’objectif est de pouvoir lancer nos propres logiciels et de proposer suffisamment de souplesse pour que l’utilisateur puisse lui aussi adapter le système à ses besoins.

Depuis le début du projet, nous souhaitions utiliser un noyau Linux. C’est certainement le noyau libre le plus répandu. En choisissant Linux, nous sommes certains de trouver de la documentation et de l’aide en cas de besoin, en particulier lorsqu’il faudra mettre les mains dans le code pour supporter nos propres périphériques ! C’est aussi certainement le noyau qui supporte le plus de fonctionnalités, et le plus de matériels. De plus, le design de notre board est fortement inspiré de celui d’une Olinuxino Micro, qui utilise un SoC iMX.233.  Ce SoC semble bien supporté par Linux, nous espérons donc une mise en place sans surprise du noyau Linux sur notre board.

C’est donc décidé pour le noyau. Nous pourrions ensuite choisir de lancer directement notre émulateur de TI-83, ou un autre logiciel, directement après le boot du noyau Linux. Mais au contraire, l’intérêt de notre matériel est de fournir un système standard, sur lequel l’utilisateur pourra se sentir à l’aise et en terrain connu. Quoi de mieux alors, pour la distribution logiciels, que Debian ? :-) N’importe quel logiciel ou presque, à portée de apt-get !

Il reste une composante importante du système à déterminer, le bootloader. En effet, le mécanisme de boot du SoC ne permet pas d’amorcer directement sur le noyau Linux. Il faut un composant logiciel intermédiaire, légé, qui chargera le noyau Linux en RAM puis l’exécutera. Le bootloader offre aussi de la souplesse pendant la phase de boot : pouvoir charger le noyau depuis le réseau, depuis une clé usb, sur une partition en FAT32 ou en ext4… Ces fonctionnalités peuvent être utiles !

Notre choix se porte sur U-Boot. En effet, U-Boot est également très répandu, en particulier sur le matériel embarqué, plutôt bien documenté et supporte notre board de référence, la Olinuxino Micro.

En résumé, notre système est constitué de trois composantes :

  • U-Boot, le bootloader. Charge le noyau Linux en RAM et l’exécute.
  • Le noyau Linux. Supporte les périphériques présents sur la board.
  • Debian, la distribution logiciels.

Continuer la lecture

Une calculatrice libre, réalisée avec des logiciels libres, utilisant des logiciels libres, et dont le materiel est publié en open-hardware.