Show Posts
Pages: 1 ... 3 4 [5] 6 7 ... 42
61  Development / Other Software Development / Re: Rotary Encoder Library on: February 14, 2014, 06:22:57 pm
The other possibility is my AltSoftSerial library.

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.
62  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.
63  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.
64  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.
65  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.

66  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: December 26, 2013, 03:44:21 pm
I put in an order for the OSH Park Arduino Due CAN Test Board.
Does anyone have a parts list or link to a shopping cart (jamco, mouser, digikey) I can use for the can transceiver, resistor, caps, and DB9 header.

Yes, here you go.  I also updated the description at OSH Park.

    Qty   Digikey P/N       Description
    ---   -----------       -----------
     2    296-27991-1-ND    CAN transceiver
     2    445-7660-1-ND     Capacitor, 10uF, 805
     2    399-1170-1-ND     Capacitor, 0.1uF, 805
     2    609-4003-ND       DB9M connector
     2    CF14JT120RCT-ND   Resistor, 120 ohm
     2    3M9447-ND         Header, 2 pin
     2    3M9580-ND         Jumper

67  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: December 23, 2013, 06:04:30 pm
What bus analyzer do you use?  I've been considering getting one of these, but mainly because I have their USB analyzer that works quite well.

Truth is, I have pretty much zero experience with CAN bus.  But I do have 20+ years experience developing with microcontrollers and several years on Arduino libraries and code.

I could use a little advice about what to do on the CAN side of things.....
68  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: December 23, 2013, 12:02:32 pm
I am still planning to work on this.  Since mid-November, a number of things have happened.

PJRC released Teensy 3.1 on December 9.  Obviously my main interest is developing a library to support CAN on Teensy.  I do want to work towards a really good, hardware-neutral API, even if that means getting somewhat involved in redesigning Due's library.

So far, the only real "work" I've done on CAN is buying and building hardware.  I built up that little circuit board for Due, and a CAN interface board for Teensy 3.1, and I purchased a couple MCP2515-based modules and connected them to the other Teensy boards.  As you can see, I've been putting together the hardware side for working on a CAN library.....

69  Products / Arduino Due / Re: Printf in Arduino Due on: December 01, 2013, 08:20:36 am
I'm not upset.  You did ask pointedly about my reasoning, and I took a moment to explain.

I should also add that I might be willing to accept a pull request that adds this translation layer.  But if it imposes a lot of overhead, like taking block transfers and turning them into byte-at-a-time writes, it'll need to be disabled by default.

Then again, I could be really swayed by a pull request accompanied by some significant work to benchmark performance over a variety of print(), println() and printf() scenarios.
70  Products / Arduino Due / Re: Printf in Arduino Due on: November 30, 2013, 08:33:32 pm
I was just curious why the translation was thought to be important enough to put in that code
but now it is not in the new printf() for the Print class.

I'm pretty sure that was just a copy and paste from some other project.

That serial code is intended to process data 1 character at a time.  The original version (while developing the USB code) didn't use interrupts at all.  It doesn't matter if extra time is spent processing each character, since it's just going to busy loop on the UART, and it's never meant to be part of any real program anyway.

The print class code is meant to be in real applications.  Performance matters.  Processing data as a block is extremely beneficial when the output device is USB or Ethernet.  Taking a block of data and processing 1-byte-at-a-time involves a pretty big performance hit if individual bytes are sent to the USB Serial write() function.

There are lots of ways to deal with this, of course, involving more complexity.

So to directly answer your question Bill, my motivation is based on performance and simplicity, and also somewhat laziness (far too many other higher priority software priorities), and also somewhat laziness in that the _write(fd, buf, len) API maps neatly onto the print class write(buf, len).  smiley

Then again, if not translating LF to CR+LF turns out to be a problem for a substantial number of users, I'll certainly respond by elevating the priority from "not likely to ever get around to it" to something likely to happen.  Much like supporting printf() at all in the Print class, which has been on my low priority list for many months, I did get around to it, mainly because it's been requested more frequently.  With only a limited number of hours in each day and a TODO list longer than I'll ever complete, I have to prioritize somehow.  I mostly go with what the most people want, and adding yet another layer for LF translation (without a big performance penalty on USB) is no exception.
71  Products / Arduino Due / Re: Printf in Arduino Due on: November 30, 2013, 08:10:06 pm
In serial1.c, serial_print() and those other functions at the end are leftover debugging stuff.  They were mostly used while I was developing the USB stack.  I'm planning to remove them eventually.
72  Products / Arduino Due / Re: Printf in Arduino Due on: November 30, 2013, 07:18:19 pm
I might still add yet another layer to translate LF to CR & LF.  But on my (incredibly long) list of features to develop, this is a pretty low priority.

For now (Teensyduino 1.17), I'm going to leave it as-is without any translation.  If someone is using a terminal emulator that can't be configured to deal with only LF, they'll just have to use printf("\r\n"), or stick with the Arduino println() function.
73  Products / Arduino Due / Re: Printf in Arduino Due on: November 30, 2013, 01:56:47 pm
For now, I'm not really concerned that println() sends CR & LF, but printf("\n") sends on LF.

On Linux, the Arduino Serial Monitor seems to handle LF only pretty well.  I haven't tested what it does on Windows and Mac, but if those 2 systems don't treat LF only as a line break, perhaps the best solution is to update the IDE.
74  Products / Arduino Due / Re: Printf in Arduino Due on: November 30, 2013, 06:40:13 am
I recently added this on Teensy 3.0, which uses a similar ARM chip.  Here's the code (in Print.cpp), if anyone interested in trying on Arduino Due.

extern "C" {
int _write(int file, char *ptr, int len)
        ((class Print *)file)->write((uint8_t *)ptr, len);
        return 0;

int Print::printf(const char *format, ...)
        va_list ap;
        va_start(ap, format);
        return vdprintf((int)this, format, ap);

int Print::printf(const __FlashStringHelper *format, ...)
        va_list ap;
        va_start(ap, format);
        return vdprintf((int)this, (const char *)format, ap);
75  Products / Arduino Due / Re: Is the Arduino Due a good choice? on: November 29, 2013, 07:37:12 pm
I'm currently working on an Audio library for Teensy 3.0, for 16 bit, 44.1 kHz streams.  So far I've done input, output, mixing, waveform generation, but not much in the way of filters and sound modifying effects.  Planning to do some of that, but still haven't decided what to implement there.

Some of my code might be portable to Arduino Due, but I'm leveraging the Cortex-M4 DSP/SIMD instructions quite a bit.  They really speed up manipulating 16 bit audio.  Unfortunately, Due is a Cortex-M3, so it doesn't have those extra instructions.
Pages: 1 ... 3 4 [5] 6 7 ... 42