Tim,

Avenue33, did you try my project template with XCode 4? I think you can just open it as a normal project with XCode4.
I don't have a computer that runs Lion yet, so I can't test this.

The templates on Xcode 4 are totally different from and incompatible with those on Xcode 3.

Building fails with the following error message:

Code:

    make

pic32-g++    -Wl,--gc-sections -mprocessor=32MX795F512L -Xlinker -T/Applications/Mpide.app/Contents/Resources/Java/hardware/pic32/cores/pic32/chipKIT-MAX32-application-32MX795F512L.ld -Xlinker -o/Users/avenue33/Desktop/Xcode_chipKIT/main.elf -Xlinker -M -Xlinker -Map=/Users/avenue33/Desktop/Xcode_chipKIT/main.map
/Applications/Mpide.app/Contents/Resources/Java/hardware/pic32/compiler/pic32-toavenue33/bin/../lib/gcc/pic32mx/4.5.1/../../../../pic32mx/lib/cpp-startup.o: In function `_main_entry':
(.text+0x10): undefined reference to `main'
collect2: ld returned 1 exit status
make[1]: *** [/Users/avenue33/Desktop/Xcode_chipKIT/main.elf] Error 1
make: *** [build] Error 2
Command make failed with exit code 2

On top of that, Xcode doesn't recognise the symbols and doesn't jump to the definition.

Enclosed the culprit.

My template for chipKIT is broken and I don't know why

I hope you'll be luckier than me

@Westfw

Feel free to join the project.

As the thread title stands, we plan to deal with Xcode.

Presently, the linker problem is solved and Xcode can compile sketches with #include libraries.

Now, next step is a template.

[button_main.pde]

Bonsoir,

Le plus simple est peut-être de commencer par les exemples fournis, comme button_main.pde

Code:

#include "WProgram.h"
#include <Wire.h>

#include "Serial_LCD.h"
#include "button.h"
#include "proxySerial.h"

// Arduino Case ---
#include "NewSoftSerial.h"
NewSoftSerial nss(2, 3); // RX, TX
ProxySerial mySerial(&nss);

Serial_LCD myLCD( &mySerial);

uint16_t x, y;
uint32_t l;

button b7( &myLCD);



void setup() {
  Serial.begin(19200);
  Serial.print("\n\n\n***\n");

  myLCD.begin();
  myLCD.setOrientation(0x03);

  Wire.begin();

  myLCD.setPenSolid(true);
  myLCD.setFontSolid(true);

  myLCD.setFont(0);
  myLCD.gText( 0, 210, 0xffff, myLCD.WhoAmI());

  myLCD.setTouch(true);

  l=millis();

  uint16_t i=9;
  b7.define( 160, 120, 79, 59, "arreter tout    ",        myLCD.rgb16(0xff, 0xff, 0xff), myLCD.rgb16(0xff, 0x00, 0x00), myLCD.rgb16(0x88, 0x00, 0x00), i);

  b7.enable(true);
  b7.draw();

  myLCD.setFont(1);
  myLCD.gText(0,  0, 0xffff, "         1         2         3         4");
  myLCD.gText(0, 20, 0xffff, "1234567890123456789012345678901234567890");
  myLCD.gText(0, 60, 0xffff, ftoa(myLCD.fontX(), 0, 8));

  myLCD.setFont(0);
  myLCD.gText(0,  80, 0xffff, "         1         2         3         4         5");
  myLCD.gText(0, 100, 0xffff, "12345678901234567890123456789012345678901234567890123");
  myLCD.gText(0, 120, 0xffff, ftoa(myLCD.fontX(), 0, 8));
}

uint8_t c;

void loop() {

  c=myLCD.getTouchActivity();

  if (c>0) {
    myLCD.getTouchXY(x, y);
    myLCD.setFont(0);
    myLCD.gText(200, 0, 0xffff, ftoa(x, 0, 5));
    myLCD.gText(200, 15, 0xffff, ftoa(y, 0, 5));

    // quit
    if (b7.check()) {
      myLCD.off();
      while(true);
    }



  }
  myLCD.setFont(0);
  myLCD.setFontSolid(true);
  myLCD.gText( 250, 225, 0xffff, String(millis()-l));
  l=millis();
}

