Can you make the arduino do non miro controler things?

[donotdespisethesnake]

5nm is the width of about 50 atoms abreast.  They are nearing/entering a domain where quantum mechanics starts to dominate.  I am eager to see in 2020, if and how they begin to deal with that.

I know what you are getting at, but transistors fundamentally depend on quantum effects to operate, so the domination has already occurred

Quantum tunneling effects place a limit on the lowest practical feature size, I guess that is what you are thinking of.

[donotdespisethesnake]

Since it reads C could you make it do something like process an image (compress a .jpg to lower quality or anything that a computer would do when you program it in C)? Not necessarily to output the image in any usable way but just make it perform calculations or do something other then look at inputs and turn on outputs.

Of course, you could even run a power station* with an Arduino.

*conditions apply

[Ian.M]

You could even compile Arduino sketches on an Arduino - though it might take the rest of your lifetime just to open the IDE!

[james_s]

I suppose you could get around the memory limitations by using a serial interface to external RAM and mass storage. It might be kind of fun to see how far the concept could be pushed, maybe boot MS DOS in an x86 emulator? You might not live long enough to see it come up, then again the original PCs were not all that much more powerful than the AVR on an Arduino.

[retrolefty]

A main point is that the 8-bit AVR used in arduino does not 'read' C code. Your PC does all the compiling (search cross compiler). If not for your PC working with an Arduino would not really be practical in anyway.

[rstofer]

I suppose you could get around the memory limitations by using a serial interface to external RAM and mass storage. It might be kind of fun to see how far the concept could be pushed, maybe boot MS DOS in an x86 emulator? You might not live long enough to see it come up, then again the original PCs were not all that much more powerful than the AVR on an Arduino.

The original 8080 ran at 2 MHz clock and about 4 clocks per instructions (IIRC) so about 500k instructions per second.  Compare this to nearly 20M instructions per second on the AVR.  I suppose it would be possible to get some kind of AVR to run CP/M and do it a LOT faster than my Altair 8800.  I would probably have to forego the 8" floppies and go straight to SD cards. 

Even the Z80 only ran at 6 MHz or about 1.5M instructions per second and it was considered smokin' at the time.  Arcade games used lots of Z80 chips!

So, wimpy as they are, AVRs are pretty impressive!

[james_s]

It's hard to compare clock cycles and instructions per second between different architectures. Especially when you're dealing with a microcontroller that has no exposed data and address buses. Yeah the Z80 and the 6502 were both very common in arcade games, Atari used a lot of 6502's. The games typically had custom graphics and sound hardware though, hardwired predecessors to the graphics accelerator.

[timb]

It's hard to compare clock cycles and instructions per second between different architectures. Especially when you're dealing with a microcontroller that has no exposed data and address buses. Yeah the Z80 and the 6502 were both very common in arcade games, Atari used a lot of 6502's. The games typically had custom graphics and sound hardware though, hardwired predecessors to the graphics accelerator.

It's also important to keep in mind that the same code can take different amounts of instructions, depending on the CPU architecture you're compiling for. Let's take this simple piece of code:

Code: [Select]

int square(int num) {
    return num * num;
}

Now, let's look at the ASM that outputs for different architectures (using the same version of GCC):

AVR GCC 4.5.3

Code: [Select]

__SREG__ = 0x3f
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__CCP__ = 0x34
__tmp_reg__ = 0
__zero_reg__ = 1
square(int):
        push r29
        push r28
        rcall .
        in r28,__SP_L__
        in r29,__SP_H__
        std Y+2,r25
        std Y+1,r24
        ldd r24,Y+1
        ldd r25,Y+2
        ldd r18,Y+1
        ldd r19,Y+2
        mov r22,r18
        mov r23,r19
        rcall __mulhi3
        pop __tmp_reg__
        pop __tmp_reg__
        pop r28
        pop r29
        ret

MSP430 GCC 4.5.3

Code: [Select]

square(int):
        push    r10
        push    r4
        mov     r1, r4
        add     #4, r4
        sub     #2, r1
        mov     r15, -6(r4)
        mov     -6(r4), r10
        mov     -6(r4), r12
        call    #__mulhi3
        mov     r14, r15
        add     #2, r1
        pop     r4
        pop     r10
        ret

ARM GCC 4.5.3

Code: [Select]

square(int):
        push    {r7}
        sub     sp, sp, #12
        add     r7, sp, #0
        str     r0, [r7, #4]
        ldr     r3, [r7, #4]
        ldr     r2, [r7, #4]
        mul     r3, r2, r3
        mov     r0, r3
        add     r7, r7, #12
        mov     sp, r7
        pop     {r7}
        bx      lr

x86-64 GCC 4.5.3

Code: [Select]

square(int):
        push    rbp
        mov     rbp, rsp
        mov     DWORD PTR [rbp-4], edi
        mov     eax, DWORD PTR [rbp-4]
        imul    eax, DWORD PTR [rbp-4]
        leave
        ret

Also keep in mind that each instructions could take anywhere from one to hundreds of clock cycles to execute, it all depends on the instruction in question, the architecture, your code, the compiler used, the current day of the week, humidity and alignment of the planets! Comparing one architecture to another is difficult; it's apples to weird space apples, really.

That said, it *is* useful to checkout the sort of assembly your code is producing and compare it among compiler versions and architectures. I use Compiler Explorer to do that and it's awesome.

[westfw]

You also have to be careful about the Optimization settings of your compiler; sometimes they make a bigger difference than other times.  For example, if I run "square" through avr-gcc with the -O3 setting, I get:

Code: [Select]

00000000 <square>:
   0:    88 9f           mul    r24, r24
   2:    90 01           movw    r18, r0
   4:    89 9f           mul    r24, r25
   6:    30 0d           add    r19, r0
   8:    98 9f           mul    r25, r24
   a:    30 0d           add    r19, r0
   c:    11 24           eor    r1, r1
   e:    c9 01           movw    r24, r18
  10:    08 95           ret(That's 4.3.3, rather than 4.5.3, but I get approximately the same improvement with 4.9.x.)
(Also note that "int" on an AVR is 16bits, while "int" on the ARM and x86 is 32bits...)

[Rick Law]

On second thought, I removed the reply I just made to avoid hi-jacking the thread and tangent into other areas.