Will we ever see higher spec chips in the Arduino

retrolefty:
...but if it's somehow shoehorned into a larger single IDE I think we could be in for a rough ride ahead. I can easily ignore the Due when released if I choose to just by not buying one, but I can't ignore the existing 8 bit IDE if its drastically changed to support the Due.

If we ignore its many bugs, the MPIDE used my ChipKit is a pretty good example of repurposing the Arduino IDE to work with a 32 bit boards and remain compatible with 8 bit Arduino boards.

Even on Arduino, there's lots of projects, shields and libraries that do fairly complex stuff, usually assisted by off-chip hardware. How is that so much different from the IDE supporting a more powerful chip which can do some of those things in its own software?

Even now, the Ethernet library is being extended with better support for protocols like DHCP and probably soon a library for HTTP.... on 8 bit Arduino.

I just don't understand these doom-and-gloom predictions. Maybe you could elaborate in more detail?

I just don't understand these doom-and-gloom predictions. Maybe you could elaborate in more detail?

Not a predictions, we have not had enough information provided to do that. Just a case of a feeling that the Due project could have unintended consequences of the existing adruino platform. This is not my first rodeo and one shouldn't criticize the soup before tasting it, but in a vacuum of information one can be concerned.

Lefty

more power I would actually look into using a Z80/Z180 processor.

I used to love Z80s, dream about the Z180s and built a large board with a 64180, banked memory and the lot. I often think of making a retro board but I wouldn't do it to get more power (unless you mean the 20Amps the board would draw :slight_smile:

but I can't ignore the existing 8 bit IDE if its drastically changed to support the Due.

Yes you can Lefty, just use one of the better options that currently exist. I downloaded AV Studio 6 the other day and that's fantastic (at first glance anyway, but of course no preloaded Arduino libs etc) but even a good editor and a make file is better that the IDE.

I can't imagine the current IDE can survive ARMageddon unless they fork the dev tools and keep 8-bits separate to 32-bits, that would be a mistake I think.

I guess we just have to wait to find out, hopefully it will be in this life :slight_smile:


Rob

Yes you can Lefty, just use one of the better options that currently exist.

Actually for me the arduino IDE is the best method for me to program my projects. As 'best' is hopelessly a subjective opinion that depends on ones objectives, experience, and preferences. As I'm an experienced hardware type that has learned just enough programming skills to get along, the arduino IDE is something I feel comfortable with and don't wish to learn or adapt to a more 'powerful' IDE. Choices are nice as long as I get to choose using the criterias most important to me.

Lefty

Yes I shouldn't knock the IDE too much, it's simple and clean and appropriate for it's target audience I think. While environments like those I mentioned are "better" that doesn't mean they are right for the typical Arduino user, TBH if they used Notepad++ and a makefile Arduino would not be the turn key app is currently is and I suspect it would not have gone very far :slight_smile:


Rob

The Arduino environment is a small, fairly clean and uncomplicated tool for prototyping with some of the Atmel chips. It doesn't require a whole lot of setup, (I remeber trying to use the old Microsoft tools under CPM on a Z80, there were a number of other tools that were developed that made it a lot easier and less frustrating...) and does one thing rather well. I don't think it would take a whole lot of modification to make it work with other processor families, some modification/changes to the boards file such as the identification of the compiler to use for the chip being programmed. On the other hand, if it were to make the Arduino IDE harder to use thenit would probably be a real negative. The only other microcontroller I have worked with was Basic Stamp and the Arduino Environment was a whole lot more usable, and a lot less limiting, in my opinion.

Perhaps the Due should have a DueDuino enviromnment that would be similar, but dedicated to the Due. A clean, dedicated environment in parallel with Arduinio.

All things considered, it's not clear to me what applications NEED a "higher spec chip"

I've become somewhat depressingly aware that there are a lot more Arduino-like clones that are "possible" and "interesting", but not really "necessary" or even "good for the Arduino community as a whole. Xmega; MSP430; PIC24; Coldfire; 8051(in several versions); half-a-dozen different ARMs (CM3, CM4, CM0, CM0+. Not counting the ones that already exist); Renesas...

I can't think of a compelling reason for most of them. The most common limitation that current Arduino users seem to run into is RAM. Which could be most compatibly addresses by adding some external RAM to a MEGA. Which is sort of boring.

I just asked this question here

As you can see there's been little response and so far not one single concrete idea. Maybe the thread in is the wrong section, or is it just that nobody needs such a beast?

So if we assume that the new Due should NOT run Unix, HDMI etc etc because there are plenty of boards that do this very well that means it should probably be a "Mega on steroids", but the question remains, "What will it do?".


Rob

"Which could be most compatibly addresses by adding some external RAM to a MEGA. " and likely solved in many cases by just moving up to a '1284, and picking up some more IO pins in the process.

Graynomad:
As you can see there's been little response and so far not one single concrete idea.

Well let me tell you why I like the Arduino. It might not be the fastest thing in the world, but remember the original IBM PC ran at 4.77 MHz. So at 16 MHz it's not too shabby,

