Show Posts
Pages: 1 ... 3 4 [5] 6 7 ... 41
61  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.

http://arduino.cc/en/Reference/APIStyleGuide

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:

http://mbed.org/handbook/CAN#api

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?
62  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?
63  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.
64  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.
65  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
SerialUSB.print(yourData);
66  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.
67  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:

https://groups.google.com/a/arduino.cc/forum/?fromgroups#!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
68  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.
69  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.
70  Products / Arduino Due / Re: Arduino DUE serial communication speed on: November 01, 2013, 07:45:18 am
The speed is not the same in both directions.

I recently tested with 64 bit Linux, measuring several megabytes/sec in the Due-to-PC direction, and about 128 kbytes/sec in the PC-to-Due direction.  If you're sending from Due to your PC, it's about 10% of the theoretical USB 480 Mbit/sec speed (with protocol overhead), which I believe is the fastest Arduino compatible board on the market today.

Sending in the opposite direction isn't nearly as fast.

Here's a page I published with the benchmark results for PC-to-board testing.  The complete code is available, so you can run the benchmark yourself.  There's even a pre-compiled Windows utility, since building the PC-side code on Windows isn't as easy as Linux and Mac.

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

An important point is the speed can depend heavily on how you do things on the PC side, especially regarding transfer sizes.  You might think a 64 bit, many-GHz, multi-core CPU with gigabytes of high bandwidth RAM could not possibly be the limiting factor, but sadly the design of the PC side software can have a pretty dramatic impact on the speed.

71  Development / Suggestions for the Arduino Project / Re: Comments on Arduino 1.5 Specifications on: October 24, 2013, 03:44:33 pm
I really wish I would have put more thought into this when I first saw it several months ago.

The more I think about it now, the more concerned I feel it may create artificial barriers to humans collaborating.
72  Development / Suggestions for the Arduino Project / Re: Comments on Arduino 1.5 Specifications on: October 24, 2013, 03:08:40 pm
Bill, precise fine-grain compatibility specs would be excellent on a technical level, but would they also work well on a human level?

A scenario that concerns me looks something like this:

1: User A writes code to interface some sensor to Arduino Uno.
2: Forum users B, C, & D request the code, so he packages it into a library and uses a library.properties for Uno.  User A posts the code to a forum topic.
3: Leonardo users can't use the library, even though it would work, only because library.properties is too narrowly specific.
4: User C with a Leonardo adds the specs for Leonardo, posts an updated copy later on the same forum topic.
5: User B has an Arduino Yun, which could run the library, except user C only owns a Leonardo board, and didn't add/test support for Yun.
6: Several months later, Arduino Tre is released.  The library could run on Tre, but can't, only because the spec is again too narrow.
7: Later, someone wants to run it on Teensy 2.0.  I make a modification for Teensy 2.0 and publish a copy in my Teensyduino installer.
8: Yet more users want to run the library on Arduino Micro, Sparkfun's clones, or other derivitives.  Maybe they find the original Uno-only code, or the 2nd port, or perhaps my version.

I could go on and on with this list.....

However, my biggest concern is how code gets ported and adapted to different boards.  Real users simply try using a library on an unsupported board.  They get errors and ask for help on the forum.  Hopefully they post the actual error messages.  The "copy error" button in 1.5.X is intended to gently guide users to post actual errors.  Expert forum users see the error and suggest fixes.  Sometimes the original author updates their library.  Sometimes abandoned libraries get picked up by others (really, I believe the most beautiful thing about open source).

My point is the "just try it and see what happens" approach, messy and error-prone, is a pretty important mechanism by which the Arduino community collaborates.  Many people who know a lot more about human interaction than me have written about the importance of empowering people to try things and accept/learn from setbacks and failures.

Yes, some libraries (notably ones you've written) are done with an expert approach, where one developer pours tremendous effort into cross-platform compatibility and verification.  But most libraries aren't developed that way.

An air-tight system that prevents users from trying to compile code on specific boards the author or maintainer hasn't certified as compatible might spare users from compile errors, but it might also have a pretty negative overall impact on community collaboration and sharing.

73  Development / Suggestions for the Arduino Project / Re: Comments on Arduino 1.5 Specifications on: October 24, 2013, 12:18:59 pm
Thanks for taking the time to look at these issues.

Regarding the EEPROM.h, I'm afraid I oversimplified things a bit.  I'm also using inline functions that call C code from within the class definition.  I don't actually have any C++ code for EEPROM on Teensy 3.0, except in that header.  The rest is all C-only, for a number of other reasons I won't mention, for the sake of keeping this reply shorter.

I really do appreciate your offer to merge a pull request quickly.  But with 1.5.5 only days from release, I would really prefer to target 1.5.6 and allow more time to carefully consider these complex issues.  The last thing I want to do is hastily prepare a pull request and cause breakage in an Arduino release, even if it is labeled beta.

It's tempting to write more regarding the parts of this spec that give my the biggest cause for concern, "core-dependencies=" and "architecture=", but at this moment I'd really prefer to think about these a while longer before more comments.  Likewise for customizing the examples.

The library search order is one place where I'd like to make a proposal.

Quote
The current IDE should work, more or less, like this:

Let's call ARCH the architecture of currently selected board, and VENDOR its vendor name.
1) The IDE discards all 1.5 libraries that haven't ARCH in the platform= property.
2) From the remaining libraries it choose the first matching library by searching these folders, in order:
    a) SKETCHBOOK/libraries
    b) ARDUINOPATH/hardware/VENDOR/ARCH/libraries
    c) ARUDINOPATH/libraries

