Arduino compiled code...size? space? efficient?

Thinking about switching camps…from PICs (PicBasicPro, assembly, etc) to the Arduino world, specifically the MEGA 2560 and the board sold here at Sparkfun, mainly because it has 4 serial ports.

I downloaded the IDE. Looks neat compared to what I’m used to. Relatively simple, compact-ish, and best of all, it’s all in one spot vs. having to jump back and forth between various windows to edit/compile/burn.

Was wondering about the compiled/assembled code as compared to what I’m used to, which is the PIC’s code.

Like I’ve said elsewhere, I’m used to the PIC18xxxx lines of MCU’s. I’ve been using PicBasicPro for about 10+ years now, PBP when I need simple, straight assembly if I need fast/tight/efficient code.

Is the compiled Arduino code ‘tight’ (for lack of a better phrase)?

I guess I’m really asking if it’s kinda like the old Visual Basic 4.0…a semi- tokenized, semi- interpreted ‘on-the-fly’, or if it’s actual machine code that can really haul the mail if it’s done right.

Could a person write code that would handle 4 simultaneous continuous 115,200 bps streams coming and go out of each serial port and still have cycles left over to process that data in various ways and still bit-bang a couple of SPI pins for an LCD output or EEPROM access? Or would that be just asking too much for the code/speed of the device…

JDG

BTW - I hate C. Always have. Don’t know why, I just do. Didn’t like old ANSI-C in high school back in the 80’s, don’t like it now…or do I?

Switching camps to the Arduino just might change my way of thinking… Ya know, I just pull myself into the 2000’s or something.

JDG

I can’t see an Arduino meeting your requirements. I’d use a Parallax Propeller for that sort of application.

skimask:
I guess I’m really asking if it’s kinda like the old Visual Basic 4.0…a semi- tokenized, semi- interpreted ‘on-the-fly’, or if it’s actual machine code that can really haul the mail if it’s done right.

It’s not interpreted, it’s compiled to machine code.

Stop reading here.

Ok, now that you’ve stopped reading I can mention that underneath the Arduino IDE gcc is used to compile the code written in the IDE–which might give you some clues about the language used. :slight_smile: Yes, it’s a “documented subset” of C/C++ and, yes, it requires worrying about memory at some point but the Arduino cores and library make a lot of the stuff you’ll deal with high-level.

I don’t know the details of your performance question but the chip runs at 16MHz and IIRC is one cycle per instruction. Also, the AVR chip used has hardware SPI.

–Philip;

Ok, good to know. This MCU/board just might be the ticket for me…even though I hate C.

16MIPS wound easily handle what I need. On the PIC’s, I was limited to the same performance, but trying to bit-bang 4 serial ports using an interrupt based solution, as well as handle other interrupts, and run the main loop. Didn’t work very well (if at all) at 115.2kbps with 1x bit sampling! Not too bad at 19.2kbps w/ 3x oversampling on the serial, but would still miss things here and there, and still didn’t have much time left over for the main loop.

Getting rid of the bit-banged serial and putting them in the hardware ports, would save a load of MIPS for those other things.

The Arduino you are looking at should work fine for what you are trying to do but have you ever considered upgrading from the PIC18 to any of the 16-bit PIC24F’s? They are 16-bit 16 MIPS parts and a number of the 64+ pin variants have 4 hardware UARTS in addition to 3 hardware SPI and I2C channels and loads of other peripherals.

-Bill

Ya, I’ve checked out the dsPIC30/dsPIC33/PIC24/PIC32MX, etc.

I think it all comes back to what I want to wrap my head around and moving from the '90’s to the current century :slight_smile:

dsPIC30/dsPIC33/PIC24 - kinda ‘vintage 2000’ types

PIC32MX - while it’s up to date, I’m having a tough time wrapping my head around the programming and what’s needed.

If I was going to go PIC32, it would be the biggest baddest PIC32 in the box…PIC32MX795F512L (at least I think that’s the biggest baddest one out there for now).

Arduino - multiple chips supported out of the box, and the newer chips are relatively “fresh”.

skimask:
Ya, I’ve checked out the dsPIC30/dsPIC33/PIC24/PIC32MX, etc.

I think it all comes back to what I want to wrap my head around and moving from the '90’s to the current century :slight_smile:

dsPIC30/dsPIC33/PIC24 - kinda ‘vintage 2000’ types

Arduino - multiple chips supported out of the box, and the newer chips are relatively “fresh”.

Just so you know, the ATmega2560 on that Arduino board was introduced in the 2005 time frame where a lot of the PIC24F line is from 2007 or later. Both series of parts are based off of architectures that date back to the '90s if not earlier.

-Bill

Also note that there’s a really easy PIC32MX development board that you can buy from SparkFun - the UBW32. There’s a really sweet USART library from Microchip that gives you 8 ‘soft’ USARTs in addition to the 2 hardware ones already on the chip. Plenty of power there for you, low cost development board to get started. Nothing more to buy (IDE and compiler is free, just like Arduino).

