Show Posts
Pages: 1 2 [3] 4 5 ... 40
31  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.

32  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

33  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.....
34  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.....

35  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.
36  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.
37  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.
38  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.
39  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.
40  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);
41  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.
42  Products / Arduino Due / Re: Is the Arduino Due a good choice? on: November 29, 2013, 06:15:46 am
What effects are you looking to implement?
43  Products / Arduino Due / Re: Bridge USB Native port to Serial2 on: November 20, 2013, 08:39:54 am
I have used Native port before with baudrates at 40Mbit/s with no problems.
What do you mean by USB reception? Is it using the programming port?

Data can flow both ways on the native port (and any of the serial ports).  The speed is not the same in both directions.  SerialUSB.write() is much faster than

What do you mean Serial2 is polled with a byte buffer?

If you use Serial2.print("Hello World") on Arduino Uno, Leonardo, Mega, etc, all 11 bytes are quickly written to a buffer.  Your program gets to keep running.  The serial2 interrupt then moves the data from the buffer to the serial line while your program can to do other stuff.

On Due, only 2 bytes of transmit buffering are used.  Serial.print() will not return until 9 bits have actually been transmitted.  Your program gets to run again when those last 2 bytes are still buffered.

Actually, in my design the TTL device will send data continuosly and the PC will send some short frames of three bytes, for configuration in asynchronous mode (after a user request).

Do you know where I can find a script doing something similar to this?
Is it possible a dma mode?

I can't get more involved in your project (and really, you initially didn't even give the detail of how much data you were planning in each direction).

Maybe these details will help you plan your code?  If not, I just can't spend more time.

Good luck.  I hope it works out well.  Maybe you'll post a followup after you build this?
44  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: November 20, 2013, 08:25:09 am
I made a quick PCB layout for the schematic in message #33.  Here the shared design, if anyone's interested.
45  Products / Arduino Due / Re: Bridge USB Native port to Serial2 on: November 19, 2013, 01:56:28 pm
I'll be curious to hear when speed you actually achieve?

My guess is it will fall short of 20 Mbit/sec.  Due's native port can transmit fast, I believe in the range of 40 to 50 Mbit/sec (about 10% of the theoretical bandwidth of 480 Mbit/sec USB).  But USB reception is slower, approx 1 Mbit/sec last time I measured.  I'm not sure what baud rates are supported for Serial2.  If do know transmit on Serial2 is polled with only the UART's 2 byte buffer, so you'll probably need to work around that somehow for the USB->Serial2 direction.

Good luck.  I hope you'll follow up with details on how it works?
Pages: 1 2 [3] 4 5 ... 40