Where should GPS classes reside?

[SlashDevin]

I am preparing to submit some GPS classes. They including a base class and one derived class, although other derived classes may be contributed in the future.

IOStream/Driver seems likely, although those classes seem much more generic than an NMEA sentence parser. Perhaps IOStream/Driver/GPS?

I just remembered... the ublox Neo-6M also has SPI, USB and i2C interfaces. Maybe there should be a Cosa/GPS subdirectory?

Cheers, Devin

[jeditekunum]

I'm seeing issues with my current code (not on GitHub) that is interrupt driven that I suspect your implementation has as well. In your post http://forum.arduino.cc/index.php?topic=150299.msg1955227#msg1955227 you said

         // Do something with the fix() data member, quickly, or the interrupt routine
         //    will start replacing data as more characters are received...
        // Copy it to a local_fix if you need more time.

The problem is the lack of atomic updates. Not only between multiple variables but I suspect within a single variable as well. This is the kind of insidious problem that is rarely seen but...

The solution is likely the use of synchronized but I haven't used it so would need to study the appropriate usage.

[mikaelpatel]

I am working on library support in Cosa. There is a need for additional directory structure for contributions but also refactoring some of the core to make it a bit more light weight.

Sofar the command line has been updated to allow library build. The issue right now is that I would like to have another level of directories to give even more structure. The Cosa core uses a Java inspired structure with inheritance hierarchy. This is fine for simple inheritance but breaks with multiple inheritance or when classifical is more important such as INET, Wireless, etc.

I am considering a function structure for the library directory. This would be high level such as Sensor, Actuator, Communication, etc.

Comments, suggestions, etc, are welcome.

BW: The Arduino IDE preprocessor forces library header files to have the extension .h which also gives a problem for Cosa which uses .hh (as GNU Emacs likes this :).

Cheers!

[SlashDevin]

@jediunix, I copied your comment into a New Issue over on my CosaGPS. I'll answer it over there.

@mikaelpatel, I'll stand by until you've got something set up. I had noticed the .HH problem, but I thought I should follow your convention. I'll change when the library issue settles down.

Regarding directory structure, I have used a matrix architecture in the past. The first row is an application layer, then successive rows go from higher-level abstractions down to OS/HW interfaces. The columns were major function categories: Comm, Graphics, UI, DB, System (e.g., security), and Core abstractions.

The directory structure for this matrix started with one directory for each of the the columns, plus one generic APP directory. This first level directory was very abstract, then had subdirectories for derived types and higher-layer abstractions. Ascending in the matrix columns was descending in the directories. The idea was that a cell in the matrix could only know about the cell below, but there was the occasional sideways reference. Peeking up was forbidden.

This also let clients make their own subdirectory somewhere below without cluttering the upper directories.

I don't know if condensing decades of software system evolution into three paragraphs is a good thing to do, but there ya' go. :laughing:

Thanks, Devin

[mikaelpatel]

@SlashDevin Sorry for the delay on this. I was leaning towards exactly the structure you are suggesting. The Cosa core has moved slowly from SPI/Driver/Device.hh towards INTERFACE/Driver/Device.hh. Especially in the cases where there is a high level interface and low level access interface with SPI/TWI/OWI etc.

I have been playing with the library structure (Cosa/libraries) and used the DHT11/22 class as an example. First problem was that the Arduino IDE build seems only to accept a single level (I would like something like Cosa/libraries/Sensor/DHT/DHT.hh), second the .h vs .hh issue, and third the Arduino-Makefile default rules need adjusting for the extra level.

Please feed free to suggest a directory structure for the GPS library. It could be Cosa/libraries/GPS/PROJECT/DEVICE.hh??

Cheers!

[mikaelpatel]

Please see commit https://github.com/mikaelpatel/Cosa/commit/92054887c21e71f2b2237f7c06aefbd1c24120a0.

NB: The library structure (i.e. header files with extension .hh) only build with the command line tool.

[SlashDevin]

Ok, I'll take a look...

[SlashDevin]

A few questions:

1) Is this intended to be like the "Playground" where anybody can submit anything (i.e., "contrib"), or will you moderate in some way, like identifying overlaps, duplicate implementations or quality/reuse issues?

On one hand, contribs can be a source of candidates for promotion into the "core". On the other hand, incompatibilites and poor Cosa usage can proliferate.

I am hoping for the latter, because (1) github can already act as a Cosa-related playground (perhaps through tags), and (2) a primary attraction of Cosa is its clean, compact, efficient, and consistent OO design. This may be a "strategic marketing" question, in that you need to consider your target "demographic".

2) Can I hold you personally responsible for the Arduino IDE's failure to properly "make" a project and to handle libraries?

I'm really searching for a scapegoat here, because years have gone by without addressing this most basic capability for an IDE. -_- Ok, I'm just kidding. I'm sure that you, like many others, are frustrated by this.

The reason I ask is because the new structure requires building only with the command line: Library usage is incompatible with the IDE.

On one hand, software professionals drawn to Cosa can also "make" their way out of a paper bag. No big deal. I have not switched from the IDE, purely out of laziness. (I claim the best reusers are truly lazy! :) )

OTOH, the success of Arduino is due, in large part, to the vast numbers of contribs that make it easy for non-professionals to reuse bits and bobs to quickly solve their own unique problems in a simple IDE.