Anyway, the PIC32 parts are pretty darn fresh - there’s a new bunch of them coming out soon. And in Jan SparkFun will have UBW32s with the PIC32MX795 on it (with, I think, 4 hardware USARTS).

*Brian

UBW32 creator

EmbeddedMan:
…(with, I think, 4 hardware USARTS).

If it’s the 100-pin version, you get 6 UARTS, 4 SPI, 5 I2C, 2 CAN, 1 USB, and 1 10/100 Base-TX Mac!

Are you going to be breaking out the ethernet port and have a header for the instruction trace lines?

-Bill

skimask:
Could a person write code that would handle 4 simultaneous continuous 115,200 bps streams coming and go out of each serial port and still have cycles left over to process that data in various ways and still bit-bang a couple of SPI pins for an LCD output or EEPROM access? Or would that be just asking too much for the code/speed of the device…

JDG

Some microprocessors have hardware UARTs with a 16 byte FIFO. This makes the interrupt rate 1/16th what it would be for an interrupt per byte. At 115Kbps each byte is about 80 microseconds’ duration. A well done ISR on a fast AVR could run in 5-10 microseconds, I’d say. So it depends on what other processing is to be done.

As to SPI - there’s hardware SPI so why do a bit-bang? But you could if you want, as SPI clocking is determined by the master so you could bit-bang with stretched clocks, but why struggle with that when there’s hardware SPI?

On ARM7 microprocessors such as LPC21xx (cheap) or the LPC176x (mbed) the UARTs are 16 deep FIFOs and the CPU is quite fast. I use 115Kbps on these, not an issue. But these are running at 70MHz.

skimask:
I guess I’m really asking if it’s kinda like the old Visual Basic 4.0…

A great AVR based programming environment about the same as VB6 is zbasic.net (see product website and the great forum). That compiler "feels" like a PC with VB6. It can compile to tokens that are interpreted by a fast virtual machine on the AVR, or compile to native code for the ZBasic AVR. Has a task scheduler, message queues, and so on.

The language is terrific, and Don, the developer, responds with requests for help in 17 nanoseconds.

EmbeddedMan:
Also note that there’s a really easy PIC32MX development board that you can buy from SparkFun - the UBW32. There’s a really sweet USART library from Microchip that gives you 8 ‘soft’ USARTs in addition to the 2 hardware ones already on the chip. Plenty of power there for you, low cost development board to get started. Nothing more to buy (IDE and compiler is free, just like Arduino).

Anyway, the PIC32 parts are pretty darn fresh - there’s a new bunch of them coming out soon. And in Jan SparkFun will have UBW32s with the PIC32MX795 on it (with, I think, 4 hardware USARTS).

*Brian

UBW32 creator

Oh...you got me drooling here...('795 has up to 6 USARTS)

I kinda overlooked the UBW and StickOS mainly because they didn’t support the '795’s. But…if the StickOS is going to support the '795…well…that throws another wrench into the master plan here! I really didn’t feel like learning another completely new (to me) assembly environment ('cause again I hate C)…

I might end up going both directions…PIC32 and ATMega2560…

stevech:
As to SPI - there’s hardware SPI so why do a bit-bang? But you could if you want, as SPI clocking is determined by the master so you could bit-bang with stretched clocks, but why struggle with that when there’s hardware SPI?

In my particular project (totally for fun, as complicated as I can make it and keep it manageable), I'd end up using 5 total SPI ports in addition to 6 USART, so obviously, one SPI would be hardware, but the rest would have to be bit-bang types.

stevech:
A great AVR based programming environment about the same as VB6 is zbasic.net (see product website and the great forum). That compiler “feels” like a PC with VB6. It can compile to tokens that are interpreted by a fast virtual machine on the AVR, or compile to native code for the ZBasic AVR. Has a task scheduler, message queues, and so on.

The language is terrific, and Don, the developer, responds with requests for help in 17 nanoseconds.

Great explanation. That kinda sums up what I've been wondering and it makes perfect sense.

And 17 nanseconds? So, he ONLY runs at 58.8Mhz? :lol:

skimask:

stevech:
I’d end up using 5 total SPI ports in addition to 6 USART, so obviously, one SPI would be hardware, but the rest would have to be bit-bang types.

Just checking - it's common to have one SPI port connect to multiple devices. They're selected with an I/O bit (chip select). Usually, you need a second SPI port only if you must have two concurrent transfers - somewhat unusual. (I'm assuming that the microprocessor is the SPI master).

Yep, the MCU would be the master. In this project, on the SPI, I’ve got a TFT LCD, touch screen control, SD card logging, and a couple of F-RAMs. While I’m waiting for the SD card to write, I can dump to the LCD, grab the latest touch on the screen (if any), and dump any other logging data to the F-RAM for later dump to the SD card. Basically, trying to keep everything busy…