Show Posts
Pages: 1 [2] 3 4 ... 42
16  Products / Arduino Due / Re: Please point me at instructions for speeding up the Due beta compiler. on: August 24, 2014, 04:24:29 pm
You don't mean that?

Yes, you're right, I oversimplified in that quick comment.

Quote
  Files need recompiling when any file they depend on changes, or
the board selected changes, etc etc.

Yes, of course it does that, using the .d dependency files created by previous runs of the compiler.

I've published this patch for several years in Teensyduino and Arduino has published in since version 1.0.1.  It's worked very well all this time.

All the source is available, if you're concerned about the implementation.
17  Products / Arduino Due / Re: Please point me at instructions for speeding up the Due beta compiler. on: August 24, 2014, 04:47:49 am
Sadly, it seems the patch I contributed to Arduino years ago, to only recompile files that have actually changed, has somehow been lost in 1.5.7.  This has recently been reported as a bug, so hopefully it'll get fixed in 1.5.8 or 1.5.9?

https://github.com/arduino/Arduino/issues/2255

The known bug where a space isn't recognized in the pathname is my fault.  I mostly use Linux, and then I port to Mac, and I always do Windows last, because it's the most painful.  When I tested on Windows, I used "c:\arduino", mostly because that makes things simpler to copy files over from my Linux machine, so I didn't notice the bug with not properly handling spaces.

I fixed this some time ago in Teensyduino, but sadly my code has drifted pretty far from Arduino's version, and they're in deep maintainence mode on the 1.0.x branch now, so odds are slim my fix will ever get into the 1.0.x branch.  It's also a good question whether they'll ever release 1.0.6....

Due's slow upload speed is mostly caused by bugs in Atmel's bootloader.  The bootloader is permanently burned into the mask rom inside the chip, so it can be updated.  Atmel is unlikely to ever fix those bugs, due to the high cost of revising the silicon.  Their own FLIP programmer apparently uses the buggy bootloader to upload a faster one to RAM, which it then runs and uses to upload code quickly.  Of course, Atmel never published any of that code, so Arduino can't use it.  It seems unlikely anyone will ever go to the trouble of developing something like that for Arduino Due.

Edit: I have put a *lot* of work into optimizing upload speed on Teensy 3.1.  If you'd like to see how fast upload can be, give it a try.  I believe on most computers, where there's significant USB bandwidth available (eg, not all used up by webcams or USB hard drives), it's limited in speed only by the USB enumeration time to detect the reboot, and the actual flash write throughput on the chip.
18  Products / Arduino Due / Re: Arduino Due Audio Library and Performing Other Tasks During Playback on: August 12, 2014, 01:23:37 pm
I'm curious to hear how using those timers work out.  I hope you'll post updates here, whether it works or does not work out.

Because this forum is for Arduino products, I'm reluctant to talk more about other hardware.  If you'd like to chat about the other library, there's a link on that github page to another forum.
19  Products / Arduino Due / Re: Arduino Due Audio Library and Performing Other Tasks During Playback on: August 12, 2014, 07:03:53 am
This might be a bit off topic, but you may be interested in an alternate audio library I've been writing for Teensy.  It's still at a fairly early stage of development.  A major feature (which does work well) is playback in the background.  In fact, this new library lets you create many audio objects, interconnected in arbitrary ways, with automatic audio data flow between them, all updated in the background.  For example, you can create 3 wav file players, connect them to the inputs of a 4 channel mixer, and then connect the mixer to the DAC output, or an audio shield output, or both.

Unfortunately, this new library requires different hardware.  While the audio processing objects are relatively pure software, all the input & output objects are coded for the DMA hardware on Freescale's chip.  The library also makes heavy use of the Cortex-M4 special DSP accelerating instructions, which dramatically speed up some objects like the FFT, BiQuad filters, and waveform synthesis.

https://github.com/PaulStoffregen/Audio
20  Products / Arduino Due / Re: About Serial.print() function for DUE on: July 24, 2014, 06:53:38 am
You should use the native port, not the programming port, if you care about speed.
21  Products / Arduino Due / Re: Arduino Due only: Wrong initialisation of SPI SS pins causes failure on: July 24, 2014, 06:41:15 am
I was not able to reproduce the problem you've described.  I would have to conclude your hardware is faulty.

Your report of this problem is also lacking detail.  If you really expect anyone to help, perhaps you could document the problem using an oscilloscope screenshot, as I have just done.
22  Products / Arduino Due / Re: Arduino Due only: Wrong initialisation of SPI SS pins causes failure on: July 24, 2014, 06:35:22 am
I just tested with Arduino 1.5.7 and Arduino Due & Arduino Ethernet Shield, with my oscilloscope connected to pin 10.  I loaded File > Examples > Ethernet > WebClient and clicked upload.

Here is the pin 10 waveform as the board starts up.



I do not see 1.65 volts.  The voltage appears to be floating at approx 2.5 volts before the sketch begins.  While the program is running, it's usually 3.3V and goes to 0 volts while using the ethernet chip.