Again, the answer may depend on your strategy: Do you want the typical IDE user to be able to use Library components? Do you have any insight into the official IDE future?

The reason I ask is because the directory structure I suggest for my components would be different if they would be treated as contributed vs. canonical components.

[mikaelpatel]

Sorry for the delay. I will try to answer your questions:

1) Is this intended to be like the "Playground" where anybody can submit anything (i.e., "contrib"), or will you moderate in some way, like identifying overlaps, duplicate implementations or quality/reuse issues?

I would like to have a few levels. The simplest is adding a list of links to REVIEWED libraries that have been published on the Cosa README or documentation. The authors would have to handle all ripple effects when the Cosa core changes and they will need to define a Cosa version that the contribution works for. I would also need to add tags. Something I have avoided for a long time.

The second level would be libraries in the Cosa core itself. I was hoping for sub-modules and that these are automatically included into the download. Right now this is not supported by github. In any case this would be libraries that are "in sync" and regression tested with the development of Cosa (as far as possible). The authors may contribute by following the development of Cosa and regression test on new versions (tags).

The third level is libraries that are totally within the Cosa core and maintained with the rest of the core. This implies that I will have hardware setups for these if necessary.

Any level of contribution could contain overlap and trigger refactoring, or just simply be a better solution to something in the core. I see that as a separate issue from the library handling. It is not easy to get the whole library set to the same standards/quality. Being added to the list or sub-module is not something automatic.

I guess there will be contribution that will be refactored into the Cosa core. This will require the authors approval.

2) Can I hold you personally responsible for the Arduino IDE's failure to properly "make" a project and to handle libraries?

That a good one. I guess that is something you would like the Arduino Team to commit to :) :) :)

I hope to soon leave the Arduino IDE and replacing it with something else. I have stopped using th IDE all together now. That is the logical next step of migration from Arduino source code to Cosa. I was hoping for some development in Arduino that would motivate keeping this but they do not even want to fix the library handling functionality (e.g. header file extensions) and they work very very very slowly.

The Cosa command line build allows users to edit sketches in what-ever-editor and then build, upload, and connect a serial monitor. This gives a more flexible high level tool chain than what is in the Arduino IDE. They do not even get the dependencies right. And the Arduino preprocessing is a can of worms.

Cheers - And Happy New Year! Mikael

[jeditekunum]

Re the IDE...

IMO the Arduino IDE is pretty much useless. I would assume anyone using Cosa is at least somewhat more advanced and shouldn't have an issue with dropping the Arduino IDE.

I was also frustrated with the command line and the interaction with monitoring. I created a simple script called avr (https://dl.dropboxusercontent.com/u/103345528/Cosa/avr) that I have been using. I'm on OSX so it may or may not work on Linux. It automatically finds the right device and can build, upload, and monitor reliably via avr all. Perhaps some of those ideas could be applied to the cosa script.

On the IDE front, I am going to try embedXcode but am waiting for an installer bug to be fixed; the paid version, embedXcode+, claims to support Cosa. Perhaps the Eclipse plugin (https://github.com/jantje/arduino-eclipse-plugin) could be extended...

On Cosa in general... this is a great project! Might I suggest that a dedicated forum be created?

[dgschwend]

I just finished my first larger project using Cosa. I'm on OSX as well, and decided to give those embedXcode+ "build scripts" a go. It's basically just a bunch of advanced Makefiles plus basic templates for Xcode. There were some problems getting it to compile at first (Cosa board tags were wrong, serial port was hardcoded somewhere deep inside the Makefiles, some gcc flags didn't work). Once I got it up and running, it worked fine. I don't know if it would be easier and faster to directly add the cosa script as a build target though, it feels like embedXcode is already pretty bloated by now...

Unfortunately all the refactoring tools in Xcode don't work for C++ code. Otherwise I'm happy with this setup.

On Cosa in general: It's an awesome project. I've seldomly seen such high quality code, fantastic! And I would love to see a version for ARM based MCUs as you recently mentioned.

[SlashDevin]

@jediunix

shouldn't have an issue with dropping the Arduino IDE.

Ha, indeed I do not. It's purely a question of strategy. I think it's very similar to saying

Microsoft shouldn't have an issue with dropping MS-DOS.

Holy cow, what a pair of steaming piles.

@mikaelpatel

The Cosa command line build allows users to edit sketches in what-ever-editor and then build, upload, and connect a serial monitor anything.

Fixt. :)

Ok, there are three levels of libraries: REVIEWED, SYNCED, and ADOPTED. That leads me to ask:

Is that also the library life cycle? We could submit libraries for your consideration (SUBMITTED?), and they may or may not progress through those levels.

• If the answer is NO, is there an open-source collaboration workflow to consider? It may suggest a life cycle or how submissions should be structured.
• If the answer is YES, should submissions be structured like Cosa directories so they can be easily promoted through those levels? Aaaand I've gone full circle now... ;)

Happy New Year, everyone!

[mikaelpatel]

@SlashDevin

Yes, those are the basic library levels even if they would never become strict as this is an open-source project. The library and core directory structure is not locked down. It is fine to suggest changes. The current setup is more or less what came with adapting the Arduino core structure and keeping that is just to allow the Arduino IDE to be used. Right now there is a issue with the Arduino preprocessor for libraries as it does not understand other header extension than .h.

"God fortsättning", Mikael