Show Posts
Pages: 1 ... 22 23 [24] 25 26 ... 42
346  Development / Suggestions for the Arduino Project / Re: Is 1.01 pinMode an improvement? on: July 27, 2012, 07:41:09 am
This one is more or less my fault, since I contributed this code.  It was indeed discussed at length MANY times on the developer mail list, about basically these same trade-offs, and especially whether to change "INPUT" or remain perfectly compatible with the old behavior.

First of all, before talking about theory, I'd like to mention practice.  This behavior has been in Teensyduino for 3+ years.  While INPUT was technically changed, in practice the compatibility with virtually all existing sketches and libraries is excellent.  There could be some cases were it matters, but in practice they're extremely rare.  Virtually all published libraries and sketches use pinMode() first, then digitalWrite().  If this had a significant practical impact on real users, my opinion about changing an existing feature would be different.

The trouble with the old INPUT was its ambiguity.  Yes, OUTPUT also suffers the same trouble, but even getting just INPUT and INPUT_PULLUP fixed required years of discussion.  If it were my decision (obviously it's not), I'd add OUTPUT_LOW and OUTPUT_HIGH, and I'd probably make OUTPUT default to OUTPUT_LOW.  But so far, only INPUT has been addressed, as it was much more urgent.

The huge problem with the old INPUT and the lack of INPUT_PULLUP is it drives all Arduino users one of 3 solutions for the pullup resistors:

1: using digitalWrite() in combination with pinMode()
2: direct register access
3: building their own hardware abstraction APIs.

The trouble with these, except perhaps #3, is they are tightly tied to 8 bit AVR's hardware.  Not even 8 bit XMEGA AVR maintains this hardware behavior.  It's hopelessly non-portable.  If you believe you'll forever use only 8 bit AVR (but never XMEGA AVR), that's not an issue.  But if you imagine someday using ARM or other chips, it's a huge problem.  Late as it may be, Due is coming...

From a perspective of serving novice users, which is Arduino's main goal, APIs with quirks like depending on prior state are not very good design.

Regarding alternate pin manipulation APIs, many I have seen envision only non-xmega AVR hardware and are barely more portable to any other chips than directly hitting the registers.  Some are much better.  Designing cross-platform APIs that actually perform well, even on only 1 platform, is quite challenging.

347  Development / Suggestions for the Arduino Project / Re: String corrupts the heap and crashes on: July 26, 2012, 05:08:43 pm
I added a comment to issue 857, linking back to the old issue where I posted the String stuff (after it had been on my website and discussed publicly for months on the Arduino developer mail list).

While posting a "please fix this" comment might do some good, posting a "I install the malloc.c and/or java patch and tested sketch XYZ and my results were [insert results]" is FAR more useful.

Admittedly, testing the java patch is difficult, because you need a working JDK, ant (plus lots of other stuff if using Windows) to recompile the Arduino IDE.  There are instructions, however.....

But testing the malloc.c file is a simply matter of copying the file to the right directory within your arduino-1.0.1 directory.  Even if you're a novice Arduino user with only just enough coding skill to blink an LED and use String, you can certainly contribute by merely copying a file to the correct location and writing up a detailed report of what problems it did & didn't fix (or if it caused any new troubles).

Relatively few people contribute actual code and bug fixes to Arduino, but also very few people contribute by actually testing and writing up a detailed report of the few and contributions fixes that do exist.  Even if you're not a developer capable of fixing bugs, just testing proposed fixes and writing results is a great way to contribute to the project.

348  Development / Suggestions for the Arduino Project / Re: Benevolent dictator or democracy? on: July 25, 2012, 04:26:33 pm
Many of the things that bother me will never change.  For example millis() ticks every 1024 us, sometimes by two ticks to catchup.

Actually, that's almost certain to change on ARM, because the NVIC has a dedicated 24 bit SysTick timer.
349  Development / Suggestions for the Arduino Project / Re: Benevolent dictator or democracy? on: July 25, 2012, 04:21:21 pm
I suppose there are many meaning to the word "fork".  In the context of this "dictator or democracy" thread, I believe Wikipedia's definition is probably representative.

Quote from: Wikipedia
In software engineering, a project fork happens when developers take a copy of source code from one software package and start independent development on it, creating a distinct piece of software. The term often implies not merely a development branch, but a split in the developer community, a form of schism.

Teensyduino is absolutely NOT intended to create "a split in the developer community, a form of schism".

While much of the code I've written might be viewed as "independent development", I do have a long history of trying very hard (sometimes spending much more effort than it took to write the code) to contribute my efforts back to Arduino.

I understand there is much frustration.  Believe me, I know it well.

But I want to be absolutely clear regarding my intentions, when it comes to statements such as Pico's:

Quote from: pico
Why not just fork the project to create a parallel but open and more democratic development path? Paul seems to be already doing just that in many ways with his Teensy version of the development environment anyway. In that way, the "Dicatatorship of the Stony Silence" becomes a non-issue.

I do not intend to fork Arduino, as in Wikipedia's definition above.  Teensyduino is NOT intended to create a parallel but open and more democratic development path.  If anything, Teensyduino is far less democratic than Arduino!  It's narrowly focused on making Teensy work with the Arduino IDE, as well as I can, which sometimes involves fixing the IDE's bugs or adding minor features.  Even if I do add more substantial stuff in the future, I do not intend to create a fork, in the Wikipedia definition sense, that serves as an alternate development path.
350  Development / Suggestions for the Arduino Project / Re: Benevolent dictator or democracy? on: July 25, 2012, 12:24:18 pm
I'm not interested in managing and maintaining a fork of Arduino.  Teensyduino is meant to be an add-on to Arduino, not a fork.
351  Development / Suggestions for the Arduino Project / Re: Benevolent dictator or democracy? on: July 24, 2012, 09:21:58 pm
While the current model isn't perfect, and I've personally found it extremely frustrating on many occasions, one thing is absolutely clear: Arduino is highly successful.

If any changes are made to Arduino's direction, small incremental improvements are probably wisest.

Apparently golden-egg laying geese are best handled with care....
352  Development / Suggestions for the Arduino Project / Re: String corrupts the heap and crashes on: July 24, 2012, 01:26:58 pm
Paul Stoffhegan made  a post a while back about patches he made to the String library to fix these problems that were never adopted by the 'team'.  Perhaps he would be willing to share those changes?

The original contribution I tried to make is still on Arduino's issue tracker.  It was a complete rewrite of String which I created for Teensyduino.  It had the fixes to the memory allocator.  I didn't want anyone using a Teensy board to suffer a buggy String library.

Unfortunately, the Arduino Team didn't use all of my code.  They made many changes, some small, but some that really hurt efficiency.  They also didn't use my fixes for the memory allocator, which is probably why this crashes on Arduino.  They ignored the special compiler options, despite numerous messages I wrote on the developer mail list to explain what a tremendous improvement they provide.

If you want my latest code, it's available as a free download from my website.  Here's the exact link:

Just run the installer, and then grab the files from hardware/teensy/cores/teensy.  You don't need to buy a Teensy board..... but of course I would prefer if you do.  Sales of Teensy are what's what funds all my work and the many contributions I (try to) make back to Arduino.

I've been running the example code on a Teensy board for the last 30 minutes without any problems.  It's reached "Done" many times.  I changed the delay to only 5ms, so it runs the entire test quickly.  This bug absolutely does not happen with my code in Teensyduino.

The installer patches your Arduino IDE, but I'm very careful to never change behavior for non-Teensy boards.  The modified compiler settings and other stuff are only used when you upload to a Teensy board.  The source code for those changes is installed to a "src" directory within your arduino directory.

Sure, we know about fragmentation, but an egregious bug is something else.

Indeed.  I completely rewrote String in Fall/Winter 2010.  While developing this, I used lots of code to log all malloc/realloc/free usage.  I spent MANY long hours carefully analyzing and tweaking so realloc would be used to best effect (depends on a couple compiler options, which they never accepted into  I found and fixed these terrible memory allocator bugs, almost TWO YEARS AGO.

They simply didn't want to use my code as-is.  They decided to accept it piece-wise, making changes.  Some parts, like the special compiler option to elide constructors (saves you from all sorts of memory fragmentation by avoiding unnecessary copies) were never used.  That's really a shame, and one that really sours my attitude about contributing to arduino, because I spent so many long hours carefully studying disassembly of the generated contructor/destrutor code and very long logs of every malloc/realloc/free operation for so many test cases.

They never used the memory allocator fix (which was more-or-less just code I lifted from a newer version of avr-libc).  That's probably why this code crashes on Arduino.  The result is a bad combination of inefficient runtime performance, which only hastens the inevitable crash due to the allocator bugs.  It's really very sad, when I put so much work into avoiding those problems.

I'm still very unhappy at how poorly String turned out for all non-Teensy users.  I tried to contribute a good String implementation back to all Arduino users.  Really, I tried.  I wrote lots of messages explaining the issues.  Much discussion was held.  In particular, Alan Burlison was very unhappy with me and my code (he had planned to do a String rewrite, but never did).  Much heated discussion occurred.  Nobody seemed to appreciate my effort.  The entire process of trying to contribute this back to Arduino was incredibly difficult and painful.  The code sat unused for many months (but of course I shipped it for Teensy boards).  When it finally was partially used, all my suggestions were pretty much ignored.

I fixed all these problems, and if you use a Teensy board you'll get my code as it should be.  If you have a Teensy board, please try running any problematic String examples.  I'm sure you'll see it works quite well (unless you run out of memory, in which case you get empty strings but never a crash).

There's just nothing I can do about Arduino's buggy code.  I really, really did try.  Sorry.

353  Development / Suggestions for the Arduino Project / Re: Bug with IDE 1.0.1 if you change font size the cursor location is wrong on: July 22, 2012, 03:47:22 pm
Please post this to the issue tracker.

You might mention which operating system you're using, and if you really care, a screenshot showing the severity of the problem would be nice.
354  Development / Suggestions for the Arduino Project / Re: Option to bypass "Processing -> C++" pre-processor on: July 19, 2012, 10:53:35 am
Yes the update can prevent rebuilding of certain files for a given sketch under certain circumstances,
but since the IDE doesn't build core or Arduino library archives and store them independently of IDE sketch build area,
the IDE must rebuild library archives when say changing board types or restarting the IDE.

Make, ant, or other build tools can't reuse code between board changes either.  The Arduino core and most libraries contain MANY #ifdef checks on the processor and clock frequency.  When you change to a different board, all that code simply must be recompiled.

Compiled code is indeed not saved between IDE sessions.  Is that really a big deal?  Really?

Long ago, Arduino compiled code to an "applet" subdirectory within the sketch.  The change to using a temporary directory was primarily motivated by Arduino's usage in schools with tightly locked down systems.  One of the few places you can be absolutely certain is writable under even the most strict security is a temporary directory.

An Arduino library being able to call another Arduino library is very problematic with the current IDE build methodology.  Yeah, there is a hack to allow it to work today, but it involves adding header files to the actual user sketch

This is issue #236.  I will fix it.  I would have fixed it about 6 weeks ago, had David not temporarily changed his mind on this issue.

... what concerns me more is that certain things like conditional compilation, (sketch being able to control compilation options of libraries), libraries being able to call other libraries, library code being able to detect and conditionally change based on board type (not processor type, or having to poke around for "magic" defines), being able to source level debug are the killers.

Are you sure that's it?  I mean, really, if these things were all fixed, I have a strong feeling you and many, many others who don't like the IDE still wouldn't like it.

Except for source level debugging, these are all pretty simple things.  Already it is possible for sketches to control library options using C++ templates.  The USB Host Shield library is one that leverages this to great effect.  Others do so much less elegantly with headers to inline some code (my own Encoder library would be a good example of the dirty way).  A standard way to detect the actual board has been an open issue for a long time, and one I'd personally like to patch.  So far, the Arduino developers have shown little interest, but I'm patient and persistent.  As more boards come out, it will become more compelling.  Eventually I will fix that.  Only days ago David (finally) relented and will accept a fix for issue 236, and I will write it in several weeks when I'm done with my current project.

I'm sure there are LOTS of other little things you and many others will name as Arduino IDE deficiencies once all this stuff is fixed.  The simple fact is Arduino is designed to be simple and NOT have lots of advanced options.  There are always going to be lots of things present in AVR/Atmel Studio, Eclipse and Visual Studio that won't be in Arduino.

But I do agree, source level debugging is the big issue.  Of course, it's an absolutely non-starter with AVR.  Atmel absolutely will not provide the debug specs for their AVR chips.  Nobody, other than Atmel, can reasonably work on this (short of impractical reverse engineering) as long as AVR is the platform.
355  Development / Suggestions for the Arduino Project / Re: Total rewrite of the Arduino App needed! on: July 06, 2012, 09:41:21 am
Also, at the current moment, the IDE (version 1.0.1) seem to have this bug that it gives an offset in the line numbers (at least sometimes). Well, I am sure that the developer of IDE version 1 are still ironing out bugs here.

This is, or was, issue #907.

I submitted the patch to fix these line number bugs on May 6.  Unfortunately, that was not early enough to make the 1.0.1 release on May 21, but it was committed to github on May 27, so this is fixed in the latest code and will be in 1.0.2.
356  Development / Suggestions for the Arduino Project / Re: Option to bypass "Processing -> C++" pre-processor on: July 04, 2012, 09:49:59 am
You can bypass the IDE's preprocessing by placing all your code in .cpp and .h files, instead of .ino or .pde.  You still need to have at least 1 .ino or .pde file which has the same name as the directory it's in.  But that file can be empty.

The Arduino IDE supports .cpp, .c, and .h files within your sketch.  They are NOT preprocessed in any way.  If you want to use the normal Arduino functions, you must add the #include <Arduino.h> line in each .cpp file.

Within those .cpp files, you can define classes and use templates.  You can also use them in .ino files, but there's a pretty good chance the IDE's not-too-smart preprocessing step will attempt to extract global-scope function prototypes.  But that preprocessing stuff is NEVER used on .cpp files.

Likewise, the .cpp files are NOT parsed for includes to infer which libraries to link into your code.  So in that empty .ino file, you can place #include <Library.h> lines, merely as directives to the IDE's build system to tell it which libraries to link.  Then you can include only the library headers needed in specific .cpp files which call those library classes.... so your other .cpp files remain free of namespace clutter.

Very few people seem to know this feature exists, but indeed the Arduino IDE does support real C++ compilation without troublesome preprocessing.  You merely need to add the .cpp files to the directory, and then do your coding in those .cpp files instead of .ino files.

Of course, there are a couple C++ things you don't get, not because of the IDE, but due to limitations in the underlying AVR toolchain.  The avr-gcc compiler does not support exceptions, and avr-libc does not provide the C++ stdlib classes & functions.

But you can bypass the preprocessing step.  It's as easy as just creating .cpp files in the sketch directory!
357  Development / Suggestions for the Arduino Project / Re: Option to bypass "Processing -> C++" pre-processor on: July 04, 2012, 09:36:04 am
Mostly just to avoid the unnecessary recompilations, I guess. The "make" way of doing things is to rationally manage a build so things don't get recompiled unless they actually need to be, after all. So a little bit of a speed of build benefit, and probably a bit more satisfaction that things are being done "properly", if you will.

Did you realize Arduino 1.0.1 does this?  Seriously, it does.  I know....

I developed the code, originally in November 2010, as part of a patch on issue 393.  It was resubmitted 1 year later as issue 638.

Last December it was committed into Arduino's github repository, and eventually released as part of Arduino 1.0.1.

I'm sure that does nothing to sway you to prefer the IDE over vim & a makefile... but when talking about ways command-line based make is superior to the Arduino IDE, avoiding recompiling files based on timestamps and dependency analysis has been part of Teensyduino for 1.5 years and now, as of 1.0.1, is officially a feature of the Arduino IDE.
358  Development / Other Software Development / Re: Beta testers needed for a new library that generates true random numbers on: June 29, 2012, 05:02:40 pm
I have also had difficulties with Strings in the past, but there were improvements in 1.0, so I thought I'd give it another go. My expectation would be that it should be able to run pretty much indefinitely.

It should run indefinitely with the String implementation (developed in Teensyduino) which I tried to contribute for Arduino 1.0.  Sadly, the String that made it into Arduino has numerous changes that defeat much of the careful optimization work I did.  My attempt to fix memory allocation problems was also not used.

If it crashes on an Arduino board, could you please give the same sketch a try on a Teensy?

359  Development / Suggestions for the Arduino Project / Re: Compile Speed - testing & feedback needed! on: June 17, 2012, 09:04:03 am
If you move your arduino-1.0.1 from C:\Program Files to just C:\ (at least temporarily for the sake of testing), does that make this magically start working?

FYI: lately I haven't had any time for Arduino hacking... 2 huge project deadlines, one recently passed, the other is a huge interactive fire art installation that shows next weekend.  I plan to look into this issue in early July.  If you could confirm (or refute) that moving the just C:\ fixes the problem before then, please do.
360  Development / Suggestions for the Arduino Project / Re: The Next Uno on: June 04, 2012, 07:05:26 am
Adding a ZIF socket, 7 segment displays (and presumably driver circuitry), and trimmer or small thumbwheel pots would significantly increase the Uno's price.
Pages: 1 ... 22 23 [24] 25 26 ... 42