Show Posts
Pages: 1 ... 3 4 [5] 6 7 ... 41
61  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);
62  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.
63  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?
64  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?
65  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.
66  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?
67  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: November 18, 2013, 06:39:32 am
Thanks Collin, for such an honest appraisal.

Within the next few months, I plan to work on a new CAN library for different hardware.  I had hoped to work towards compatibility with a well-defined official Arduino CAN API.  Seems such an API is still some distance in the future?

When talking about APIs for Arduino, it's usually good to refer to Arduino's style guide.

Bringing up new hardware AND designing an official API (implementing and testing on Due as well) might be more work that I can realistically take on?  Then again, I'll need to implement something for an API.  I really do care deeply about compatibility.  I know from experience that starting without an API plan usually results with an API deeply rooted in the hardware's specific details.  From what I can see, it looks like the Atmel guy did this, then you've been adding the higher level stuff?

My hope at this point, if you and others are willing, would be to discuss what the final, official Arduino CAN API might be, in a perfect universe where we all had plenty of time to actually work on the code?

I've been reviewing the existing CAN APIs.  So far, I've found 3 Arduino libraries: this one, Seeed's for their MCP2515-based shield, and ChipKit.  Seeed's API is fairly simple, just 8 public functions.  ChipKit's API is horribly complex.  The other API I've seen which seems the most Arduino-like, is mbed's:

I'd like to ask a couple specific API questions...

#1: How do you feel about using a special typedef or object for message data, versus primitive types?  Currently Due, Chipkit and mbed use these.  It does allow passing more info together, like the ID, length, timestamp.  But it also doubles the API, from just one object that communicates to 2 objects, with more stuff to learn to create and extract the data.

#2: Does providing mailboxes in the API add more benefit for users than the increase in complexity and overall size of the API they require?  For many Arduino users, the ease of learning is key.  An API with fewer than 10 functions, where all have simple names, seems approachable.  Seeed and mbed don't expose mailbox functionality.  Due and ChipKit have APIs with dozens of functions and long lists of constants.  So my question is whether mailbox access (rather than simple read & write) is really beneficial for some uses, and what those applications might be?
68  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: November 17, 2013, 10:04:20 am
This may be a silly question, but I'd like to ask about the status of this library's API....

Specifically, is this really the final "official" API for CAN on Arduino?

The reason I ask is because this API seems to disregard many of the common conventions and the overall style of Arduino APIs.  Most communication libraries inherit Stream or mimic Stream.  The init(), rx_avail(), get_rx_buff() and sendFrame() are pretty close, but they do require users to deal with structs, which is not commonly done with Arduino APIs.  The mailbox API seems to be particularly complex, and tied to Due's specific hardware, rather than attempting to provide a simplified abstraction that most Arduino users expect, with just a few easy-to-learn functions which cover most common needs.

Another common design feature of many Arduino APIs is the use of hardware neutral base classes.  Stream doesn't neatly fit CAN.  The closest is probably Udp.h, which Arduino 1.0 added to the core library.  The idea is you can write a UDP-based library or sketch using the base class functions, and then it will work when used with different libraries (eg, both Ethernet and Wifi).  Perhaps CAN needs its own abstract base class?  This sort of abstraction seems particularly valuable for developing the higher level protocols, like ODB-II.

So my question is whether this API is now forever fixed, or if it's still in significant development, and if it is, would a migration towards a more Arduino-like API be welcome?
69  Products / Arduino Due / Re: SoftwareSerial.h on: November 13, 2013, 04:06:56 am
About a year ago, I wrote a alternative library, called AltSoftSerial.

AltSoftSerial solves these problems with concurrent data streams by using a timer's input capture unit to receive the data, include of busy looping inside an interrupt, and the timer's output compare units to transmit, rather than busy looping with interrupts disabled.  It can even tolerate a significant amount of interrupt latency imposed by other libraries without losing timing accuracy.

However, it does use up one of the 16 bit timers, which are in short supply.  You can only use the specific pins that timer supports.

Oh, and it also only works on AVR.  But maybe someone could port it to Due?  Due's timers appear to have 2 signals that can be either capture or compare, so the necessary hardware is present, and the timers are 32 bits instead of 16, so the prescaler probably isn't even needed for the entire range of useful baud rates.
70  Using Arduino / Sensors / Re: Library for multiple flow meters/ hall sensors? on: November 11, 2013, 08:56:48 pm
I do not plan to substantially work on FreqMeasure within the next 2 years (and perhaps not ever again), other than minor tweaks to port it to other boards.  If you want the code to work differently, you're going to have to roll up your sleeves and do the work yourself.  Or maybe hire someone to do it?  The code is open source, afterall.

