Caught up between a rock (Arduino) and a hard (ARM) place.

[rs20]

Can you give an example of where Arduino's predictably slow digitalWrite would be preferred?

Absolute predictability means that changing between the cases you mention won't change the timing of the program. It's nice when time-critical code doesn't suddenly stop working when making seemingly irrelevant changes. Arduino is all about hiding the complexities from the user, and it's moderately complex to understand that different call patterns might lead to different timings. So, Arduino's solution is to hide that complexity from the user. I don't agree with that approach, but it certainly aligns with Arduino's wool-over-the-eyes philosophy.

[westfw]

digitalWrite(pinVar,stateVar) in Wiring I expect avr-gcc would use a jumptable and compile to ~15 clock cycles.

Maybe you should check.  It looks to me like in the all non-constant case, Wiring ends up using essentially the same code that Arduino uses.
Also, I don't see any special cases for one "one argument is constant", so I think you'll see exactly the "two cycles or 50 cycles" behavior I'm worrying about.

I've never seen such bad code in any Arduino libraries anyway, so it's more of a moot point.

Really?  I would have thought the C++ libraries with arbitrary pin constructors would be full of calls with both values variable.  Here's one from one of the wiring examples:

Code: [Select]

byte rowPins[ROWS] = {2,3,4,5}; //connect to the row pinouts of the keypad
byte colPins[COLS] = {6,7,8,9}; //connect to the column pinouts of the keypad

Keypad keypad = Keypad( makeKeymap(keys), rowPins, colPins, ROWS, COLS );
(Not that speed matters much here.  slow _pinwrite() is plenty fast.  Which is the main reason that the Arduino lib hasn't changed.)

I don't know whether anyone has written a digitalWrite() that optimizes ALL the cases.  Teensy, perhaps (hard to tell; it's pretty ugly.)
Teensy3 too, but ... there's not as much optimization to do on an ARM.  Sigh.

(In any case, to bring things back to the topic we're supposed to be discussing...
looking into the details surrounding this sort of thing can be VERY educational!)

[CM800]

Thanks for all your help, some really interesting points have been made here.

I am going to buy the ATATMEL-ICE-BASIC right now.

In the long term I want to work my way up to buying and using this microprocessor here:
http://www.ti.com/lit/ds/symlink/am3357.pdf

For a product in the future I have in mind making use of those industrial protocols.

However that is a long way off I think. The Tech Doc for that MPU is just shy of 5000 Pages!

[TopLoser]

I think I've got a AM335x development kit somewhere.

[ralphd]

Can you give an example of where Arduino's predictably slow digitalWrite would be preferred?

Absolute predictability means that changing between the cases you mention won't change the timing of the program. It's nice when time-critical code doesn't suddenly stop working when making seemingly irrelevant changes. Arduino is all about hiding the complexities from the user, and it's moderately complex to understand that different call patterns might lead to different timings. So, Arduino's solution is to hide that complexity from the user. I don't agree with that approach, but it certainly aligns with Arduino's wool-over-the-eyes philosophy.

OK, I get the point now.  It never occurred to me that some Arduino users would be unaware that their code gets compiled to machine instructions, and the speed of execution is related to the number of instructions executed.

[ralphd]

Also, I don't see any special cases for one "one argument is constant", so I think you'll see exactly the "two cycles or 50 cycles" behavior I'm worrying about.

From what I recall of working with VirualWire, it works that way.  The output pin was a compile-time define, and the HIGH/LOW value was a runtime variable (user data).

I've never seen such bad code in any Arduino libraries anyway, so it's more of a moot point.

Really?  I would have thought the C++ libraries with arbitrary pin constructors would be full of calls with both values variable.  Here's one from one of the wiring examples:

Code: [Select]

byte rowPins[ROWS] = {2,3,4,5}; //connect to the row pinouts of the keypad
byte colPins[COLS] = {6,7,8,9}; //connect to the column pinouts of the keypad

Keypad keypad = Keypad( makeKeymap(keys), rowPins, colPins, ROWS, COLS );


Good point.  I forgot about old libs like that.  More recently I've been looking at code from talented programmers like Mike Patel who will use things like __builtin_constant_p() to ensure compile-time constants don't have runtime penalties.  As I've also pointed out in the past, turning on lto (-flto) can make up for a lot of that bad programming.

