Show Posts
Pages: [1] 2 3 ... 42
1  Development / Suggestions for the Arduino Project / Re: Non blocking hardware serial on: September 22, 2014, 04:58:26 am
Arduino recently added Serial.availableForWrite(), which tells you how many bytes you can transmit without blocking.

I believe it's currently only implemented on AVR, and only in the very latest 1.5.x versions.
2  Products / Arduino Due / Re: Assembler translation from UNO to DUE on: September 22, 2014, 04:32:17 am
I2C is completely different from I2S & SSC.

I2S is a protocol for continuously streaming stereo audio.  Two clocks are used.  The data signal is unidirectional, so if data flows in both directions, 2 separate pins are needed to transmit and receive.  I2S is designed to stream data continuously, without any checking if the other side is present or receiving the data.

Many chips with I2S require another "master clock", typically at 256 times the sample rate clock.  Arduino Due appears to be incapable of generating this extra clock (but I could be wrong about that), so it's probably only possible to use Due with I2S chips that create their own clocks.  On Teensy 3.1, the audio library default is generating all 3 clocks, which has a nice benefit that the audio timing remains perfectly synchronous to the processor's clock.

I2C is a general purpose control protocol.  One clock is used.  The data signal is bidirectional.  Typically short messages are used, with lengthy silent times between them.  I2C has features to allow each chip to detect if the other is present and has properly received the message, because it's meant for infrequent control messages, rather than continuously streaming data.

Many audio chips have both I2S (for sending & receiving the audio) and I2C (for controlling parameters, like headphone amplifier volume).

SSC is the name of the on-chip peripheral on Arduino Due which is capable of I2S communication.  Atmel could have simply named it the "I2S peripheral", but since it's capable of a variety of similar formats, they probably wanted a more generic name to imply its wide range of capabilities.
3  Products / Arduino Due / Re: Assembler translation from UNO to DUE on: September 20, 2014, 10:12:58 am
This probably won't help at all for Due (which is Cortex-M3 instead of Cortex-M4), but I've been working for the last year on an audio library.  It supports the WM8731 with I2S.

This graphical design tool is the best way to get a feeling for my library's capabilities....
4  Products / Arduino Due / Re: Assembler translation from UNO to DUE on: September 20, 2014, 09:46:48 am
Looks like you're trying to fake I2S (audio) protocol with SPI.
5  Products / Arduino Due / Re: TLC5940 change frequency to 20kHz on: September 15, 2014, 11:25:26 am
I believe the TLC5940 PWM is always 1/4096th of the GSCLK input, and the maximum GSCLK speed is approx 31 MHz.

No amount of wishing a thing to be more than it actually is can make it so.
6  Products / Arduino Due / Re: Audio (yes, I know) on: September 15, 2014, 03:22:47 am
Well, I think I need to stop following this thread now.  It's wasted enough of my time.

If you have written a better message, with code and details, I probably would have helped.  Maybe someone else will do so, if you write a good question with details.  But I'm done.  You've used up all the time and attention I'm willing to give.
7  Products / Arduino Due / Re: Audio (yes, I know) on: September 15, 2014, 03:16:58 am
Do you believe people on this forum have extrasensory powers like clairvoyance, to see the mistakes you've made without you having to provide any information about what you've done?
8  Products / Arduino Due / Re: Audio (yes, I know) on: September 15, 2014, 03:15:24 am
I have no idea either.
9  Products / Arduino Due / Re: Audio (yes, I know) on: September 15, 2014, 03:11:02 am
You're probably doing something incorrectly.
10  Products / Arduino Due / Re: Best book for Due hardware information? on: September 11, 2014, 05:39:44 am
The board clearly wasn't designed as a DAC to take your CDs and produce audiophile grade analog output (if so, it would be a steal at 10x the price if it could deliver on that promise).

Have you seen the audio library and hardware I've been developing on Teensy?
11  Products / Arduino Due / Re: Audio (yes, I know) on: September 10, 2014, 03:23:45 pm
I'm trying to build a one way ethernet radio, but I can't get the code to work at all...

For the last year, I've been working on an audio library for Teensy 3.1.  It has a lot of features, but recording and streaming still need a lot of work.  It's not so easy.