I agree with this approach: all the parameters are on the files

/Applications/Mpide.app/Contents/Resources/Java/hardware/arduino/platforms.txt
/Applications/Mpide.app/Contents/Resources/Java/hardware/pic32/platforms.txt

The Arduino IDE or the chipKIT MPIDE are great tools. However, they are closed.

Both Arduino and chipKIT should disclose more so any standard IDE could be used: Visual Studio, Eclipse, Xcode, to name a few.

I fully agree with you.

I find here an extensive list of Arduino-related makefiles.

What we need:
• Actions: Build and Upload
• Boards choice: Arduino UNO, ... , chipKIT UNO32
• #include libraries compiled and linked
• Xcode template

I could easily close my repository and point to yours.

Is there an Xcode specialist around? Please!

Best regards,

Bonjour Franck,

Ce que j'ai compris (en d’autres thermes), la dalle est soit pilotable à 100% par l’Arduino (mode SGC), ce qui consomme de grosses ressources à l’Arduino (taille programme et temps d’occupation µC).

L'écran possède son propre contrôleur, donc l'Arduino envoie seulement des commandes du genre

Code:

myLCD.rectangle(100, 100, 200, 200, myLCD.rgb16(255, 0, 0));

Je n'utilise que le mode SGC. Inutile de se lancer dans le GFX.

Comme il n'y a pas d'interruption, l'Arduino doit constamment surveiller l'état de la dalle tactile.

Peux tu nous donner une idée de ce que représente, en taille programme, le traitement de ton écran ?

A partir des exemples disponible dans le répertoire GitHub,

• serial_hardware_main
• serial_software_main
• serial_i2c_main

Binary sketch size: Libraries proxySerial + LCD_Serial + button pour Arduino UNO / chipKIT UNO32

• liaison série matérielle 11840 / 20664
• liaison série logicielle (avec NewSoftSerial) 14158 / non disponible
• liaison série I2C (avec I2C_Serial) 13642 / 23554

Par contre la compréhension du support de liaison m’échappe encore.

Plutôt que de rédiger 3 librairies, une par type de liaison série, j'ai développé une couche d'abstraction matérielle (Hardware Abstraction Library) ou pilote (driver) proxySerial. Les trois liaisons série sont des classes dérivées de Stream et j'utilise les propriétés offertes par les objets.

J'utilise cette même librairie proxySerial pour mon GPS.

Bien que j’ai une idée en tête que je développerais ci-dessous, la Duemilanove dispose bien d’un port I2C (broches 4 et 5 que j’ai laissé libre sur mon application). Pourquoi y rajouter une interface SC16IS750 ? Cette sortie I2C ne permet-elle pas les 2 modes de fonctionnement en direct (GFX et SGC) ?

L'interface SC16IS750 se branche sur le port I2C et ajoute un port série. Elle possède un tampon de 64 octets et sa vitesse est paramétrable.

Puisque ma Duemilanove est en fonctionnement 24/24h, et qu’il me semble préférable d’éviter de trop toucher ce qui est maintenant fonctionnel.

Il ne faudrait surtout pas que les poissons soient les victimes d'explorations robotiques !

Je pourrais donc faire l’acquisition de ce chipkit Uno 32 pour développer mon interface de dialogue. Et ensuite rebasculer le soft actuellement en place dans la Duemilanove vers la chipKit, pour finalement interchanger les cartes.
A condition que mon appli actuelle soit compatible (librairies servos et PID, utilisation des PWM avec modif des prescalers, …).

J'ai détaillé ici les difficultés que j'ai rencontrées lors de mon passage de l'Arduino à chipKIT.

Sinon, je me retrouverais avec 2 cartes… Et de la redondance possible 

Elles peuvent toujours dialoguer via I2C : l'une est maître, l'autre esclave !


Bien cordialement,

Bonjour,

Si cela peut vous aider, j'ai développé une librairie pour gérer des boutons et des boîtes de dialogue.