(In any case, to bring things back to the topic we're supposed to be discussing...
looking into the details surrounding this sort of thing can be VERY educational!)

So the way Wiring does it should be preferred.  :-) Programmer changes the way the code toggles a pin, notices timing difference, learns objdump to see what the code compiles to, and now has some useful knowledge...

[CM800]

I think I've got a AM335x development kit somewhere.

Really? Even though it will be a long way off from now, if the price is reasonable I would be happy to grab it!

[jnz]

Something I haven't seen brought up yet was vendor lock-in.  After more than a decade of being locked into Microchip and having to put up with bad decision after bad decision, no way I'll ever do that again. In ARM I can go to ST or Atmel or NXP or Freescale, etc. ST isn't going to make the part I need? Well, Atmel does and 95% of my code is logic and not peripheral access - so I can make that work.

Oh, I use Arduino and depsite (or because of) increased popularity they keep dumbing it down? They don't make the part I want? The series I'm using isn't retail/wholesale available? Their XYZ peripheral sucks? Too bad.

On top of that, I don't understand why anyone would still go 8bit when 32bit costs the same or less in a lot of cases.

[asgard20032]

8 and 16 bit are still relevant depending of the complexity and real time requirement. Most of the time, a 16 bit mcu will have less latency than a 32 bit arm to respond to real time, with 1 cycle interrupt latency, and 1 cycle interrupt return while a arm can have as up to 30 cycle to enter and another 30 cycle to leave ISR. Its all about pipeline and other architectural design. 16 bit = less complex, so smaller pipeline. Once the pipeline is going on, an ARM is unbeatable, but when there is a change in order of instruction execution (a while, for, switch, function call, or an ISR... all the pipeline has to stop and start again at another place, so you loose some precious cycle). Pic32 is even worse for cycle lost. But on the other side, all math stuff take less time on the 32 bit arm, with floating point and other DSP extension ( m3 & m4 & m7). So for hard real time, a pic24, dspic, msp430 will be better. If real time is important, but you are not at 20 cycle accuracy, most arm will do the job. Also, you have to consider zero wait state of the flash and ram and other. In the right hand, arm will beat most other common mcu. But if not used correctly, there will be lot of wasted cycle doing nothing...

[nctnico]

On top of that, I don't understand why anyone would still go 8bit when 32bit costs the same or less in a lot of cases.

Still I like the suggestion to stay with Arduino for a little bit longer and get rid of the Arduino layer and start using the peripherals directly one by one. Once you know how to use Atmel peripherals directly the switch to ARM won't be that hard because what is under the hood works by the same principles. I have given this thread some thought and it is easy to throw all kinds of options at the topic starter but I think the most important first step is to get more comfortable with microcontrollers in general and which place is better than to start with something you already got working and can modify in small steps?

[asgard20032]

Some hard step to get into arm world include getting a toolchain setup (or buy an IDE), crosswork is a popular cheap one that do all major arm, understanding that on almost all arm, nothing will work at power on until you setup periphiral clock... GPIO don't work? Setup GPIO clock... Next, how does interrupt work, trap work, reset vector... if you can get across all what i mentioned, then you can pick up almost any arm.