So putting a library inside ARDUINOPATH/hardware/VENDOR/ARCH/libraries works. Again, here there is another compromise to deal with: we can reorder the path priority for example b) c) a), but this won't let the user the possibility to override vendor-provided libraries.

I agree, a) b) c) is the best search order.

However, I would like to propose a smart strategy for the a) to b) transition.  If the user installs a library in their sketchbook, perhaps with "architecture=avr" or any other library.properties line that doesn't match the board they're selected, then b) and c) should be tried to find a better match.  Libraries found in b) should always match, and c) is the last location, so really the smart decisions are only truly needed at step a).
74  Development / Suggestions for the Arduino Project / Re: Comments on Arduino 1.5 Specifications on: October 24, 2013, 03:44:11 am
Cristian, if you're still reading, here are some questions:

All 22 libraries that ship in Arduino 1.5.4's libraries folder have "core-dependencies=arduino (>=1.5.0)".  What is my Teensyduino installer supposed to do with the core-dependencies field?  If "arduino (>=1.5.0)" means it will only work with a core named "arduino", do I need to rename my core from "teensy" to "arduino"?  Or do I modify the library.properties files to add the name of my core to the properties files?

Likewise, how am I supposed to install Teensy 3.0's non-avr architecture EEPROM library?  Suppose I name Teensy 3.0's architecture "kinetis".  It seems logical that I would add a "kinetis" directory inside libraries/EEPROM/arch and copy my architecture EEPROM.cpp there?  But what do I do about EEPROM.h?  It's currently in libraries/EEPROM/src, shared by all architectures.  My EEPROM library customizes that header, adding a constructor which I use to initialize the hardware (unlike AVR, the eeprom hardware needs to be initialized).  It looks like I'll need to overwrite the platform neutral header with my customized version.  Then, of course there's the library.properties file in EEPROM, which currently says the EEPROM library is only compatible with AVR architecture.  Will I need to modify EEPROM's library.properties, for both architectures and core-dependencies?

SoftwareSerial is another library I've ported to Teensy 3.0.  Fortunately, SoftwareSerial seems to have a header in libraries/SoftwareSerial/src that includes the architecture specific header, but it looks like I might need to patch library.properties, since both architectures and core-dependencies say it's incompatible with my hardware (even if I copy the code into a new directory to make it compatible).  Another complexity with SoftwareSerial is I'll want to patch the examples, which mention the supported pin numbers only for Arduino boards.  I'll want to add similar comments for my 3rd boards.  How am I supposed to do that?

I recall earlier you mentioned the intended path is to contact the library maintainer and get them to update their library.properties file and add the code.  Is that really what you intend for the 22 libraries that ship with Arduino?  Generally Arduino has maintained a policy of facilitating 3rd party hardware, but not shipping any code or file that directly support any non-Arduino boards.  Arduino's lengthy release cycle could also be, well, frustrating if you're the path to get 3rd party support into those library.properties files.

I did notice 1.5.4 has two old style copies of the Wire library, in hardware/arduino/avr/libraries/Wire and hardware/arduino/sam/libraries/Wire.  Maybe this the path?  If I have a library like EEPROM ported to another architecture, but it's already present with library.properties incompatible with my hardware, can I put a pre-1.5 format library in my platform/arch/libraries directory?  Will it override the same-named copy in the main libraries directory?  I was under the impression those directories were the pre-1.5.3 way which was intended to be replaced by library.properties.  Is that right?  If those are the official way for 3rd party boards to be compatible with the 22 "standard" libraries that ship with Arduino, it really ough to at least be mentioned in the library spec.

When I start supporting 1.5.X, I really do want to do it properly.  I honestly do not see what the proper way is to resolve these many issues, at least not without overwriting many library files.  Please let me know your thoughts?
75  Development / Suggestions for the Arduino Project / Re: Comments on Arduino 1.5 Specifications on: October 23, 2013, 08:19:22 pm
Paul,
What is your understanding of the "architectures=" field?

I honestly do not really know at this point.

Ultimately, my top priority is making everything "just work" on Teensy.  A strong secondary goal is enhancing the Arduino API, ideally in ways compatible with all official Arduino boards, like the advanced ADC API recently discussed on the developer mail list.

I also do want to utilize this multi-platform stuff, but that's a secondary goal.  If there's any sort of trade-off, making everything "just work" for customers takes precedence.  I already apply lots of patches to the IDE.  I want to do things in the simplest, most maintainable ways, but if patching results in more work for me but a better experience for my customers, I'll always optimize for end user experience.

Regardless of what the spec says, I believe what this really ends up meaning will largely depend on how many library authors actually end up using it.  I've never been good at predicting the future, so I'm going to resist the urge to make any more predictions.  I'm mostly in "wait and see" mode.
Pages: 1 ... 3 4 [5] 6 7 ... 41