Here's a zoom in view during the time while the sketch is transferring data.

23  Products / Arduino Due / Re: Arduino Due only: Wrong initialisation of SPI SS pins causes failure on: July 23, 2014, 03:02:11 pm
Can you please post a small but complete, ready-to-run program which demonstrates the problem?
24  Using Arduino / Programming Questions / Re: The Software serial multple serial test example does not compile on: July 01, 2014, 06:59:05 pm
R_AVR_13_PCREL is a known bug in the avr-gcc linker.
25  Using Arduino / Programming Questions / Re: How to clear serial buffer? on: July 01, 2014, 06:57:49 pm
It might be worth noting that the WIN32 API used on Windows, and the POSIX API used on Macintosh and Linux, use the same functions to access data from ordinary files and serial devices.

In fact, all use the term "read".  On WIN32, the function is ReadFile(), and on Mac and Linux it's simply read().
26  Using Arduino / Programming Questions / Re: How to clear serial buffer? on: July 01, 2014, 07:11:54 am
Do you know of any good, inexpensive, preferably parallel (or serial if there are no parallel ones) LIFO chips?

I've never seen a dedicated LIFO chip.  They may exist, but if so, I'm not aware of any.

Of course, FIFO chips are still made.

http://www.cypress.com/fifos/

Quote
How scared should a novice solderer be about putting pins on a Teensy, whether 2.0 or 3.1?

For the pins on the outside edges, it's pretty much the same as soldering pins to any breakout board, for Arduino Mini or Nano.  Usually you'd put the pins into a breadboard or socket, so the ends are held at the correct spacing, while you solder to the circuit board.

A version of Teensy is sold with the pins already soldered, mainly for use with solderless breadboards.  If you don't have a soldering iron, building on a solderless breadboard with that version is definitely the way to go.

Quote
Especially the 3.1, I'd love some kind of combo breakout and ZIF that would contact all the pins!
Hey, we're not all hardware heads!

I'm reluctant to write much more specifically about Teensy here on Arduino's forum.  There's a forum for Teensy.  In fact, here's a recent thread about this.

http://forum.pjrc.com/threads/26071-Using-all-Teensy3-x-pins-with-a-socket

Let's talk about anything specific to Teensy, which isn't somehow related to Arduino's products, on the PJRC forum.
27  Using Arduino / Programming Questions / Re: How to clear serial buffer? on: July 01, 2014, 06:08:25 am
I also think of last-in first-out stacks when I see "push" and "pop".  Using those terms for non-stack buffers seems terribly confusing to me.
28  Using Arduino / Interfacing w/ Software on the Computer / Re: C++ serial communication too slow on: June 30, 2014, 01:44:00 pm
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365467%28v=vs.85%29.aspx
29  Using Arduino / Programming Questions / Re: How to clear serial buffer? on: June 30, 2014, 07:15:28 am
Quote
That's when you have the capability to push.
How do you supposed data gets into the serial buffer?

The Serial receive code is designed for only the main program to remove data from the buffer, and only the interrupt routine to add data to the buffer.  If you add code in the non-interrupt context which modifies the "head" index, which today is only written by the interrupt context, you'd disturb the careful design which avoids extra overhead of disabling interrupts while manipulating the buffer, and head and tail index.

Certainly it's possible to put data back into the input buffer, but not a simple addition.  As soon as you write to the head index from the main program, or to the tail index in interrupt context, the entire design needs to be carefully analyzed and/or guarded by interrupt disable.  In a best case scenario, such a seemingly simple feature would cost quite a bit of extra code/overhead.  In a worst case scenario, such a chance could easily introduce difficult-to-troubleshoot bugs to the serial code.
30  Using Arduino / Programming Questions / Re: Detecting available space in Serial transmit buffer on: June 30, 2014, 05:19:26 am
Not sure how the interrupt priority is related?

I must confess, I haven't analyzed all possible ways calling these functions while executing at different interrupt priorities might impact things.

Quote
If room() is called from non-interrupt context, any interrupt can interrupt it, right?

Yes, of course, any interrupt can interrupt it.

So far, this design is basically the same as all the rest of the hardware serial code, which assumes one of the index variables is only advanced by the main program and the other only advanced by interrupt context.

If there are cases where this needs to be improved, I'm certainly willing to improve the code.

Quote
However, in the teensy code, it seems there are some #ifs to allow head and tail to be uint16_t. In that case, AFAIU on AVR all reads and writes to them should be done with interrupts disabled to prevent the variable changing halfway through a read

Teensy uses two completely separate core libraries, one for AVR and one for ARM.

The AVR version only supports uint8_t for head and tail.

The ARM version uses uint8_t if the buffer size is under 256 bytes, or uint16_t if the buffer is larger.  On ARM, reading 8, 16 or 32 bits uses a single instruction.
Pages: 1 [2] 3 4 ... 42