Most mcu = get to know how to configure clock, then how to configure each peripheral. Arm has the added toolchain/IDE complexity (Freescale and NXP has their free ide, Atmel has a free one but i hear lot of bad thing about it, TI also got one, but i wouldn't recommend TI for ARM, they are not really general purpose ARM and cost more... and their IDE is lock down to their XDS100 debugger except if you want to pay the price for it). Crosswork, 150$, IDE for all ARM on the market, or almost all. Work on Windows, mac and linux, and it look great. And the other complexity added by arm is that except if you know about whats going on with the clock, you could loose many hour of your life by not knowing that at power on, there is clock in none of the peripheral, not even the GPIO. If you get over those, arm is like all other mcu, but more standard and more popular these day.

[ralphd]

On top of that, I don't understand why anyone would still go 8bit when 32bit costs the same or less in a lot of cases.

337c will get you 10 ATtiny13a, or 169c will get you an ATmega328p Pro Mini board.  175c will get you a USBasp for programming.
The instruction set is a bit simpler than ARM, and as others have pointed out, programming the peripherals on ARM MCUs is a lot more complicated.  About 10 minutes of browsing the datasheet is all I need to get programming with a new 8-bit AVR.

The amount of existing code is the biggest benefit (for some this could be a drawback given how much crap code there is out there).  While I often write my own library code from scratch, having someone else's code to look at is a big help.  More than once I've come across documentation in a datasheet that is ambiguous.  Rather than having to write some test code to see how the part actually works, I can usually find existing code that shows the correct way to do it.

Lastly, at least for me, I like creating things that are easy for others to duplicate.  Most cities over 100,000 population seem to have electronics stores where you can find an arduino or pro mini board in stock.  If I made a project with a stm32f030f4p6, it would be a lot harder for people to duplicate.

[andersm]

Most of the time, a 16 bit mcu will have less latency than a 32 bit arm to respond to real time, with 1 cycle interrupt latency, and 1 cycle interrupt return while a arm can have as up to 30 cycle to enter and another 30 cycle to leave ISR.

Cortex-M3/M4/M7 have an interrupt latency of 12 cycles on entry and 10 on exit. If another interrupt is pending on exit, interrupt tail chaining shortens the latency to 6 cycles. CPUs with FPUs can add 17 cycles on entry and exit, depending on configuration. The Cortex M0/M0+ have a longer latency of 16 and 15 cycles, respectively.

The Cortex-M hardware interrupt prologue sets up nested interrupts, the runtime environment and vectors to an ISR that can be a normal C functions. Latency numbers for other CPUs are typically counted only until the first instruction of the ISR is executed, but omits mandatory overhead like pushing registers and branching to the correct handler.

Once the pipeline is going on, an ARM is unbeatable, but when there is a change in order of instruction execution (a while, for, switch, function call, or an ISR... all the pipeline has to stop and start again at another place, so you loose some precious cycle).

Cortex-M0/M3/M4 have a 3-stage pipeline, and the Cortex-M0+ a 2-stage pipeline. It is rare to get actual pipeline stalls, but on faster chips there may be flash wait states. (The Cortex-M7 has a 6-stage pipeline, but that's a different class of beast.)

So for hard real time, a pic24, dspic, msp430 will be better. If real time is important, but you are not at 20 cycle accuracy, most arm will do the job.

The Cortex-M can actually be configured to be fully deterministic. Whether the latencies are low enough is of course a separate issue.

[ralphd]

Most of the time, a 16 bit mcu will have less latency than a 32 bit arm to respond to real time, with 1 cycle interrupt latency, and 1 cycle interrupt return while a arm can have as up to 30 cycle to enter and another 30 cycle to leave ISR.

Cortex-M3/M4/M7 have an interrupt latency of 12 cycles on entry and 10 on exit. If another interrupt is pending on exit, interrupt tail chaining shortens the latency to 6 cycles. CPUs with FPUs can add 17 cycles on entry and exit, depending on configuration. The Cortex M0/M0+ have a longer latency of 16 and 15 cycles, respectively.

The Cortex-M hardware interrupt prologue sets up nested interrupts, the runtime environment and vectors to an ISR that can be a normal C functions. Latency numbers for other CPUs are typically counted only until the first instruction of the ISR is executed, but omits mandatory overhead like pushing registers and branching to the correct handler.

8-bit AVRs have a 4-cycle interrupt latency.  A basic software pulse generator using a timer interrupt has no need to save/restore registers, and could be done with two instructions:

Code: [Select]

sbi PINREG, PIN;
reti;


[Frost]

In ARM I can go to ST or Atmel or NXP or Freescale, etc. ST isn't going to make the part I need?

But only if you go the CMSIS way.
If you decide to use a vendor SDK then you will be locked again.

I came from the AVR world and try to dive into the ARM land now.
There was the same question for me like the thread starter,
how to begin.
So I orderd the FRDM-K64F as a cheap evolution board to start
my ARM journey.
The nexed question was, how to start and program this thing,
on the freescale page they offer you two paths to start,
with a local IDE or to go the mbed way.
I decided not to use the mbed web environment, because my
main goal is not to get a project up and running as fast as possible,
I would like to understand the CPU and how the ARM world works,
not at the lowest possible level but low enough to get a feeling
and understanding how the things work behind the scenes
and this was the reason for me to decide against the mbed way.

Instead I looked for something, that will help me to get a better
understandig how the things work and I ended up with a book
"The defenitive guide to ARM Cortex-M3 and Cortex-M4"
from Joseph Yiu and I would say, it's a must read for every person
who wants to start working with the ARM Cortex-M processors.
So you will be able to start with simple bare metal programs
and code and raise the complexity step by step with your learning
curve and after you get more and more familiar with the basics
of the cpu.

[andersm]

A basic software pulse generator using a timer interrupt has no need to save/restore registers, and could be done with two instructions

You can always invent special cases. Once you go beyond the trivial (maybe the pin should be cleared once in a while too?) the differences start going away. And for this special case, it would be better handled in hardware, with no interrupts.

[nctnico]

8 and 16 bit are still relevant depending of the complexity and real time requirement. Most of the time, a 16 bit mcu will have less latency than a 32 bit arm to respond to real time, with 1 cycle interrupt latency, and 1 cycle interrupt return while a arm can have as up to 30 cycle to enter and another 30 cycle to leave ISR.

You forget that a typical 8 or 16 bit CPU will have to push the registers onto the stack using software where the Cortex Mx CPU does this in hardware. So that 1 cycle on an 8 bit or 16 bit CPU quickly expands to 10 cycles or more and then there is 10MHz versus 50MHz (or more). Either way the ARM will be much faster. Even the older ARM7TDMI controllers have a single instruction which stores multiple registers onto the stack.

[technix]

...glad that at least someone woke up and wrote "I feel Arduino has just kinda messed it up, making it too simple to the point I feel lazy not understanding or doing anything beyond simple Arduino 'stuff'."

'd be nice if more people would come to the same conclusion.

Thumbs up for your decision, keep the good work man!

+1, well put. I was trying to say the same thing, but couldn't put it into words.

I feel the same albeit in a different direction: Arduino's driver model is not exactly plugin friendly and it will take a lot of work to integrate a new piece into the library system. And the IDE is crappy (since my daily driver is Xcode.)

[obiwanjacobi]

I had sort of the same problem - I was also not happy with what Arduino hid from you. So I did this.

Download the Atmel Studio, get yourself a JTAGICE3 (or preferably, a cheap clone), and start programming your Arduino that way using the 2x3 header on the Arduino itself. At that point, you're not "doing Arduino" per se, you're programming an ATMega328P.

It's a bit of a learning curve to get down to the MCU level (and reading the datasheet) but its been fun and rewarding.[2c]

[nctnico]

IMHO part of the fun of using microcontrollers is trying to find new sick & twisted ways to use the peripherals for a certain purpose they where not intended for.

[CM800]

Wow,

I just programmed a nano to flash an LED through Atmel Studio using my Atmel ICE.... was a heck of a lot easier then I expected .. else I would have done it sooner.... now to do something more useful... haha.

Does anyone on here have Steam or Skype who would be willing to chat with me about AVR stuff? Give me some pointers or quick help if I have a problem?

[Chris C]

Congratulations!  Getting past the initial intimidation is quite an accomplishment.  I'm PIC-only, else I'd take you up on that chat offer.

[ez24]

OP 

What do you think of this

http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,719,1471&Prod=LABVIEW-PCK

the hardware and software

[CM800]

Looks interesting, but I imagine the same with Arduino, you will find yourself having fun at the start, but when you begin pushing limits you will cry in frustration like myself and want to move over to a proper set up... that being said, It looks like a fun thing to play with potentially.

[TheWinterSnow]

I know I am probably late here on the topic, but reading through I wanted to add something. 

I program my Arduino Mega2560 with the USB connection but program it in C using standard IDE's (in my case Eclipse), so I don't have to worry about needing a programmer.  Yes the chip still has the 8kB bootloader but it saves me from spending the money on a programmer.  You could always use the Arduino IDE to use your Arduino board as a programmer to program another AVR device. 

My board is stock yet I can program it in C in a standard C IDE with the standard C library yet I can turn around and program it with the Arduino IDE if I ever felt the need to do so (eww!).

I personally refuse to use the Arduino IDE and libraries, give me the old C language and register controls.  I was against the Arduino libraries and IDE when I only had experience with the 8051 platform and Arduino was just beginning to get into popularity circa 2009-2010.

By writing your code in C or C++, and calling on the header libraries of that specific piece of hardware, in order to learn a new piece of hardware like the ARM system, you only need to study up on the API of the library that is intended for that piece of hardware.  In the case with ARM, not all of them use the same header libraries so you have to be careful there.  But in the end to me, its much easier and you learn more by programming for a specific target device, plus you save execution time by not using bloated entry level libraries.