I've been helping many of the early users of my library.  When they communicate effectively, usually that process leads to me improving the library, and they get great working projects.  But communication is the key, and sadly, it's really lacking in this thread.  I just don't think I can do much more to help you, staurtm34, even if you were using the Teensy hardware.  On Due, there's far less in the way of well maintained libraries.

12  Products / Arduino Due / Re: Audio (yes, I know) on: September 09, 2014, 05:59:36 pm
What software can receive the packets and play them?
13  Products / Arduino Due / Re: Audio (yes, I know) on: September 07, 2014, 03:51:39 pm
I'm curious what you're trying to do here?  I a moment, I'll point out a few problems with the latest code, which should help you.

In return, I hope you'll be willing to spend a few moments explaining this application.  I really do want to know.  For the last several months I've been developing an audio library for Teensy.  Recording is one of the areas where I've done very little work, so even if you had the right hardware, my library as-is probably won't help.  Really, I'm hoping you'll help me, not with specific code, but with some explanation of what you're trying to really accomplish (eg, if all this code could somehow magically work).  By better understanding the application, maybe I can plan future audio library development?

Anyway, back to this code.  I see 5 possible issues....

First, it looks like you might have a buffer overflow.  Two loops use "while (inccnt<8001) {", with an increment at the end.  The first iteration of the loop will have inccnt equal to zero, which accesses the first location in the array, since arrays are zero-based.  The last iteration will have inccnt = 8000, which accesses 1 beyond the end, since it is only 8000 long and zero-based.  The last location is accessed when inccnt = 7999.

Second, your UDP send code use Udp.print(), which is probably not what you want.  For unsigned numbers, it will print ascii characters.  You almost certain should use Udp.write(), to copy the data directly to the UDP packet without turning it into printable ascii characters.

Third, your code appears to use "inccntr" in the second loop without first setting it back to zero.  The condition "while (inccntr<8001)" will NEVER occur, because the variable was left greater than 8001 from the previous loop which collected the audio samples.  As a result, your code will only call the Udp.beginPacket() and Udp.endPacket() functions, transmitting an empty packet.  The audio data will never leave the Arduino.

Fourth, UDP packets have a maximum length.  There are several different limits, all of them well under 8000 bytes, so you can't possibly send all the bytes as a single packet.

Based on that info, 500 looks like a good number to use.  You'll need 16 packets to send all 8000 bytes.

A fifth possible issue, which isn't technically a bug in your code, but rather a limitation in the Arduino Ethernet library, it terrible inefficiency for sending 1 byte at a time.  You should really use Udp.write(buffer, 500) to send 500 bytes all with a single write.  Perhaps something like this:

      inccntr = 0;
      while (inccntr<8000) {
        Udp.beginPacket(broad, remPort);
        Udp.write(audBuffer + inccntr, 500);
        inccntr = inccntr + 500;

There, I've identified 5 issues with this code which are probably preventing you from getting any results.  There may be more problems, but those are the 5 I can see from just reading your code quickly (eg, not actually running it here on an Arduino Due board with Ethernet Shield and microphone circuit).  Hopefully this will help you.

I really would appreciate if you would return this favor by taking a few moments to explain what your project is really about.  What are you trying to ultimately accomplish?  This information isn't for the purpose of debugging your code.  I'm asking you to take a moment to help me, so I can understand your application.

I am working on an audio library (for Teensy 3.1, not targeting Arduino Due).  Eventually, I want to add awesome recording capability to my library, so these types of projects will be very easy.  But first, I want to understand your project, so I can use that understanding as I work on my library.  I've made a significant effort to help you, and I hope you will be willing to return the favor by explaining your application.

14  Products / Arduino Due / Re: DmxSimple on: September 07, 2014, 03:03:54 pm
I have already an Arduino Uno, I can send DMX, now I will see to receive DMX. Is there another library?

On that page for the Teensy port for DmxSerial is a link to this forum thread, where Ward wrote DMX receive code.  Again, it's only for Teensy 3.X, but maybe you can use it to at least get started?  At the very least, it shows DMX receive is possible on ARM.
15  Products / Arduino Due / Re: DmxSimple on: September 07, 2014, 02:57:58 pm
DmxSimple doesn't work for the Due and it's possibly too much work to port it to the ARM hardware platform.

I ported DmxSimple to Teensy 3.1, so it certainly can be ported to ARM with some work.

Maybe my version will give someone a head start for porting to Due?
Pages: [1] 2 3 ... 42