Go Down

Topic: Will we ever see higher spec chips in the Arduino (Read 4512 times) previous topic - next topic

Grumpy_Mike

Quote
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.

retrolefty


Quote
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

Graynomad

#32
Apr 01, 2012, 01:21 am Last Edit: Apr 01, 2012, 01:29 am by Graynomad Reason: 1
Quote
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

Code: [Select]
/* 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.

Quote
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.

Quote
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
Rob Gray aka the GRAYnomad www.robgray.com

Grumpy_Mike

Quote
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.

Quote
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.

Paul Stoffregen

#34
Apr 01, 2012, 01:38 pm Last Edit: Apr 01, 2012, 01:53 pm by Paul Stoffregen Reason: 1

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.

Grumpy_Mike

Quote
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.

retrolefty


Quote
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.  ;)

Go Up