Show Posts
Pages: 1 [2] 3 4 ... 40
16  Products / Arduino Due / Re: DUE PWM Frequency on: March 14, 2014, 04:38:40 pm
Is that really all you need?  Just a moment ago you threw in a H-bridge requirement, but without specifying what signals it needs.

Maybe you really need 6 waveforms, with some sort of non-overlapping dead time?
17  Products / Arduino Due / Re: DUE PWM Frequency on: March 14, 2014, 03:54:02 pm
Usually H-bridge driving is done with a pair of PWM signals that have a "dead time" between them, rather than the overlapping "phase correct" type of signal on 8 bit AVR chips.

But then, who knows what's really needed here.  There's very little accurate description and a lot of complaining, which is hardly a good approach to asking for free tech support / help on a forum!
18  Products / Arduino Due / Re: DUE PWM Frequency on: March 14, 2014, 02:47:45 pm
Are you now saying you need two PWM outputs, with some special timing relationship to each other?
19  Products / Arduino Due / Re: DUE PWM Frequency on: March 14, 2014, 02:30:46 pm
I should mention this works on Teensy 3.1, but hasn't been ported to Arduino Due (and may never work on Due, since Due has the Cortex-M3 chip and a lot of this code depends on the DSP extensions on Cortex-M4).  With that caveat in mind, here's the link.

https://github.com/PaulStoffregen/Audio

To get a sine wave, you'd write a sketch with an AudioSynthWaveform object, an AudioOutputPWM object, and one AudioConnection object to feed the sine wave from the synth to the pwm.
20  Products / Arduino Due / Re: DUE PWM Frequency on: March 14, 2014, 02:16:56 pm
The PWM output object on the (currently beta test) Teensy audio library supports this.
21  Products / Arduino Due / Re: DUE PWM Frequency on: March 14, 2014, 02:11:50 pm
What exactly is a "SINE PWM" wave?
22  Products / Arduino Due / Re: WS2801 and WS2811 based RGB LED Strips with Due? on: February 26, 2014, 08:22:26 am
Flickering problems might be timing related, or they might be voltage related.

If the strips are just barely able to recognize a 3.3V signal, flickering can happen when they draw enough current to cause small (or perhaps not-so-small) changes in their ground voltage, due to the resistance and inductance of the wires between the LEDs and power supply.

Some of the newest strips are having more trouble with 3.3V signals.  I have one "grumpy" strip here that won't recognize any 3.3V signal, even under perfect power conditions.  Most do work, but the margin for error in voltage is very small.

I'm making a little shield for Teensy 3.1 that has the 74HCT245 buffer, the 100 ohm resistors, and RJ-45 connectors.  It'll be available in 2-3 weeks.

You might need to do something similar for Due.  The 74HCT245 chip and resistors are cheap, so I'd suggest you do that before fiddling with the timing.  If you do get into timing stuff, you really need an oscilloscope or logic analyzer to view the waveforms.
23  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: February 22, 2014, 08:18:24 pm
Did you select Arduino Due in the Tools > Boards menu?

Those errors look suspiciously like the kind that occur when compiling Due-specific code for an AVR-only board.
24  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: February 19, 2014, 12:15:01 pm
I know this might be nitpicking and it's probably far too late to change now, but...