Le code se trouve ici et la documentation là.

Déclaration et affichage

Code:

button b7( &myLCD);

b7.define( 160, 120, 79, 59, "stop all", myLCD.rgb16(0xff, 0xff, 0xff), myLCD.rgb16(0xff, 0x00, 0x00), myLCD.rgb16(0x88, 0x00, 0x00), 9);
b7.enable(true);
b7.draw();

Boucle principale

Code:

void loop() {
  if (b7.check()) {
    myLCD.off();
    while(true);
  }
}

Et c'est tout!

Bonsoir,

Oh, des Français qui parlent français sur du matériel italien ! Les Français parlent donc aux Français.

Problème classique qui a également été le mien : avec l'expérience des projets, l'imagination dépasse les capacités du matériel !

J'utilise depuis plusieurs mois l'écran μLCD-32PT(SGC) 3.2” Serial LCD Display Module de 4D Systems. C'est un véritable système tout-en-un avec processeur dédié, carte SD, sortie son, écran tactile.

J'ai rédigé une librairie avec trois couches :

• le niveau supérieur, optionnel, regroupe les libraries avancées (graphiques, boutons, fenêtres, ...)
• le niveau intermédiaire constitue la librairie principale de gestion de l'affichage
• le niveau inférieur est une couche d'abstraction matérielle qui permet d'utiliser indifféremment des ports série matériel, logiciel (NewSoftSerial version 11) ou I2C (carte SC16IS750).

Le nombre de ports série matériels est limité sur une carte Arduino Duemilanove.

Deux possibilités :

• utiliser un port série logiciel, mais NewSoftSerial prend de la place
• utiliser un port série I2C avec la carte SC16IS750 de Sparkfun. C'est la solution que j'utilise.

En complément ou en remplacement des solutions proposées ci-avant, pourquoi ne pas considérer la carte chipKIT UNO32 ?

• 80 Mhz 32-bit MIPS
• 128K Flash
• 16K SRAM
• format Arduino™ Uno
• 42 I/O dont 2 ports série, 1 port I2C, ...

L'environnement de programmation est MPIDE, compatible avec celui de l'Arduino 0022. Quelques points sont à surveiller, notamment les types de données. Par exemple, int signifie int16_t pour Arduino mais int32_t pour chipKIT !

Sur Roboshop,

• Carte chipKIT UNO32 25€
• Carte SC16IS750 14€
• écran tactile couleur 3,2" version SGC 72€

Bien cordialement,

[release 14]

This new release 14 brings some novelties:

• proxySerial library is now a stand-alone library.
• It can now be used by other libraries, as Serial_GPS.
• It includes utilities like ftoa

Let's have some fun! I ported this game of life and it runs pretty fast on the chipKIT.
Integers only, pixels updated if changed, fast serial at 115200.



More details on my website.

Enjoy!

Hi!

Please find on this GitHub repository a Xcode project for Arduino UNO.

• Xcode 4 on Mac OS X.7
• MPIDE 0022 based on Arduino IDE 0022

I tested it successfully with the Arduino UNO and the chipKIT UNO32 platforms.

The Xcode 3 template is no longer valid because Xcode 4 has changed everything about the templates.

More details on my website.

I'd greatly appreciate some help on Xcode 4 about templates and libraries linking.

[new release 13]

Thanks to the work of the chipKIT / MPIDE team, the hardware serial class for the chipKIT platform is derived now from the Stream class as NewSoftSerial and i2cSerial are.

More important for LCD_Serial, the new release 13 offers multiple options: hardware, software and I2C serial ports can be used to drive the screen.

Learn more about the multiple serial options with examples!

I gave a try.

Result is, I should re-write the LCD_Serial entirely to deal with the Stream and Print classes.

The Stream and Print classes management is done by the proxySerial library. Everything works fine so I stay unchanged.

But feel free to participate and improve that library! You're welcome

Sorry for the misunderstanding. I'll give a try.

Yes, this is what I did.

Code:

ProxySerial::ProxySerial(Stream * port0) {
  _proxyPort = port0;
}

You're welcome!

The box is important to keep the LCD safe.