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.

Messages - cver65

Pages: [1] 2
Wiring Implementations / Re: Why not join forces with Arduino
« on: June 28, 2012, 04:18:47 PM »

though I understand somewhat espanol, Could you please repeat in English ? This forum is not really supposed to be multilingual, at least not on the thread level ...

If you read this thread and a few others, for example related to the MPIDE, you'll probably start to understand that there is very little technical reasons for the split. Is more like a family dispute here IMHO.
Wiring Implementations / Re: Why not join forces with Arduino
« on: May 25, 2012, 08:15:25 AM »
@egnoske, frankly I don't know. My own involvement was put on hold when I bricked my Arduino MEGA and its environment, so I first need to solve "bigger issues" first. I'd like to be able to create a sketch in Wiring and get it on my LPC1343 board from Olimex, but I don't grasp te inners of how the compilers etc. work in the Processing/Wiring world.

I'm ready to do what I can, and I really find it sad that there aren't more people wanting to get the Wiring platform fulfil its promises, but I obviously can't do it alone, and I miss some knowledge. Besides, there is so little activity on github's Wiring project that it looks like no one else is interested getting it forward. Even leaflabs/maple continue to support/improve their own version instead of merging here. I don't understand why.

I tried IAR for the LPC1343, but couldn't get it to work. So for the moment I'm back to arduino0022 platform, using a nano and a DINo. For those I could actually use Wiring as well, but since no one seems to answer the real questions, I stay to my own answer : nobody has time, so nothing happens.

Have you an idea of what would be needed to support LPC on Wiring ? There is no "bootloader" on LPC, it's replaced by an USB disk emulation, so all you need is to generate a "binary.hex" file and write it on the board. But ... how ?
TI MSP430 / Re: Progress on MSP430 Support
« on: April 25, 2012, 02:31:38 PM »
Well, I 'm not very experienced in github, but I think (maybe naively) that the purpose is to get poeple collaborate on projects. What I found on the site was more a number of 'personal' lists of repositories (organised a bit like iTunes : person/repositories), but sometimes the 'person' is an organisation, e.g. arduino/arduino or wiring/wiring.

So if I want to "merge" libmaple and wiring, do I need to first "fork" both, by creating cver65/wiring and cver65/libmaple, and then start create additional directories and copying files, and start tuning those and some make files so that it first compiles and second provides the expected results ?

Or do I understand this completely wrong ?
Website Questions / Re: Potentiometer is not a Photoresistor
« on: April 20, 2012, 02:25:38 AM »
There is actually another issue with the Potentiometer library : its usage of pins. If Wiring adopts the usual convention to number analog pins A0-A5 etc.
Potentiometer should make use of "A0" for pin numbers. This has a number of implications, because for example an Arduino MEGA

Another mistake : there is a hard definition


that makes the library HW dependent... The Maple, that _should_ :-( be supported by Wiring, has a 12 bit resolution...

So this definition should make a reference to some board.txt file.
TI MSP430 / Re: Progress on MSP430 Support
« on: April 16, 2012, 03:55:09 PM »
Hi Rei, all,

Could you explain to me how it exactly works with github ? I'm a bit surprised that there is a need to start a separate project or a personal fork to make a project like Wiring progress ? Shouldn't this be a collaborative effort with a main branch called wiring ?

What are the advantages of "forking" and creating yet another derivative ?
Wiring Implementations / Support of Cortex M3 in Wiring
« on: April 12, 2012, 05:57:35 AM »
As pointed out in a sister thread,37.msg386.html#msg386, I'm interested in supporting 32-bit Cortex chips/boards in Wiring/Arduino platform.

I really welcomed the announcement of joining maple and Wiring platforms ... back in October (2011), but was disappointed to see that nobody really has time to make that happen.

I firmly believe that being able to handle most differences between chips/boards at the library level should be the definitive advantage of the winning platform. Wiring has at least one advantage here : the segregation of libraries between "core" (chip/board specific) and "cross platform" (chip/board agnostic).

Unfortunately, the community is small, time-strapped and apparently unable (until now ;-) to convert people to join.

Here is the place (I hope) where some progress regarding the fusion of libmaple and Wiring could be discussed. My programming skills and time are limited (as everything in life), but even the smartest programmer can't get nowhere without an explicit goal/requirements etc. So shoot : what's needed ?

Unfortunately, I wonder what is the most difficult part of it
Core/Cross-platform Library Questions / Re: boardInit() vs Init()
« on: April 12, 2012, 04:47:22 AM »
Wouldn't a simple

#define Init boardInit

of some kind solve the problem ?

I'm not a C expert, but ...
Don't think so.

Arduino 1.0 decided to break compatibility with Wiring in many places, (without any good reason IMHO), and relationship between Wiring and Arduino "core team" can't be qualified of friendly.

(Why) Should it ?
Wiring Implementations / Re: Why not join forces with Arduino
« on: April 12, 2012, 03:33:47 AM »
Hmm. I feel I have to play devil's advocate here.In cases of miscommunication, usually no party is 100% (or 0%) correct. Are really "most of the others at the Arduino camp [...] stuck with their heads in the sand" ? What about ... the Wiring camp ?

Sure, Wiring is "the original". Sure, Arduino 1.0 is an "Microsoft-like" deviation. But where does Wiring 1.1 stay ? Where are the commits on github ? I don't intend to shoot at the pianist here, but probably "they" have good reasons to believe in their "flawed system".

To me, this is not a "funny thing" at all, it is an occurence of the most annoying weakness of the "Open" community : the NIH syndrome.

Since I believe in _constructive_ criticism and discussions, could you elaborate on where the MPIDE approach is flawed, especially as compared to Wiring's approach ?

Who knows, maybe it could help me understand what I need to do to support my LPC1343 board with Wiring ... ;-)
Programming Questions / Re: Strange behavior on ATmega 328
« on: March 29, 2012, 07:54:13 AM »
Hi Paul,

