Show Posts
Pages: [1]
1  Using Arduino / Project Guidance / Re: Driving a shaker with Arduino: is it possible? on: August 28, 2012, 03:40:30 am
How frequently you need to change voltage? What are your requirements for timing and speed flunctuations? How precise the signal must be?

If you need no time drift you would have to use timer interrupt.
2  Development / Suggestions for the Arduino Project / Re: Replace ABI stubs with real implementations on: August 26, 2012, 04:32:44 am
Thanks for yours replies.
Adding/changing error handling in the Arduino environment is likely to be discussion provoking.
I understand this and that's why I've written a post with description of how it works to supply food for discussion. Looks like it was not enough.
I think there is a general resistance to implementing large parts of a C++ runtime library, for example.
I understand this resistance very much. Good implementation of stdlib needs a lot of effort. I can say, that even taking uClibc++ is not a very good choice: it provides quite good realization for basic algorithms, but it has some issues with containers and lacks some optimizations which gnu libstdc++ has, because they were not available when uClibc++ was developed.
That's why my pull request for ABI implementation uses abort() instead of std::terminate. And there is another pull request, which relies on presence of STL and uses std::terminate in ABI implementation. And it still uses small part of standard library, which does not require much effort to implement.
1) Discuss the issue on "developers."
2) Create an "issue" at
3) submit diffs via the issue (so other people could apply it before it is accepted to the official code), and/or via pull request (also somewhat depending on overall complexity of the patch.)
I've made changes without discussion because I needed them myself. Pull requests on github and posts here serve for two purposes: backup copy of my changes and to give other people possibility to use them.
Fighting "management" to get new ideas accepted is certainly one of the less pleasant parts of software development :-(
I understand this but I don't really need these changes to be accepted. Right now I'm working on eliminating/separating usage of arduino libraries from my project because I need it to run on other hardware.
To set your expectations, changes are typically accepted to Arduino typically happen on the time scale of months, not days or weeks.  Yeah, it's slow.
Purpose of these posts was to bring some attention and provoke discussion. When there is no answers it is impossible to say if anybody has noticed pull requests. Arduino team may think on suggested patches or may not think on them for any amount of time. But if you have any additions/objections/considerations about suggested patches I would be glad to discuss them.

3  Development / Suggestions for the Arduino Project / Re: Replace ABI stubs with real implementations on: August 23, 2012, 03:28:58 pm
You should join the "Developers" mailing list, and discuss these changes there.
Well, you see, I've sent pull request 1.5 weeks ago. All interested people have received email notifications, I guess. I also don't believe that developers do not read this forum at all (if it is true, just close it). I've also posted issues to projects related to arduino, such as energia or wiring. Nobody cares.

And I've also seen issues in arduino bug tracker and pull requests about very strange choice for operator new implementation... These issues stay open and uncommented for months. This makes me thinking that nobody cares even more.

So I'm not going to hunt developers and force them to talk. If they want they can easily find a way to contact me. Instead I'll spend my time to make my project as robust as possible and arduino users may continue to have most weird crashes in their projects. If they want.
4  Development / Suggestions for the Arduino Project / operator new and operator delete on: August 18, 2012, 10:58:05 am
Arduino 1.0 has introduced support for new and delete, but, unfortunately, only 1/6 part of required operators are implemented. Another problem is that this 1/6 part does not conform to the C++ standard and leads to undefined behavior in case if you run out of RAM.

There is uClibc++ posrt to arduino which has proper implementation for all required overloads for operator new and delete. But it conflicts with arduino library because both define implementation for the most commonly used operator new(size_t numBytes). You can take it here:

In my opinion ideal solution would be to include STL implementation in arduino project. If you find this not feasible, please resolve conflict with uClibc++ library by either removing incomplete and incorrect realization of operator new and operator delete or by providing correct one (so I would be able to disable it in uClibc++). I would prefer if standard library will not be teared apart.

One of possible solutions:

Here is a description how operator new should handle situation, when malloc returned 0:

5  Development / Suggestions for the Arduino Project / Replace ABI stubs with real implementations on: August 18, 2012, 10:41:53 am
Arduino library implements several gcc specific C++ ABI functions. Unfortunately, instead of real implementations stubs are used. This leads to undesired behavior in some circumstances.

Here is a pull request with better implementations for the functions:
It is not so good because it uses abort() instead of std::terminate from standard library. In case if you are ready to use standard library there is another request:

I've described purpose of these ABI functions and reasons why they must be implemented like I did here:

Thanks. I hope that this post would produce a little more feedback, than pull requests.
6  Development / Suggestions for the Arduino Project / Re: min, max, abs.. are macroses? on: December 29, 2011, 03:51:37 pm
No round?  Did you exclude it on purpose?
In my version of arduino library round is commented out:
//#define round(x)     ((x)>=0?(long)((x)+0.5):(long)((x)-0.5))
So I didn't include it.
You allow the parameters to be different types.  You're not concerned about the possibility of implicit type-conversions?
Right. That's how it is done in gcc's library:
  template<typename _Tp>
    inline const _Tp&
    max(const _Tp& __a, const _Tp& __b)
      // concept requirements
      //return  __a < __b ? __b : __a;
      if (__a < __b)
return __b;
      return __a;
So I think C++ standard allows to have different types here. At first version I didn't allow to have different types but I've got weird errors nearly identical types. Default C++ types have quite logical type conversion rules and class constructors in most cases should be defined as explicit so as to prohibit implicit type conversions. So if your classes are well written you should not be aware of implicit type conversions much.
It uses some C++11 features so -std=gnu++0x flag should be passed to gcc.

I suspect that will not happen.
C++11 is cool. Using it for my project allows me to spend less time and write more readable code. And I really need it for implementing good mixin design patterns. If you use makefiles you can add compiler flag easily. I do use makefiles because I'm used to vim.

I think, that you can find C++99 compliant solutions here:
or here:
But unfortunately I didn't succeeded in compiling these libraries today.
P.S. Using it shouldn't have any impact on program size or speed if you are using macros only with single variables.
In my testing it does.  In some cases this...
template <class T> const T& minT ( const T& a, const T& b )
  return( (a<b) ? a : b );
Produces less code the the min macro.
Well, it shouldn't if you pass single variable to macro which is an advised way to use macro. And it easily can be faster and consume less memory if you pass expressions in-to macro.
7  Development / Suggestions for the Arduino Project / Re: min, max, abs.. are macroses? on: December 29, 2011, 01:05:36 pm
This is what I currently use in my project. Including this file from C++ source would result in undefining macros and defining appropriate templates. Including from C source should have no effect because of macro guards.
It uses some C++11 features so -std=gnu++0x flag should be passed to gcc. It also calls gcc specific abs realizations for floating point types so it is not possible to use this with compiler other than gcc.
I've also defined new and delete operators. As far as I understand they are already defined in latest arduino. So you may need to remove them to compile your project.

P.S. Using it shouldn't have any impact on program size or speed if you are using macros only with single variables.
8  Development / Suggestions for the Arduino Project / Re: min, max, abs.. are macroses? WTF on: December 23, 2011, 05:06:56 pm
I don't mind a good discussion but please watch your language. Definitely if you make statements which are not solid.
1) your language:
It is not macroses but macros
You do not use WTF. Definitely not in a title.
Thanks. I was a little bit upset that I have to reinvent standard library. I've corrected errors.
2) the "must be a function"
The C89 standard you refer to is more commonly known as ANSI C. ANSI C was officially released in 1989. I have been programming in C from 1991 till 2000 for my living. In all those years I used a define for max. It is new to me that this must be a function. If you are sure that ANSI C  states that max must be a function please tell me where this is stated.
The C99 is the newest version of C. The compiler used by the Arduino team is (like most other C compilers) not 100% compliant with C99. As far as I know there is no statement that max must be a function. Please state where it states min max and abs  must be functions. Also refer to where it states all C compilers must comply to C99.
I didn't want to say that max must be a function accordingly to standard. Only abs must, in ANSI C too. I wanted to say that today in 2011, nearly in 2012 there is no need to put user right at the edge of a pit, even if you warn him. Look at this macro:

define sq(x) ((x)*(x))

It squares a variable. Why you would ever like to use it? If you have a single variable x it is easier and shorter to write x*x. But if you have a big statement which you would like to square it is very handy just to put it inside sq(). If sq was a function it would be computationally efficient too.
So if you see that using sq()would ease your life you nearly definitely going to make a mistake. This macro pushes user to a wrong way.
3) No macros but Inline
You state that these macros must be rewritten as inline. Inline is new in C99. It comes from C++. Inline is class related and on a AVR you do not want to have classes for something as basic as integers.
inline has nothing with classes. inline is just a hint for compiler that you would like to inline the function, nothing more. Using inlined function for integer does not convert them to classes.
4) why a macro?
A macro has a great advantage. That is, it works with any type that implements the methods you use. So you do not need a maxint maxlong maxstring.....
Actually this macro works only with different types of integers, float, double, pointers which can be implicitly converted to void*. If you have operator< defined for other type you are already using C++ and you can use templates which are much better then macro in this situation.
5) You are right there is a risk with macros
On the content you are right that
will result in MyNumber being 7 and not 6;  This is however a design decision that has been taken a long time ago on very good ground by people that didn't know about Arduino because it simply didn't exist yet. So blaming Arduino is not the way to go. It has been like this for decades now. I feel no sense of urgency.
If you look at main page you ca read "It's intended for artists, designers, hobbyists, and anyone interested in creating interactive objects or environments". Time has changed, programming languages has changed.This design decision was made "a long time ago on very good " old ground. Artists, designers, hobbyists do not need carefully documented well known rakes. 20 years ago it was the best solution but now we have more fool proof programming technologies. Which are still as efficient as old ones. They can be even more efficient in some cases.
6) overloaded functions from C++ std
I see no reason why you could not overload. You can use the #undef instructions if you want.
Thanks for the hint. I've did it for my building environment.
9  Development / Suggestions for the Arduino Project / Re: min, max, abs.. are macroses? on: December 23, 2011, 02:29:53 pm
I understand, that it is not possible to write in ANSI C, but current implementation do not conform to C99 or C89 because abs must be a function. And these macro prevent form defining good overloaded functions from C++ std:: namespace.
And I'm sure that these macroses do much more harm than good: they behave differently than functions with the same names on other platforms. They look like functions but the do not work like functions. It means that someone not familiar to arduino is unable to read/write programs with these macroses.
10  Development / Suggestions for the Arduino Project / min, max, abs.. are macroses? on: December 23, 2011, 01:06:52 pm
Why on the earth these functions are defined as macros:

#define min(a,b) ((a)<(b)?(a):(b))
#define max(a,b) ((a)>(b)?(a):(b))
#define abs(x) ((x)>0?(x):-(x))
#define constrain(amt,low,high) ((amt)<(low)?(low):((amt)>(high)?(high):(amt)))
//#define round(x)     ((x)>=0?(long)((x)+0.5):(long)((x)-0.5))
#define radians(deg) ((deg)*DEG_TO_RAD)
#define degrees(rad) ((rad)*RAD_TO_DEG)
#define sq(x) ((x)*(x))

This is dangerous and leads to strange behavior when you supply calculated values to these functions because values are calculated twice. They definitely must be rewritten as inline functions. This would make them much more robust and much faster.

I can write appropriate patch if you want.

Moderator edit: [code] [/code] tags added.
Pages: [1]