It is interesting how much know-how and energy do spend/invest people into retro-computing stuff (when talking 8-bitters) PS: PIC32MX250F128B costs the same as the atmega328p and less than the atmega1284p..

Wow! Thats something I only dream of ;-). There is a lot of design in Cosa to use PROGMEM when ever possible and cut down on SRAM usage. With 16K I could put in a real RTOS with processes ;-)

You can really speed up pin I/O using a template class. I just posted a library that does writes in two cycles or 0.125 usec on an Uno. That library is at the above location.

I looked at your library recently and found that it uses much the same techniques as in Cosa and Jeelab. The current Arduino/Wiring style can be improved a lot with regards to speed and abstraction. Using C++ is a way forward.

The more important issues are abstracting and structuring the code base so that drivers, libraries, etc, can be added in a methodological fashion. Also I see a need to abstract IO functionality so that devices can be extended, replaced, etc. The IOStream/Canvas and IOBuffer classes in Cosa help a lot with this.

It would be nice to have a device driver framework for Arduino that allows a component view of both hardware modules/shields and software. Cosa is a small step in this direction. 1-Wire, I2C, SPI, etc, needs an abstraction layer and protocol generation so that integration becomes as easy as build in Arduino today. The research done in the d-tools project is an excellent starting point but we need to look at platform support for communicating systems; e.g. application build onto multiple boards, processors, etc, communicating over wire or wireless.

Hardware wise Arduino is a great contribution to getting cheap hardware for schools, university, prototyping and hobby projects. Software wise we have a lot more to do. Much has been done but additional structuring and refactoring is needed for the next quantum leap. Arduino/Wiring is great for beginners but it has some obstacles when it comes to scaling to larger projects. And 32-bits processors are not the answer even if they remove some of the resource limitations (memory, etc).

I think that there is a fair number of professionals with many years of experience of software design and implementation out there/here using Arduino for fun which could and should contribute in this process.

It is interesting how much know-how and energy do spend/invest people into retro-computing stuff (when talking 8-bitters) PS: PIC32MX250F128B costs the same as the atmega328p and less than the atmega1284p..

A chip alone does not a board make. I think you underestimate the fun of making a '8 bitter' do what one can make them do. It's a hobby dude. We don't do it to try and impress the ladies.

The more important issues are abstracting and structuring the code base so that drivers, libraries, etc, can be added in a methodological fashion. Also I see a need to abstract IO functionality so that devices can be extended, replaced, etc. The IOStream/Canvas and IOBuffer classes in Cosa help a lot with this.

This won't happen as long as the Arduino company controls the IDE and you fit your stuff into that environment. The average user just won't use Cosa since what they get from Arduino is good enough for hobby use.

I was involved with BSD Unix at Berkeley. The goal of BSD was to replace AT&T Unix, not fit in. The open source Unix evolved into Linux and is the base for OS X and Android.

Open source Uinx happened because AT&T was impossible to deal with. The Arduino company provides a product hobbyists like or at least live with.

I have ported popular open source RTOSs to Arduino but don't see much interest.

I just accept Arduino and build little add-on libraries that may be useful to users.

I do think serious embedded systems need a preemptive priority scheduler. The research in the 1970s on scheduling with the Liu and Layland theorem on rate monotonic scheduling and Horn's algorithm (earliest deadline first) are key to modern tools and design.

This won't happen as long as the Arduino company controls the IDE and you fit your stuff into that environment. The average user just won't use Cosa since what they get from Arduino is good enough for hobby use.

I was involved with BSD Unix at Berkeley. The goal of BSD was to replace AT&T Unix, not fit in. The open source Unix evolved into Linux and is the base for OS X and Android.

Open source Uinx happened because AT&T was impossible to deal with. The Arduino company provides a product hobbyists like or at least live with.

I have ported popular open source RTOSs to Arduino but don't see much interest.

I just accept Arduino and build little add-on libraries that may be useful to users.

Supporting a movement like Arduino is not an easy task as the main focus is not programming and the majority of users (and founders) are not programmers. But all this risks graining to a halt when scale starts to play in. The lack of structure will need to be addressed sooner or later and the foundation needs to be production quality; rock solid.

Using a Due with current Ardunio software should be compared to, for instance, using a RaspberryPI. Due gives for the average user just more memory, speed and ports. Trying to integrate different libraries is near impossible as the problem was not so much the lack of memory as the lack of structure. I think that the Mega has already shown this problem.

Professionals don't really use the Arduino IDE. It is basically a toy. A nice toy - but still a toy. The thing is to work around it and replace it in increments. Show the alternatives - slowly. Obviously Cosa can be built without any of the Arduino IDE/library/etc. The only essential part is AVR tools with GCC etc. GNU emacs and make works just fine as an IDE replacement ;-)

I think it is important to show possible steps forward with regard to structuring and using the full power of the programming language C++ for small scale embedded systems. I intend to include a Forth-like virtual machine (working name Avanti) in Cosa. This would gives direct access to the Arduino hardware without a compiler when needed and the possibility to add Domain Specific Languages for teaching, rapid prototyping, etc. The concurrency.cc project is a good inspiration in this regard.

If you think OOP is too larger step for the Arduino community then RTOS is "from here to eternity" ;-)

