Show Posts
Pages: 1 ... 23 24 [25] 26 27 ... 40
361  Development / Suggestions for the Arduino Project / Re: Found lousy boo-boo in arduino IDE generated compilation commands on: March 28, 2012, 07:05:20 am
The way the IDE does its build now, you pay the price for separate module compilation,
without gaining the benefits like the ability to avoid re-compiling modules that have already been compiled.

That really depends on your definition of the word "now"  smiley

Yes, that's how Arduino 1.0 works.

But the code on github, soon to become Arduino 1.0.1, has a patch I wrote many months ago which avoids recompiling code.  It works more or less like you described, except it doesn't retain the .o files or a .a library for each board setting.  It simply uses the .o files left over in the temporary directory.

This feature has existed in Teensyduino for nearly 1 year.  Very soon it will be in Arduino.

Placing all the .o files for each library into a .a archive probably doesn't provide much benefit.  If the archives were retained in a non-temporary directory, it could speed up the first compile when you begin running Arduino, or the first compile after changing to a different board (that's been used previously).  That might be nice, even though it's a much less common case, but accomplishing that would take a pretty substantial patch.  I doubt anyone will actually work on such a patch, and even if they did, I believe David probably would be reluctant to accept it.

One other thing to consider is where Arduino can write files.  Long ago, it would create an "applet" subdirectory within the sketch folder and put the compiled files there.  But that behavior caused all sorts of problems when compiling the examples, because many schools would install Arduino on a read-only networked filesystem.  To solve that, the temporary directory was used for examples, but applet was used for normal sketches.  Eventually, the "applet" subdirectory was removed, so Arduino would only attempt to write to the temporary folder.  Writing all generated files to the temporary directory greatly improved satisfaction with Arduino among security conscious users, and the linux distros who now package Arduino to work across several "standard" locations.

Any proposal to store compiled archives must carefully consider the restrictive shared network filesystems which are used by many academic institutions.  A patch which returns Arduino to the "bad old days" of writing within its own directories is certain to be rejected.

I was saying the copying of the source files to this build area should not necessary.
It should be possible to compile the code with the source files in place
and redirect the output objects to the very same place they are currently are.
(avoid the copy of the source files)

The library and core source files are never copied to the tempoary build directory.  Only the sketch source is copied, and for good reason...

