Porting from AVR to ARM
Porting from AVR to ARM
Hi Everyone,
I have been working on porting the libraries from AVR architecture to ARM.
I'm trying to follow along with the new Arduino Due, which uses ARM Cortex-M3 processors from Atmel.
The main reason I would like to move to ARM is because of the ability to communicate directly with Android devices by turning Reef Angel into a USB accessory.
Well, technically I had already done this on AVR and used MAX3421. I had several prototypes made in the past year, but never actually finalized the boards as there was always something I wanted to change.
Then, I've been keeping an eye on the progress of the Arduino Due and when Google announced ADK2012, which would be compatible with the Due boards, I decided that I should peek at what would be involved into porting the code.
Well, the Google ADK2012 isn't quite compatible as one would think.
I can say that it was not an easy sail, but I'm very happy to be at the point I got today.
Today, I was finally able to modify some of the core files and I was able to get my SAM3X8E, which is the chip that comes on the Due board, to talk to my android phone , just like I had with the combo Mega2560 (chip used on RA+) and MAX3421.
That was the main reason that would make or break the deal. Now that I can communicate with Android directly using the ARM processor, I can start porting our libraries to the new architecture.
One of the drawbacks of the SAM3X8E is that it does not have internal EEPROM, so I'll have to move all internal memory settings to external EEPROM or wait until the Arduino team comes up with a way to save into Flash memory instead.
All PROGMEM variables will also need to be modified too or wait on the Arduino team once again.
I'll keep updates coming as I move along and have any progress.
I have been working on porting the libraries from AVR architecture to ARM.
I'm trying to follow along with the new Arduino Due, which uses ARM Cortex-M3 processors from Atmel.
The main reason I would like to move to ARM is because of the ability to communicate directly with Android devices by turning Reef Angel into a USB accessory.
Well, technically I had already done this on AVR and used MAX3421. I had several prototypes made in the past year, but never actually finalized the boards as there was always something I wanted to change.
Then, I've been keeping an eye on the progress of the Arduino Due and when Google announced ADK2012, which would be compatible with the Due boards, I decided that I should peek at what would be involved into porting the code.
Well, the Google ADK2012 isn't quite compatible as one would think.
I can say that it was not an easy sail, but I'm very happy to be at the point I got today.
Today, I was finally able to modify some of the core files and I was able to get my SAM3X8E, which is the chip that comes on the Due board, to talk to my android phone , just like I had with the combo Mega2560 (chip used on RA+) and MAX3421.
That was the main reason that would make or break the deal. Now that I can communicate with Android directly using the ARM processor, I can start porting our libraries to the new architecture.
One of the drawbacks of the SAM3X8E is that it does not have internal EEPROM, so I'll have to move all internal memory settings to external EEPROM or wait until the Arduino team comes up with a way to save into Flash memory instead.
All PROGMEM variables will also need to be modified too or wait on the Arduino team once again.
I'll keep updates coming as I move along and have any progress.
Roberto.
Re: Porting from AVR to ARM
Hey Roberto,
What does this mean in layman's terms?
--Colin
What does this mean in layman's terms?
--Colin
Re: Porting from AVR to ARM
cosmith71 wrote:Hey Roberto,
What does this mean in layman's terms?
--Colin
Thanks for asking
Re: Porting from AVR to ARM
The main goal here is to be able to support the protocol standard USB OTG (On the Go).
https://en.wikipedia.org/wiki/USB_On-The-Go
If everything goes as I plan, the new RA head unit will be on another platform and Curt's android app will become the new RA screen
The android device would be connected though USB to the head unit instead of wifi.
https://en.wikipedia.org/wiki/USB_On-The-Go
If everything goes as I plan, the new RA head unit will be on another platform and Curt's android app will become the new RA screen
The android device would be connected though USB to the head unit instead of wifi.
Roberto.
Re: Porting from AVR to ARM
Ah, OK. New hardware. How far out?
--Colin
--Colin
Re: Porting from AVR to ARM
that sounds pretty cool.
Sent from my iPad mini
Sent from my iPad mini
Re: Porting from AVR to ARM
PROGMEM was easy
In ARM architecture, if you declare the variable as const, it will be stored in flash and not RAM.
Well, we are going to have a lot more memory too... 512K flash for code and 96K RAM and no EEPROM
In ARM architecture, if you declare the variable as const, it will be stored in flash and not RAM.
Well, we are going to have a lot more memory too... 512K flash for code and 96K RAM and no EEPROM
Roberto.
Re: Porting from AVR to ARM
With no EEPROM how will we save things we want persistent?
Re: Porting from AVR to ARM
That's the point I raised on the original post.
We can't just with the processor alone. We will need to use the external EEPROM.
RA and RA+ have 2 external EEPROM banks of 32K each So, I can use the same chips.
The first bank is used for storing the graph plots and the 2nd bank is used for graphics.
The graphics were dumped a long time ago and the graphs won't be necessary on this new board. I originally had dropped them from the board, but reinstated it back when I realized we needed EEPROM.
We can't just with the processor alone. We will need to use the external EEPROM.
RA and RA+ have 2 external EEPROM banks of 32K each So, I can use the same chips.
The first bank is used for storing the graph plots and the 2nd bank is used for graphics.
The graphics were dumped a long time ago and the graphs won't be necessary on this new board. I originally had dropped them from the board, but reinstated it back when I realized we needed EEPROM.
Roberto.
Re: Porting from AVR to ARM
Ok, so I face a problem right now.
Arduino decided to use some of our class instances.
RTC and PWM are the two so far.
RTC was easy because it is not used by us, so I just renamed to RTC_EXTERNAL, just because the SAM3 has internal RTC, which we will not use.
But, the PWM is a tough one. It's widely spread and used by us. I had already thought of changing it in the past when we started doing analog dimming, but always thought it would just break everyone's code.
So, I'm thinking of using the same auto-feature detection and correct the code on the fly everytime there is a reference of PWM within the INO code. This would make it easier for everyone.
I'll figure out the way to get that auto-correction on the fly.
My question is now, what should we call this new class reference?
Here are two I thought:
VariableSpeed
Dimming
Maybe you guys can give me some input or another name for it
Arduino decided to use some of our class instances.
RTC and PWM are the two so far.
RTC was easy because it is not used by us, so I just renamed to RTC_EXTERNAL, just because the SAM3 has internal RTC, which we will not use.
But, the PWM is a tough one. It's widely spread and used by us. I had already thought of changing it in the past when we started doing analog dimming, but always thought it would just break everyone's code.
So, I'm thinking of using the same auto-feature detection and correct the code on the fly everytime there is a reference of PWM within the INO code. This would make it easier for everyone.
I'll figure out the way to get that auto-correction on the fly.
My question is now, what should we call this new class reference?
Here are two I thought:
VariableSpeed
Dimming
Maybe you guys can give me some input or another name for it
Roberto.
Re: Porting from AVR to ARM
Who uses the PWM class directly? Everyone uses it through ReefAngel.PWM
Couldnt you just declare whatever new class name and still call it PWM inside ReefAngel? Would you change the xml as well if not then i would use the same variable name PWM and declare it is an RA_VarSpdDim who cares what the back end class is called...
As far as backwards compat, i dont think its so much of an issue. I could be wrong though.
I would call it 2.0 and ship it with the download and not do auto update. Sounds like this board would be the new direction forward.
Just my thoughts...maybe not the best..
Couldnt you just declare whatever new class name and still call it PWM inside ReefAngel? Would you change the xml as well if not then i would use the same variable name PWM and declare it is an RA_VarSpdDim who cares what the back end class is called...
As far as backwards compat, i dont think its so much of an issue. I could be wrong though.
I would call it 2.0 and ship it with the download and not do auto update. Sounds like this board would be the new direction forward.
Just my thoughts...maybe not the best..
Re: Porting from AVR to ARM
It doesn't work that way. At least it didn't work for me.
You can't have any reference to PWM anywhere, whether it is inside another class (ReefAngel.PWM) or not.
The internal class has not issues as we call it RA_PWM anyway, so there is no conflict there.
I don't think we need to change the XML tags as most people usually are not going to be seeing them anyway.
It is just the PWM reference that needs to be changed.
You can't have any reference to PWM anywhere, whether it is inside another class (ReefAngel.PWM) or not.
The internal class has not issues as we call it RA_PWM anyway, so there is no conflict there.
I don't think we need to change the XML tags as most people usually are not going to be seeing them anyway.
It is just the PWM reference that needs to be changed.
Roberto.
Re: Porting from AVR to ARM
I would think the VariableSpeed or VarSpeed or VarSpd or something of the like would be the name to use. The reason is now it's not just for dimming like initially. We have other devices that use those dimmable channels now as well. Or if you say RA_PWM is a valid name, you could just switch to RAPWM for the variable name but that may be a little confusing.
Re: Porting from AVR to ARM
Hehehe...
But variable speed doesn't relate to dimming either
I just got the name variable speed because it is how apex call theirs, I think.
But variable speed doesn't relate to dimming either
I just got the name variable speed because it is how apex call theirs, I think.
Roberto.
Re: Porting from AVR to ARM
or even better, "VariableControlledPWMChannelForDevices"?? just kidding.rimai wrote:How about Variable Control?
VariableControl would work fine to me. It indicates what it does and is used for.
-
- Posts: 137
- Joined: Sat Feb 16, 2013 7:44 am
Re: Porting from AVR to ARM
Very exciting stuff... What are the challenges with using a flash card?
Re: Porting from AVR to ARM
Are you talking about SD cards?
If so, none.
SD cards use SPI communication which are standard communication and I plan to have them available anyway.
Due to the way SD cards store stuff (FAT file system), it is much easier to do on EEPROM than doing on FAT for single byte reading/writing.
There is a way to do it. I've seen someone created a library for reading/writing single bytes, but I feel it is not worth the hassle. I'm thinking on using external EEPROM chip for this.
If so, none.
SD cards use SPI communication which are standard communication and I plan to have them available anyway.
Due to the way SD cards store stuff (FAT file system), it is much easier to do on EEPROM than doing on FAT for single byte reading/writing.
There is a way to do it. I've seen someone created a library for reading/writing single bytes, but I feel it is not worth the hassle. I'm thinking on using external EEPROM chip for this.
Roberto.
-
- Posts: 137
- Joined: Sat Feb 16, 2013 7:44 am
Re: Porting from AVR to ARM
Yes I meant SD cards... I would actually challenge you on this. Here are my thoughts With the SD card if something goes wrong with the data storage, I can just replace. I could also use a computer program to change the values(Ascii format)... I could store strings, localize the strings for various languages/cultures, define complex schemes of configuration settings (Think custom screen layouts) - just to name a few ideas... As for the complexity of reading and writing an ascii file, it is a one time hit. For customers that are not developers that rather not compile code, this could be a very easy way to configure settings without having to re-compile.
Just my 2 cents
Just my 2 cents
Re: Porting from AVR to ARM
Roberto et al.
I just got my Reef Angel, although been following its dev for years, but was delayed in getting a tank setup. Now that the tank is getting going, I could justify finally getting an RA. I really am impressed with everything Roberto and the team have put together. Back in the late 90s I hacked my Neptune systems controller and put it on the internet which freaked them out a bit. Its great to see how far along controllers have come.
I am considering building a new head unit built around the the spark core. (I don't have permission to link to sites for some reason but it is w w w . s p a r k . i o
I was in on their kickstarter and should receive mine next month. It has a lot of cool features including integrated wifi and wireless, cloud-based programming etc.. It is based on the Arm M3, so I was wondering about porting issues when I found this thread. I assume the class collisions will still be an issue as its an Arduino one, not a ARM issue. Is that correct?
I don't know how far down the road RA is on developing a new head unit or the architecture, but I'd like to respectively propose that the RA dev team take a look at the Spark Core. If you think it is interesting, I'd be interested in helping out.
I just got my Reef Angel, although been following its dev for years, but was delayed in getting a tank setup. Now that the tank is getting going, I could justify finally getting an RA. I really am impressed with everything Roberto and the team have put together. Back in the late 90s I hacked my Neptune systems controller and put it on the internet which freaked them out a bit. Its great to see how far along controllers have come.
I am considering building a new head unit built around the the spark core. (I don't have permission to link to sites for some reason but it is w w w . s p a r k . i o
I was in on their kickstarter and should receive mine next month. It has a lot of cool features including integrated wifi and wireless, cloud-based programming etc.. It is based on the Arm M3, so I was wondering about porting issues when I found this thread. I assume the class collisions will still be an issue as its an Arduino one, not a ARM issue. Is that correct?
I don't know how far down the road RA is on developing a new head unit or the architecture, but I'd like to respectively propose that the RA dev team take a look at the Spark Core. If you think it is interesting, I'd be interested in helping out.
Re: Porting from AVR to ARM
Thanks! BTW, got your PM, but I don't have privileges to respond!
Guess, I need to post some more. Hard when you don't want to add to convos just to get your post count up...
Hoping to have some cycles in the next few months to start to dig into all the code and hardware and get a better understanding "under the hood."
As I said, super impressed with what is going on and really appreciate all the hard work Roberto and the community has put into RA.
Guess, I need to post some more. Hard when you don't want to add to convos just to get your post count up...
Hoping to have some cycles in the next few months to start to dig into all the code and hardware and get a better understanding "under the hood."
As I said, super impressed with what is going on and really appreciate all the hard work Roberto and the community has put into RA.
Re: Porting from AVR to ARM
I already looked into the spark chip, but they were not released and I didn't fund the kickstarter project.
I was waiting for them to come out of pre-order to dig further.
I was waiting for them to come out of pre-order to dig further.
Roberto.
Re: Porting from AVR to ARM
From the specs on their page, do you see anything major that would not work for what is here today or what you are planning in the future? (Specs below)
Spark Core
8 digital I/O pins, 8 analog I/O pins
4 PWM pins; UART (Serial), SPI, I2C, and JTAG peripherals available
Programmed wirelessly (through Spark Cloud), via USB or JTAG
3.3V DC supply voltage (on board power regulator); can be powered by USB Micro
100mA typical current consumption; 300mA peak consumption (during transmit events)
2MB of external flash; EEPROM supplied by CC3000
Microcontroller
STM32F103 microcontroller
ARM Cortex M3 architecture
32-bit 72Mhz processor
128KB of Flash, 20KB of RAM
Wi-Fi module
Texas Instruments SimpleLink CC3000
802.11b/g
Range of 100-300 feet
Spark Core
8 digital I/O pins, 8 analog I/O pins
4 PWM pins; UART (Serial), SPI, I2C, and JTAG peripherals available
Programmed wirelessly (through Spark Cloud), via USB or JTAG
3.3V DC supply voltage (on board power regulator); can be powered by USB Micro
100mA typical current consumption; 300mA peak consumption (during transmit events)
2MB of external flash; EEPROM supplied by CC3000
Microcontroller
STM32F103 microcontroller
ARM Cortex M3 architecture
32-bit 72Mhz processor
128KB of Flash, 20KB of RAM
Wi-Fi module
Texas Instruments SimpleLink CC3000
802.11b/g
Range of 100-300 feet
Re: Porting from AVR to ARM
Spark just emailed. They are pushing back delivery again. ugh. Now its Nov 4th
Re: Porting from AVR to ARM
Do you have access to their cloud software to upload codes yet?
Roberto.
-
- Posts: 3
- Joined: Tue Jul 30, 2013 2:46 am
Re: Porting from AVR to ARM
Hi,
What's about the new Intel Galileo Platform. Here are some of the specs:
Intel® Galileo includes native Ethernet, SD, USB Host support, USB Client support, RS-232 serial port, and 10 pin JTAG ports. It also includes Arduino* shield connectors compliant with the Arduino* Uno R3 connector definition. Finally it includes a native mini-PCIe connector for the addition of Wi-Fi (for example).
Arduino* Uno R3 is the compatibility. Some shields may not work properly due to hard-coded registers in the shield drivers; however, Intel is working with Arduino and shield owners to correct the drivers.
Intel® Galileo can be connected to the internet by connecting the on-board Ethernet RJ45 connector to your home router. Intel Galileo firmware includes DHCP for automatic configuration of the Ethernet interface with an IP address. It can also be connected wirelessly or over 3G via expansion on PCIe or shields.
Intel® Galileo comes with an integrated onboard NIC and the embedded Linux* on the board has the drivers for the NIC already.
Intel® Galileo does have I/O features often found on desktop boards or laptops and not easily found on an Arduino* boards such as full USB host and PCI express capability.
Can I run Linux on Intel® Galileo?
Yes. Intel® Galileo runs Linux* out of the box. It comes in two flavors; the default is a small Linux. If you add an SD card to your kit, you can add a more fully-featured Linux. Refer to the Intel® Galileo Getting Started Guide and Intel® Quark SoC X1000 IoT Development Kit Software GSG.
Best regards,
Manuel
What's about the new Intel Galileo Platform. Here are some of the specs:
Intel® Galileo includes native Ethernet, SD, USB Host support, USB Client support, RS-232 serial port, and 10 pin JTAG ports. It also includes Arduino* shield connectors compliant with the Arduino* Uno R3 connector definition. Finally it includes a native mini-PCIe connector for the addition of Wi-Fi (for example).
Arduino* Uno R3 is the compatibility. Some shields may not work properly due to hard-coded registers in the shield drivers; however, Intel is working with Arduino and shield owners to correct the drivers.
Intel® Galileo can be connected to the internet by connecting the on-board Ethernet RJ45 connector to your home router. Intel Galileo firmware includes DHCP for automatic configuration of the Ethernet interface with an IP address. It can also be connected wirelessly or over 3G via expansion on PCIe or shields.
Intel® Galileo comes with an integrated onboard NIC and the embedded Linux* on the board has the drivers for the NIC already.
Intel® Galileo does have I/O features often found on desktop boards or laptops and not easily found on an Arduino* boards such as full USB host and PCI express capability.
Can I run Linux on Intel® Galileo?
Yes. Intel® Galileo runs Linux* out of the box. It comes in two flavors; the default is a small Linux. If you add an SD card to your kit, you can add a more fully-featured Linux. Refer to the Intel® Galileo Getting Started Guide and Intel® Quark SoC X1000 IoT Development Kit Software GSG.
Best regards,
Manuel