Smacks of elitism, but I would assume you wouldn't mind if others do their serious projects on same.

Hum, I guess "serious projects" means industry/commercial prototyping and not "your serious hobby projects". We are a few that get to work with embedded systems and use a lot of alternative software and hardware. I hope that whatever the scope of the project we have a set of tools to choice from. And we do it for fun and learn something new in the process.

It is important that young talented arduino users will grow - therefore ie. such TLAs like RTOS, OOP etc. shall attract them.. Veterans, like me, love 8bitters, especially when more powerful than Block II AGC..

I spent most of my career as an architect for large embedded systems. I did some of the initial architecture for one of the LHC experiments that discovered the Higs Boson at CERN.

Systems like this are implemented with a certified reliable RTOS. LHC used LynxOS.

Quote

The LynxOS-178 RTOS is the first and only hard real-time DO-178B level A operating system to offer the interoperability benefits of POSIX® with support for the ARINC 653 APplication EXecutive (APEX).

This is professional level serious.

I have often used VxWorks, the system used in Mar Landers. Two of my former colleagues founded Wind River Systems and developed this RTOS. This is also a professional level serious RTOS.

I am now retired but do a little commercial development. I just don't find Arduino hardware/software reliable enough for this use. FreeRTOS and ChibiOS/RT fit this level of seriousness, they have support for commercial use.

I love playing with small programs on Arduino. I am a frustrated programmer want-to-be. Management forbid me from implementing any of my designs since a large programming staff was hired to do that. This is hobby fun level of seriousness and Arduino is great.

So the Arduino millisecond clock ticks every 1024 microseconds then does two ticks every 41-42 milliseconds to catchup. This is a hobby level system.

I spent most of my career as an architect for large embedded systems. I did some of the initial architecture for one of the LHC experiments that discovered the Higs Boson at CERN.

Systems like this are implemented with a certified reliable RTOS. LHC used LynxOS.

Quote

The LynxOS-178 RTOS is the first and only hard real-time DO-178B level A operating system to offer the interoperability benefits of POSIX® with support for the ARINC 653 APplication EXecutive (APEX).

This is professional level serious.

I have often used VxWorks, the system used in Mar Landers. Two of my former colleagues founded Wind River Systems and developed this RTOS. This is also a professional level serious RTOS.

I am now retired but do a little commercial development. I just don't find Arduino hardware/software reliable enough for this use. FreeRTOS and ChibiOS/RT fit this level of seriousness, they have support for commercial use.

I love playing with small programs on Arduino. I am a frustrated programmer want-to-be. Management forbid me from implementing any of my designs since a large programming staff was hired to do that. This is hobby fun level of seriousness and Arduino is great.

So the Arduino millisecond clock ticks every 1024 microseconds then does two ticks every 41-42 milliseconds to catchup. This is a hobby level system.

I have no real issues of the subject and content that you and others in this thread have posted, but rather the tone and impression of the specific comments I listed. The arduino platform was well designed and build for the users it was aimed at, non technical users. It's also a continuously changing and improving platform that is evolving as people contribute more and more to it. The vast popularity of the platform and the huge membership of this forum kind of validates that there exists such a viable user base.

And there are many members here that come from professional background in software and/or hardware that like to contribute knowledge, share library contributions (as you certainly have), and otherwise encourage the less experienced members.

It just rubbed me (and maybe only me) the wrong way to read:

Quote

I don't use Arduino boards or the IDE for serious projects.

Followed with a supporting:

Quote

Hear, hear!

I know your contributions to the arduino platform do not reflect a person with an elitism attitude towards arduino projects or members using the platform, so don't take my comments as personal criticism of you, but rather just criticism of the comments that were posted.

You may enhance your Cosa mcu collection with atmega32 (same pin layout as the 1284p, bootloader works, the core and variant of the mighty1284p works under 1.5.2.). The major diff is it has got only 4 PWM and single UART - maybe the UART setting needs a fix.

You may enhance your Cosa mcu collection with atmega32 (same pin layout as the 1284p, bootloader works, the core and variant of the mighty1284p works under 1.5.2.).

I will see if I get the time for this later this week. Dont like the idea of doing too many modifications I cant run through the tests. Thanks for the schematics. Will need to read up on the spec as well.Cheers.

I spent most of my career as an architect for large embedded systems. I did some of the initial architecture for one of the LHC experiments that discovered the Higs Boson at CERN.

Systems like this are implemented with a certified reliable RTOS. LHC used LynxOS.

Just to present a counter-argument, I spent most of my career as a developer at cisco Systems, which helped create The Internet As We Know It Today. A cisco router is a fairly large embedded system that uses a home-built OS that is not certified, not realtime, and not particularly (certainly not inherently) reliable. I remember way back when BBN announced that they had gotten their fancy multicore "butterfly" router to reliably switch packets within 1ms. At the time, cisco routers were switching most of the packets in about 12 us... (but we couldn't do ALL of them within 1ms.)

The other interesting part involved cisco's experiments (and products) that WERE/ARE based on real-time kernels. It turns out that effectively using a modern RT kernel is a pretty complex undertaking, and it's really easy to shoot yourself in the foot...