Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - rei_vilo

Pages: [1]
Wiring News / Is Wiring Back?
« on: May 25, 2016, 06:24:42 AM »
According to Sneak peek: Arduino’s Primo and Primo Core IoT duo, Arduino.ORG is working again with Hernando Barragán, the initiator of the Wiring framework, on which Arduino and Energia are based.

“Developing the Arduino IDE for the Primo and Primo Core is our main focus right now,” continues Giori. “In other words, the ‘Hello World’ of Arduino is to blink an LED (blinky sketch) and if you download that same sketch that runs on an Uno to your Primo, it will ‘just work’. The big effort for Arduino software developers is that this board does so much more than an Uno. The number of libraries and APIs has to therefore grow accordingly. Our software developers coordinate with Hernando Barragan, the author of Wiring which became the Arduino IDE, so our goal of course is to maintain the ease-of-use principle as we expand the core libraries."

Nice to see Wiring back! Should we expect Wiring++?
Exhibition / 4D Systems Screens: A Genie for Your Wiring Sketch
« on: December 18, 2012, 03:07:17 AM »
Users of my Serial_LCD Library Suite already know 4D Systems, the maker of the screens on which my Serial_LCD library runs.

4D Systems has just released a major update of its IDE Workshop with an outstanding feature: ViSi-Genie.

ViSi-Genie allows to build a professional-looking graphic user interface very easily.

It only requires to drag-and-drop elements, including buttons, sliders or more elaborate ones, and define the events associated, like pressing a button or moving the cursor on a slide-bar.

Read my review with an example completed in just a couple of minutes!
The Wiring S Play Shield is potentially hazardous.

There is a risk of short circuit between the pins number 1 and 8 of the U2 chip for EEPROM and the ground of the USB connector, as shown in the picture.

As a result, I fried the 2 chips, the DS1307 RTC and the 24LC256 EEPROM. As a collateral damage, I burnt one finger.
With the embedXcode template, I'm dealing with 6 different Processing-based IDEs with Wiring-derived frameworks: Arduino 0023 and 1.0, Wiring, Maple IDE, chipKIT MPIDE and LaunchPad MSP430 Energia.

Needless to say none is fully compatible. So when I develop a library I want to use on different boards, as the Serial_LCD library suite, I need to test the MCU, ending in such inelegant code :-\ as:
Code: [Select]
// Core library
#if defined (__AVR_ATmega328P__) || defined(__AVR_ATmega2560__) // Arduino specific
#include "WProgram.h"
#elif defined(__32MX320F128H__) || defined(__32MX795F512L__) // chipKIT specific
#include "WProgram.h"
#elif defined(__AVR_ATmega644P__) // Wiring specific
#include "Wiring.h"
#elif defined(__MSP430G2452__) || defined(__MSP430G2553__) || defined(__MSP430G2231__) // LaunchPad specific
#include "Energia.h"
#elif defined(MCU_STM32F103RB) || defined(MCU_STM32F103ZE) || defined(MCU_STM32F103CB) || defined(MCU_STM32F103RE) // Maple specific
#include "WProgram.h"
#else // error
#error Platform not defined

As at today, some of the IDEs have specific definitions passed on as arguments to the compiler and linker:
  • Arduino uses -DARDUINO=23 or -DARDUINO=100,
  • Wiring has -DWIRING=100
  • and MapleIDE uses -DMAPLE_IDE.
  • Energia for LaunchPad is considering -DENERGIA=6
  • and chipKIT sticks with -DARDUINO=23 -Danything_you_want -Danything=1.

The question is, in the new Wiring framework, is there a clean way for identifying the platform and its corresponding framework?

The main benefit is a more readable code, as:
Code: [Select]
// Core library
#if defined(WIRING) // Wiring specific
#include "Wiring.h"
#if defined(MPIDE) // chipKIT specific
#include "WProgram.h"
#elif defined(ENERGIA) // LaunchPad specific
#include "Energia.h"
#elif defined(MAPLE_IDE) // Maple specific
#include "WProgram.h"
#elif defined(ARDUINO) && (ARDUINO >= 100) // Arduino 1.0 specific
#include "Arduino.h"
#elif defined(ARDUINO) && (ARDUINO < 100) // Arduino 23 specific
#include "WProgram.h"
#else // error
#error Platform not defined

The test on ARDUINO comes last as some IDE may use two definitions.
Exhibition / LCD_screen Library Suite
« on: March 24, 2012, 11:11:37 AM »
Jump to the new LCD_screen Library Suite!

Please find the new LCD_screen Library Suite that replaces the Serial_LCD Library Suite.

The LCD_screen Library Suite supports a wider range of SPI and 16-parallel affordable screens, apart from the 4D Systems Picaso-based serial screens.

Enjoy :)

The 4D Systems μLCD-32PT(SGC) 3.2” is a really amazing screen, providing touch control, micro-SD-card reader, sound player and its own dedicated controller.

I've developed the Serial_LCD library suite based on three layers
  • top level for end-user libraries like dialogs and buttons
  • core library with screen management, i.e. Serial_LCD
  • hardware abstraction layer with proxySerial to ensure proper dialog through hardware, serial and I2C serial ports

The library suite works with Arduino boards —with both 0023 and 1.0 IDEs— and Diligent chipKIT PIC32-based boards.

I'm presently porting it to Wiring. Because I'm waiting for a Wiring S board, I haven't fully tested it yet. Building works fine, but I don' know how uploading works.

This library suite works with all 4D Systems screens, μLCD, μOLED and μVGA. It handles text and graphic display, touch, SD-card and sound.

High level library GUI provides label, buttons, menu, dialog box.

High level library Graphics provides clock, gauge and histogram graphics.

Hardware, software and I2C serial connections are managed through the proxySerial library.

• Serial_LCD: contains the core functions
• proxySerial: manages hardware, software and I2C serial port
• button / GUI: provides basic GUI with high level button, dialog window, menu and label.
• Graphics: provides ready-to-use graphics as histogram, gauge, clock, direction, yaw, pitch, roll, ...
• Gallery: use the screen as a picture frame!

Find full documentation, including tutorials, examples and code at 4D Systems μLCD-μLED-μVGA Serial_LCD Library.

Enjoy :)
Is Wiring 1.0 build 100 Arduino 1.0 compliant?

Code: (Wiring print.h) [Select]
class Print
    // pure virtual - must be implemented by derived class
    virtual void write(uint8_t) = 0;

    // virtual - can be redefined (polymorphic class)
    virtual void write(const char *str);
    virtual void write(const uint8_t *buffer, size_t size);

write is void with Wiring 1.0 while returning size_t with Arduino 1.0

Code: (Arduino 1.0 print.h) [Select]
class Print
    int write_error;
    size_t printNumber(unsigned long, uint8_t);
    size_t printFloat(double, uint8_t);
Core/Cross-platform Library Questions / boardInit() vs Init()
« on: March 08, 2012, 09:18:36 PM »
Wiring uses boardInit() instead of Init() as Arduino or chipKIT do.

However, all 3 are implementations based on the same Processing.

Is there a specific reason for the boardInit()?

For better compatibility, couldn't boardInit() be changed for Init()?

This is one issue I'm presently facing on my embedXcode project, embedded computing on Xcode.
Pages: [1]