Arduino concatenates all the .ino & .pde files (if there's more than one) and does some preprocessing, mainly to automatically add #include <Aduino.h> and function declarations, which allows functions to call each other regardless of their order within the files.

Perhaps that preprocessing step could be done entirely within memory, with the result fed into the compiler via a pipe?  But that would require quite a bit of extra java code.  It's currently written in a fairly simple way, where all the .ino / .pde files are turned into a single (temporary) .cpp file, before the "Compile" step is even begun.  While compiling, gcc is run using pretty much the same code with works on a paradigm of files being compiled to produce other files.  If the preprocessed output were never written to disk, not only would the preprocessing code need to be changed to more complex code to manage the whole thing in memory, but the compile code would need to run gcc differently for one part where the input isn't a file, and the entire structure within Arduino would need change to pass the in-memory copy between the "Sketch" and "Editor" sections and the "Compile" object.

That would be a monstrous patch, only to avoid writing one temporary .cpp file!

More importantly, as the Dr pointed out in the OP,
the way the IDE works, you are stuck having to add includes to the main sketch
in order to get the include path setup to allow other modules to compile.

And that is the main thrust of the the Dr's comment in the OP.
It was that in order for a module to use any
code form a library, the main sketch must include a header file from that library
to get the IDE to do some "magic" things and set up the include path.

I have often considered writing a patch to fix this.  It doesn't look like anyone else is ever going to do it....

I'd probably just reuse the existing parser that preprocesses the .pde / .ino files to extract a list of the #includes from all .cpp files, as if they'd been in the user's sketch.  But if there's something special it should do, please enlighten me?

362  Using Arduino / LEDs and Multiplexing / Re: ShiftPWM support topic. Latest update: ShiftMatrixPWM needs testing on: March 27, 2012, 04:22:55 pm
The Wire library doesn't use any timers.  I'm not sure why it would hang, other than it may be a bug in Wire itself?

Servo does indeed use timers.  You can edit Servo.h to configure which timers it will use.  It's pretty easy to make Servo use only timer1 or timer3 on Teensy or Teensy++.  Look in Servo.h for details.

Here's a photo of ShiftMatrixPWM....

363  Development / Suggestions for the Arduino Project / Re: Will we ever see higher spec chips in the Arduino on: March 23, 2012, 12:03:44 pm
...but if it's somehow shoehorned into a larger single IDE I think we could be in for a rough ride ahead. I can easily ignore the Due when released if I choose to just by not buying one, but I can't ignore the existing 8 bit IDE if its drastically changed to support the Due.

If we ignore its many bugs, the MPIDE used my ChipKit is a pretty good example of repurposing the Arduino IDE to work with a 32 bit boards and remain compatible with 8 bit Arduino boards.

Even on Arduino, there's lots of projects, shields and libraries that do fairly complex stuff, usually assisted by off-chip hardware.  How is that so much different from the IDE supporting a more powerful chip which can do some of those things in its own software?

Even now, the Ethernet library is being extended with better support for protocols like DHCP and probably soon a library for HTTP.... on 8 bit Arduino.

I just don't understand these doom-and-gloom predictions.  Maybe you could elaborate in more detail?
364  Development / Suggestions for the Arduino Project / Re: COMPUND STRINGS for SERIAL.PRINT() on: March 19, 2012, 10:33:38 am
Serial.println(String("reg1 is ") + String(reg1));
365  Using Arduino / Audio / Re: precision rotary encoder midi controller on: March 18, 2012, 08:04:15 am
For interfacing those rotary encoders, you'll probably want to use my Encoder library....

It provides "4X" counting, so a commonly available 24 pulse/rev encoder will give you 96 steps per revolution.  Of course, there are much higher precision encoders available, but they tend to be expensive.  Maybe for your application they're worth the cost?

The library works best if every encoder uses at least 1 interrupt pin.  Arduino Uno only has 2 such pins, so if you plan to connect more than 2 encoders, you might want to consider using a board with more interrupts available.

366  Using Arduino / Microcontrollers / Re: Resetting the Arduino Uno R3 Atmega16U2 on: March 18, 2012, 06:57:08 am
my uno r3 stopped responding after setting the baudrate to 14400 and started to create a new serial (/dev/ttyACM*) port with each reset.

Last time I looked (about 3 years ago when Teensy started and all Arduino boards were still FTDI), multiple software issues all combined in a terrible way.

1: Linux cdc_acm driver didn't support 14400 and 28800 baud settings.

2: The RXTX library behaves badly when an unsupported baud rate setting is configured.

3: Arduino remembers and applies the old setting before giving you the serial monitor window, and won't accept a new setting after RXTX starts misbehaving.

The net result was choosing either of these baud rates made the board forever inaccessible.  The only way to fix it was editing the prefs file to change back to a supported baud rate.

One of the many patches Teensyduino installs is a tiny bit of code which silently turns 14400 into 19200 and 28800 into 38400 if Linux is in use, and a Teensy board is selected.  I'd pretty much forgotten about this little problem until now....

Hopefully this explanation helps?
367  Development / Suggestions for the Arduino Project / Re: Will we ever see higher spec chips in the Arduino on: March 16, 2012, 11:40:58 am
But to my mind the Due is not about sheer numbers of GPIO pins, it is about the speed and internal memory. This opens up the possibility of using it for projects that currently beginners think the Arduino is capable of doing. Stuff like MP3 decoding, web cam interface, audio record and playback, image processing, LCD graphics display driving, digital signal processing, FFT and recognition and so on. The sort of stuff young people think a computer should do easily.

Yes, indeed.  But it's going to take so much more than just a chip to make these things happen.

At the very least, Arduino Stream and Print classes will need to support some way to connect together like "pipes" (probably leveraging DMA), so data incoming on a stream gets automatically pushed into a mp3 decoder and/or signal processing library, and its output stream gets automatically pushed to a I2S output.

An incredible amount of software work is needed.  Nothing impossible, but a huge amount of tough work and much of it focused on good performance.  That seems very unlike the current pace of Arduino software development.

368  Development / Suggestions for the Arduino Project / Re: Compile Speed - testing & feedback needed! on: March 16, 2012, 11:02:14 am
Glad to hear Teensy is working out so well.   smiley

This speedup was accepted into Arduino and will be in version 1.0.1.  If you're using Teensy, you already have it.  For normal Arduino, it can be tested now in the release candidates:

Mac OS X:
Linux (32-bit):
Linux (64-bit):

If anyone reading this wants an easy way to help Arduino development, installing and using the release candidates NOW and reporting any issues soon would really be good.

369  Development / Suggestions for the Arduino Project / Re: Will we ever see higher spec chips in the Arduino on: March 14, 2012, 03:11:01 pm
Indeed, just because it's an official Arduino board doesn't mean it will be 100% compatible.

Consider Arduino Mega.  For nearly a year, almost no major 3rd party libraries supported it.  Even some of the ones shipped with Arduino didn't work.

Arduino Mega support in many of the more complex libraries is a result of my porting efforts for Teensy.  Firmata, which now ships pre-programmed on all Arduino boards, would be a good example of a library which became compatible with many other boards only because I added a hardware abstraction layer in the process of porting it to Teensy.  I've ported several others over the last couple years, when clearly nobody else intended to do so.

That's just slightly different AVR chips.  The situation will be much harder for a completely different chip.  Look at the library compatibility lists for Maple and ChipKit.  They're short lists.  It's not impossible, but it does take a lot of time and effort to port so much code to very different hardware.  Believe me, I know....
370  Development / Suggestions for the Arduino Project / Re: Speeding up development by uploading tested code. on: March 11, 2012, 06:01:00 pm
From the Arduino developer mail list today:  (notice the 4th item on the list of changes)


Hi all,

I just uploaded the release candidate of Arduino 1.0.1:

Mac OS X:
Linux (32-bit):
Linux (64-bit):

Please try it out and report and problems.  The final release is
targeted for the start of April.

You can see a list of related issues here:
Commit log here:

In particular, changes include:
- fixing the ArduinoISP sketch (lowering baud rate from 19200 to 9600)
- internationalization and Japanese translation
- including of AVR toolchain on Linux
- improved compilation speed (only compile changed files)
- addition of INPUT_PULLUP argument to pinMode()
- ability to do repeated starts in the Wire (TWI) library
- Ethernet.maintain() function for renewing DHCP leases
- various other bug fixes and improvements

Thanks to everyone for their contributions!

371  Development / Suggestions for the Arduino Project / Re: Speeding up development by uploading tested code. on: March 07, 2012, 06:25:39 pm
I already did this.  It was issue #638.  No need for a kickstarter!  But if you want to contribute financially, this work and pretty much all my Arduino contributions and libraries are funded by PJRC's sales of Teensy...

David committed my patch to github on December 16.  Actually, I had left "Verify" separate, but he combined it with "Compile", so it works pretty much exactly the way you want.

You could grab the latest code from github and compile.

A release candidate is supposedly going to be published in the next few days.  Using the release candidate and reporting (with detailed info) any bugs is an excellent way to contribute to Arduino without digging into the actual code.  Typically very few people bother to really test the release candidates.  Often they're only announced on the developer mail list, so relatively few people even know they exist.  If you have a little time to spend testing next week, you really can pretty easily make a real contribution.

Arduino 1.0.1 is due within about 1 month.
372  Development / Suggestions for the Arduino Project / Re: Bug with Serial.print in the new arduino 1.0 on: March 07, 2012, 02:20:52 am
Do you have access to a Teensy board?  Teensyduino has the original String implementation I tried to contribute to Arduino.

I just ran this and it seems to work fine.  It continues printing forever **, but the string stops getting longer after 162 because available memory has run out.

** ok, forever is still running after a few minutes... but Teensy sends at full USB speed, not 9600 baud.  After only the time I've written this message, it's hit 16 bit numerical overflow and is now printing negative numbers on the beginning of each line!  Oh, now it's rolled back over to positive...
373  Using Arduino / Networking, Protocols, and Devices / Re: AltSoftSerial Library on: February 27, 2012, 06:48:36 pm
It is absolutely impossible from software to make any pin other than 8 on Uno act as a 16 bit timer input capture.
Actually you could use any one of the analog pins as an input for the 16 bit timer. 

Wow, yes, you're right.  The AN1 pin can too.  I didn't notice that before.

The signal will become inverted, so the library would need to handle reverse polarity (on my to-do list), and of course code would need to enable the analog comparator and ADC mux.

Good eye on the hardware's seldom used features!
374  Using Arduino / Networking, Protocols, and Devices / Re: AltSoftSerial Library on: February 27, 2012, 12:10:25 pm
If "will try putting it backwards" means only swapping pins 8 and 9, then good.

If it means attempting plug the whole shield in some strange way (perhaps hanging off the edge of the Uno) which reverses 8 and 9, but also causes other pins to line of differently... well, don't do that!
375  Using Arduino / Networking, Protocols, and Devices / Re: AltSoftSerial Library on: February 27, 2012, 12:03:59 pm
Ouch. As you can see, the shield is meant to be inserted just one way and fits nicely together with the GPRS shield. Will try putting it backwards nevertheless, just to make sure.

You will probably damage the shield if you reverse ALL the pins.  Only pins 8 and 9 should be swapped.

It's unfortunate this shield was designed with the pins swapped.  AltSoftSerial did not exist 2 years ago when it was made.  I wrote AltSoftSerial only a few weeks ago.

Is it that some deep code hacking is needed to reverse the pins or is it impossible at all because of wiring reasons?

AltSoftSerial only works with the pins as documented.  On boards like Uno with only one 16 bit timer, there are absolutely no other options.

As explained above, it uses timer1's special features, and those hardware features are hard-wired to those specific pins.  It is absolutely impossible from software to make any pin other than 8 on Uno act as a 16 bit timer input capture.

AltSoftSerial will only work if you connect the signals as documented.  It provides a lot of benefit, but the limitation is only specific pins can be used.
Pages: 1 ... 23 24 [25] 26 27 ... 40