If you look at util/capture.h, you'll see the options for hardware.  Arduino Mega has 4 timers compatible with FreqMeasure.  However, two of them do not have their ICP pins routed to any of Mega's accessible pins.  You could in theory use those other timers if you modify your board to gain access to those extra pins.  You'll need to refer to Atmel's datasheet for the chip and Arduino's schematic and PCB layout documentation to discover where those pins are located.

In theory, 4 copies of FreqMeasure could run simultaneously.  I wrote the code to use only 1 timer, which you can change by editing util/capture.h.  Read the comments in that file for details.  To run more than one copy, you'll have to edit the name of the library class and the default instance, so the other copies won't conflict.  You might have to edit more stuff too.  The errors from the compiler will give you an indication if stuff is conflicting between the multiple copies of the library.  You'll need to resolve those problems, but if you post here with the specific code and error messages, perhaps you'll get some help?  I personally can not get very involved.

I know you said you wanted 6 sensors.  There are only 4 timers inside Arduino Mega that can work with FreqMeasure.  Nothing you do can change that reality of the hardware.  If you do put this work into modified copies of the FreqMeasure, do so with an awareness of this hardware limit.

Good luck.  If you do get it working, I hope you'll participate in the spirit of open source by publishing your code, even though that's not required by the very permissive MIT license FreqMeasure uses.
71  Products / Arduino Due / Re: Insufficient data rate on the serial port. How to use the native USB port DUE on: November 07, 2013, 05:03:36 am
72  Development / Suggestions for the Arduino Project / Re: Somebody may you design an ARDUINO ATMEGA 256 board for more advanced projects? on: November 03, 2013, 07:49:31 am
Are there ANY bluetooth, wifi or SD cards that run on 5 volts?

5 volt chips and 5 volt signals are rapidly becoming obsolete.  Only the low end of 8 bit microcontrollers (eg, AVR mega, but not AVR xmega) are 5 volts these days.  Everything else has already gone to 3.3 volts or less.
73  Development / Suggestions for the Arduino Project / Re: Arduino 1.5.x -serie is running ahead of 1.0.x on: November 03, 2013, 07:46:08 am
Version 1.5.X has important changes to the way different boards and libraries are handled, especially 3rd party libraries and boards.

1.5.0 introduced the new "platform.txt" and other chips.  1.5.2 released an early version of the library and boards scheme, and it was revised again in 1.5.3/1.5.4.

Recently these new features have been hotly debated, with considering input/concern/push-back from 3rd party develops (full disclosure, including me).  It's still being discussed even now on the developers list:!forum/developers

Only yesterday (Nov 2, 2013) Cristian published a new goals/requirements list for these new features.  Based on Cristian's message, it seems extremely likely this new scheme is likely to change again in 1.5.5 or 1.5.6.

I'm happy to say the new goals/requirements list has more emphasis on backwards and forwards compatibility between 1.0.X and 1.5.X.  Long term, I believe these changes will greatly benefit all Arduino users.

So while 1.5.X works very well (it's "stable" in that it doesn't crash or work improperly), many pretty important aspects of the design are still likely to change.  In terms of the APIs used by boards and libraries, things are still developing.  I believe the Arduino Team is actually making a pretty good balance between making the new stuff available versus providing a stable platform that works with a huge number of boards, libraries, and sketches found across the playground and thousands of websites.

Moderator edit: add url tag
74  Development / Other Software Development / Re: Library conflicts on: November 02, 2013, 02:55:40 am
This simplest solution is to just delete the TFT library.
75  Products / Arduino Due / Re: Arduino DUE serial communication speed on: November 01, 2013, 08:01:18 am
Another thing to consider is your communication protocol.  Using USB, you'll have a difficult but not impossible task to sustain a 200 Hz update rate if your approach requires sending data to the Beaglebone, doing computation, and then sending control data back to Due.

That sort of receive sensor data, do computation, send control message approach is ALWAYS SLOW.

USB host controllers allocate bandwidth on 1 ms frames.  Typically you'll see 1 ms latency with USB.  Since you're looking for a 5 ms cycle, maybe that's not too bad?  But when you throw non-realtime operating system scheduling (Linux) in the mix, things can get worse... much worse.

If you design your Linux application with 2 thread or processes, or 2 handlers within within 1 program (eg, using select, poll or async i/o), you can do much better.  But this requires more sophisticated design.  Usually you need to do something like have the sensors continuously measuring and transmitting, never waiting for the control messages, and likewise have the control side send messages on its own schedule, with the receiving code on the Arduino side regularly checking Serial.available(), but never waiting when Serial.available() returns zero.

Perhaps your control algorithm requires so much CPU time that it absolutely can't run on Due?  If that's true, then I suppose you have no choice?  But if you can optimize your code to run on Due, I've confident you'll achieve much faster response speed than a 2-board system that will suffer so much inefficiency from all the USB I/O.
Pages: 1 ... 3 4 [5] 6 7 ... 41