A common convention for names in all caps and with underscores (eg, "CAN_FRAME") is for constants from #define.
25  Development / Other Software Development / Re: Rotary Encoder Library on: February 14, 2014, 08:31:14 pm
The other other possibility (if my AltSoftSerial library doesn't solve the interrupt latency conflicts) would be using a different Arduino compatible board which has an available hardware serial port.  Since I'm the creator of Teensy (full disclosure), of course I'd recommend using a Teensy.  All of them have a free serial port.  Teensy 3.1 has 3 hardware serial ports, yet it's very affordable.

I believe Arduino Leonardo, Micro, Mega and Due also have extra serial ports.

But since you said you were already using an Uno clone, I'm guessing buying a more capable board is not an option?

I'm also curious, did you buy a cheap clone?  Not even a single penny goes to support the Arduino project, nor 3rd party developers, who write the libraries you're using, like Encoder and AltSoftSerial (I'm the author of both, and I can tell you both Encoder and AltSoftSerial development was funded through sales of Teensy boards).  The people who make those extremely cheap clones don't develop any software or libraries.  They usually don't answer any technical questions.  They usually don't even host a forum for questions, instead sending their customers to get support here, from those of us who are funded by sales of the name brand boards.

The extra cost of those boards pays for all this software and library development and resolving of technical issues.  I hope anyone reading this will keep that in mind when considering cheap no-name clones.
26  Development / Other Software Development / Re: Rotary Encoder Library on: February 14, 2014, 06:22:57 pm
The other possibility is my AltSoftSerial library.

http://www.pjrc.com/teensy/td_libs_AltSoftSerial.html

It does not disable interrupts for the entire byte, so it will interfere much less with Encoder.  However, AltSoftSerial depends on Timer1, so it's incompatible with any other libraries that need Timer1.
27  Development / Other Software Development / Re: Rotary Encoder Library on: February 14, 2014, 06:19:43 pm
SoftwareSerial disables interrupts while sending or receiving a byte.  For example, at 9600 baud, 8N1 format, a byte takes 1.04 ms.  During that time, the Encoder library can't recognize any changes on the encoder pins.

The pin interrupt hardware will save the fact that the pin changed, so as long as only 1 change happens during that time, it will be picked up later.  But 2 missed changes can cause incorrect counting.

With hardware serial, interrupts are disabled for only a few microseconds, instead of over 1000 us, so even fairly fast movement on encoders can be properly tracked while serial data flows.
28  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: February 13, 2014, 12:39:42 pm
can you prove list of arduino which has CAN bus support? (DUE comparable)

I believe Due is the only official Arduino board that has CAN bus.  Clones of Due, like Udoo and DigiX, should have CAN bus, assuming they've copied Due closely.

On 3rd party boards, ChipKit Max32 has dual CAN bus.  As far as I know, it's currently the only other board that attempts some form of Arduino compatibility and has a published CAN library.  I looked at their library some time ago, and my initial impression was the API was even more complex and convoluted that the older version of Due's CAN library!

Teensy 3.1 has a single CAN bus, but there is currently no CAN library for Teensy 3.1 (full disclosure: I'm the creator of Teensy).  Some Maple boards might have CAN bus, but as far as I know, no easy-to-use libraries are available and there may be interrupt conflicts with USB.  I've seen conversation about people using Keil's example code.
29  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: February 13, 2014, 09:47:06 am
can I use SN65HVD230 based can boards on arduino nano/pro micro?

No, not in any way that might actually work.  Arduino Nano and Sparkfun's Pro Micro do not have CAN bus support, so connecting only a transceiver chip would be pointless.
30  Products / Arduino Due / Re: some performance related questions on: February 07, 2014, 02:59:38 pm
You'll very likely achieve lower performance by placing your code into the RAM, because all of the SAM3's RAM is located above address 0x20000000.

The Cortex-M3 CPU has 2 buses.  The code bus is used for all memory access from 0x00000000 to 0x1FFFFFFF, which is the flash memory and boot ROM on this chip.  The system bus is used for 0x20000000 to 0xDFFFFFFF, which is the RAM and peripherals.  Higher addresses are generally reserved for stuff built into the CPU core, which doesn't involve data transfer on these 2 buses that link the CPU to the rest of the chip.

When executing from flash, instructions like load, store, branch+link (ARM's version of a call instruction) and interrupt entry/exit leverages both buses.  While your load instruction is bringing data into the chip over the system bus, the code bus is bringing the next opcodes into the CPU prefetch buffer to keep the pipeline filled.  Likewise, during interrupt entry, the code bus begins fetching the opcodes of the ISR while the system bus is saving registers to the stack.

If you locate code in the RAM, you'll cause bus contention.  Any possible savings you might have hoped to achieve by using lower latency RAM will be destroyed by forcing the CPU to wait for access to the single system bus.  Two buses operating in parallel really are dramatically faster.  The flash memory is also pretty well optimized, with a wide path that provides a lot of bandwidth and a small cache memory between the flash and the CPU's prefetch buffer.

On the Freescale chips used on Teensy 3 (full disclosure: I'm the author of Teensyduino) a portion of the RAM is below the 0x20000000 boundary, so you can do this sort of optimization.  But it's a mixed blessing, since less of the RAM is accessible from the system bus that doesn't conflict with the code bus.  It's important (for performance) to always locate the stack on memory accessed by the system bus.  Atmel chose to locate all their RAM above 0x20000000 on these SAM3 parts.


Pages: 1 [2] 3 4 ... 40