You don't have to download DLLs onto it. You don't get viruses. You don't have an operating system so complex no-one can comprehend what it does. It boots in about a second, or less. It shuts down by yanking out the power cord. It's powerful enough to talk to SD cards for massive data storage. You can interface LEDs, motors, rotary encoders, LCDs, a huge amount of things. It's cheap. The Arduino IDE in particular makes it very easy to program. Properly configured, it can use a tiny amount of power when inactive.

You compile with a "real" language (C++). You can, if you wish, use fancy features like templates, the STL, classes, dynamic memory and so on. You can extend it with extra RAM, EEPROM, and port-expanders. You can use I2C, SPI, serial, 1-wire, and so on. You can connect USB and Ethernet. With a few extra chips you can have radio communications, or RS485.

Nick, I think you have expressed well one of the real advantages to both the success and popularity of the Arduino platform and that is the total lack of having to deal with a operating system when working down at the sketch level. Just me and the chip, and with a little help from the datasheet. I don't have to learn or remember stuff that doesn't have anything to do with what I'm working on.

So while of course the Arduino IDE is very dependent on a PC OS to operate in, once I'm working down at the sketch and hardware level of the arduino, there is a much simpler, approachable, and controllable universe at my control.

Yes I think that's why most of us like this sort of platform. I know when I have a problem with say a VB.NET program there are so many levels of complexity that I don't even know where to start some times. And even if you do narrow it down to a framework or system call what are you going to do about it? Raise a support ticket with M$ and wait 6 months?

That's not to say you don't have problems with embedded stuff but as Lefty put it so well it's "Just me and the chip, and with a little help from the datasheet."

Of course all that can still be true of an ARMduino, as long as the feature creep is kept in check (something I find very hard to do :))


Rob

as long as the feature creep is kept in check

Yes that is the trick. There is so much of "this is easy to do so let's do it" mentality. There is not enough of stepping back and thinking how useful is this and does it complicate matters.

Having said that I don't see why an ARM based arduino has to look very different at the C level than we have at the moment. Sure if you want to stray away from the basics it is a whole different ball game but it doesn't have to be.

Grumpy_Mike:

as long as the feature creep is kept in check

Yes that is the trick. There is so much of "this is easy to do so let's do it" mentality. There is not enough of stepping back and thinking how useful is this and does it complicate matters.

Having said that I don't see why an ARM based arduino has to look very different at the C level than we have at the moment. Sure if you want to stray away from the basics it is a whole different ball game but it doesn't have to be.

Well I haven't researched it but I get the impression that a typical ARM chip needs quite a bit of initialization code to configure it's I/O, internal buses, and other peripherals. Assuming that is true then that is another level of abstraction and or complexity that a user either has to accept the board designers default or learn. While the Atmel AVR chips do have a little of this (timer0 setup) it's rather simple to understand and or change. Maybe that's overstating something I really haven't seen, but I suspect the reason for the overDue's lateness is all software/firmware/support library/IDE issues rather then hardware problems.

Lefty

a typical ARM chip needs quite a bit of initialization code to configure it's I/O, internal buses, and other peripherals.

True, I don't know if it's more complicated or that there's just more of it. For example here's some startup code to set the SPI pins

	/* Configure SPI pins */
#ifdef CONF_BOARD_SPI
	gpio_configure_pin(SPI_MISO_GPIO, SPI_MISO_GPIO_FLAGS);
	gpio_configure_pin(SPI_MOSI_GPIO, SPI_MOSI_GPIO_FLAGS);
	gpio_configure_pin(SPI_SPCK_GPIO, SPI_SPCK_GPIO_FLAGS);

	#ifdef CONF_BOARD_SPI_NPCS0
		gpio_configure_pin(BOARD_SPI_NPCS0_GPIO, BOARD_SPI_NPCS0_GPIO_FLAGS);
	#endif

	#ifdef CONF_BOARD_SPI_NPCS1
		gpio_configure_pin(BOARD_SPI_NPCS1_GPIO, BOARD_SPI_NPCS1_GPIO_FLAGS);
	#endif

	#ifdef CONF_BOARD_SPI_NPCS2
		gpio_configure_pin(BOARD_SPI_NPCS2_GPIO, BOARD_SPI_NPCS2_GPIO_FLAGS);
	#endif

	#ifdef CONF_BOARD_SPI_NPCS3
		gpio_configure_pin(BOARD_SPI_NPCS3_GPIO, BOARD_SPI_NPCS3_GPIO_FLAGS);
	#endif
#endif

In a quick test program I setup there's about 150 lines of this in init.c and another 550 in sam3u_ek.h, that's a lot but it's all done automatically by environment and so can largely be ignored I guess.