Actually, you could take the opposite point of view : if you switch boards, you still want digital pin "0" to be "0" and analog "0" to be "A0" as marked on the board. And not having to remember on which port/pin of the chip it is...

That's the very reason for the Wiring framework and similar IDE's to ask you which board you use ;-)

In addition, the framework also care for all the "fuse" settings and other parameters such as pre-dividers for timers etc. One of the very reason most people turn to IDEs like Wiring instead of starting with Eclipse and reinventing that wheel.
TI MSP430 / Re: Progress on MSP430 Support
« on: March 29, 2012, 07:07:48 AM »
Any idea of how much work it would be to do the same for an ARM chip ?
Wiring Implementations / Re: Why not join forces with Arduino
« on: March 29, 2012, 05:30:36 AM »

I looked a bit further in MPIDE, and I clearly was mistaken thinking the project was stalled ! Maybe that is indeed the bandwagon to join for Wiring ? I'm unsure that everything is right regarding the copyrights etc. because the revisions.txt for example, but they appear to at least retrofit both improvements from Arduino (0023) and Wiring 1.0 in their solution.

Now if MPIDE could also support pinguino HW and some Olimex ARM boards, I'd be VERY happy ;-)

Opinions ?
Done. I also commented/supported the idea of aligning with Arduino and Maple by numbering the analog pins starting at the pin number (A0=55 for Mega etc.), like everybody else does. This allows things such as "digitalRead(A0)" to make sense without hassle.
Just found some lackind PIN definitions for Arduino :

Nano has 8 Analog Ins (from 0-7), while standard Uno etc using DIP only have 6.

Result is that A6 and A7 are "undefined" in Wiring while they should be defined (apparently as 6 and 7) in the "c:\Program Files\Wiring\hardware\Arduino\DuemilanoveUno\BoardDefs.h"

I also saw #define TOTAL_ANALOG_PINS       6

That is also incorrect.

Actually, this is strange as I expected to be able to use DigitalRead (A4) correctly, but that won't be the case here either.

To be discussed/solved. Probably the NANO needs to be handled separately after all.
I just was looking for some info on Wirinig libraries, and I really liked the idea of segregating those in "core" (for microprocessor dependent) and "cross-platform" (that should work on any ÁP).

Obviously, some like EEPROM make only sense if there is some EEPROM on the chip, like AVR. However, I was surprised to see that the EEPROM related page was unfortunately not just specific to AVR boards, but to Wiring old generation ... : indeed, the refers to "pin 48" to blink the LED !

OTOH, the page strangely refers to BASIC alternatives far from Wiring, but forgets to include the Arduino MEGA that is more similar to Wiring V1 first column.

There is also an error on that comparison page, the Arduino supports more than 3 PWM outputs, I believe it is 6 (D3 D5 D6 D9 D10 D11).

Maybe not very important, but worth a correction IMHO.

Best regards.
Pages: [1] 2