Just how the IDE (I'm using AVR Studio 6) decided I wanted SPI instead of GPIO for those pins I haven't figured out yet although maybe that's what SPI_MISO_GPIO means, set to GPIO. Now that I think about it that's probably what's happening and that would make sense, set everything to GPIO until told otherwise.

EDIT: Thinks again, #ifdef CONF_BOARD_SPI probably means that in another file the SPI has been enabled, not GPIO.

But as you can see it's standard C, the constants are different but I guess the Arduino environment will hide a lot of that in the same way that most people don't currently have to know about SPDR, COM2A1, OCR1BH etc.

So presumably the Arduino IDE will hide all this as well and the average punter will just do the normal 2-3 pinMode()s in setup() and carry on.

the reason for the overDue's lateness is all software/firmware/support library/IDE issues rather then hardware problems.

I would say that's the case, the hardware looks pretty simple. Porting all the libraries would be a big job with many gotchas I think.

accept the board designers default or learn.

This might be an issue, for example I'm wondering if external RAM is required because as soon as you add one you lose about 30-odd GPIO pins. Does the designer add a chip and screw those that really need the IO or just make the addition of an XRAM board easy?


Rob

So presumably the Arduino IDE will hide all this as well and the average punter will just do the normal 2-3 pinMode()s in setup() and carry on.

Yes that is my point, the hardware abstraction can take place under the hood like it is done now and most users will be non the wiser. There is already the "removal" of the data direction register in the abstraction we have now. The choice of if pins get switched to alternative functions like SPI will be made when you initialise the SPI or use it for the first time.

Does the designer add a chip and screw those that really need the IO or just make the addition of an XRAM board easy?

No in exactly the same way that this is not done in the Mega at the moment. You can add extra memory as a shield if you want. There is no reason to go adding extra RAM to the base processor, it just adds expense that not everyone will want or need.

The alternative approach is taken by the Raspberry Pi, out of the 56 GPIO pins only 14 of them are brought out the rest are used for internal functions like the SD card, you never get to see those pins. That is why I think the Pi will be for software intensive applications and the Due for physical computing.

Grumpy_Mike:
Yes that is my point, the hardware abstraction can take place under the hood like it is done now and most users will be non the wiser.

Sadly, the Arduino world is filled with sketches and libraries that directly manipulate the timers and ports.

While pinMode, digitalWrite and digitalRead do provide a nice hardware abstraction, lots of authors are dissatisfied with their sluggish performance. Several libraries, like Capsense, Ping, OneWire and others legitimately need the performance and can't work well with the 50-some cycles taken by digitalWrite. But in many other cases I've seen, authors are simply familiar with directly manipulating the ports and do so, even if their code spends much of its time in delay().

Even with the Arduino functions are used, a very AVR trick is used to activate the pullup resistors. All ARM chips, and even AVR XMEGA, use a separate register to control the pullups, rather than repurposing the output register when the pin is using input mode. Arduino 1.0.1 will finally provide INPUT_PULLUP with pinMode(), but there is already a vast amount of code written which depends on the AVR register behavior.

When it comes to timers, Arduino provides nothing other than polling with millis() or micros(). A good portion of all Arduino libraries directly manipulate one or more hardware timer, with lots of AVR timer register assumptions built in. If you look at ChipKit and Maple, very few libraries are compatible. Usually it's timers.

Arduino has also been long missing a number of other important features. In their absence, authors have resorted to direct hardware access. For example, I recently worked on porting (only to Teensy with non-UART "Serial", not a non-AVR chip) a sketch that allowed a specific software package to control several stepper motors. It was based on a big polling loop that depending on non-blocking access to Serial and the motors. Of course, Arduino's Stepper library is a fully blocking API (only 1 stepper can move at a time). Until very recently, transmitting on Serial also blocked if more than 2 bytes were sent. So the author wrote his own stepper control code, using direct port manipulation, and wrote all the output to a buffer, with direct access to the UART registers to incrementally transmit the buffer contents only when the UART was ready for another byte. Had Arduino offered something like Serial.available() to know if writing would block, that sketch probably wouldn't have directly hit the UART and might be portable to a future ARM-based board. But like so many Arduino application, the gaps in Arduino's functionality required direct hardware access.

Eventually Arduino is going to need to provide a more complete API. It's so very unfortunate that the motivation to design the API with forward thinking towards future platforms hasn't been present all these years. So many very compelling sketches and libraries have been written over the last couple years. A great number that do anything "interesting" are unable to use only the Arduino functions without resorting to AVR-specific direct hardware manipulation.

Even today, lots of sketches work on Uno but not Mega. When/if Due is released, certainly simple LED blink examples will work, but it's going to be take a lot of work for many of the compelling libraries and sketches are ported.

Even today, lots of sketches work on Uno but not Mega.

Yes that is my point. You can't expect to see someone convert all the libraries ever been written, that is never going to happen. Look how many have not survived the move to IDE 1.0 and correction for that is simple enough.

All they need do is to write equivalent ones to the ones that ship, at the moment, with the basic IDE.

Grumpy_Mike:

Even today, lots of sketches work on Uno but not Mega.

Yes that is my point. You can't expect to see someone convert all the libraries ever been written, that is never going to happen. Look how many have not survived the move to IDE 1.0 and correction for that is simple enough.

All they need do is to write equivalent ones to the ones that ship, at the moment, with the basic IDE.

What is clear is that the 'Arduino world' has become much larger then what the Arduino development team and company can completely control for good or bad, that is the nature of popular open source projects. It's certainly understandable for newcomers to the arduino world to be confused why problems like outdated libraries even exists. But I consider that a feature rather then a bug for the arduino platform. :wink: