Porting from AVR to ARM
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
Re: Porting from AVR to ARM
unfortunately, I don't. Will post when I get my hands on one.rimai wrote:
Do you have access to their cloud software to upload codes yet?
I've been checking out their forum:https://community.sparkdevices.com/
and there are posts by people who have them. The I2C pins are exposed so I believe that would enable plug-in-play for Reef Angel accessories.
They are porting the standard Arduino libraries, but 3rd party libs would need to get ported (like OneWire)
Re: Porting from AVR to ARM
I received a prototype board this week and was able to get the Android ADK working on it so far.
I still need to see if the internal RTC works. All the other features are pretty standard and should be no problem for using them.
The biggest thing was to be able to talk to Android directly, which I was able to get it working.
I still need to see if the internal RTC works. All the other features are pretty standard and should be no problem for using them.
The biggest thing was to be able to talk to Android directly, which I was able to get it working.
Roberto.
Re: Porting from AVR to ARM
Oh my, i'm gonna have to keep an eye on this one. Using the ARM means faster and smoother operation. I was looking into the Galileo on adafruit for $99 and using the PCA9685 break out I have from them already and using either a 3.5" or 5" touch-screen.
-
- Posts: 1
- Joined: Fri Jan 17, 2014 2:08 pm
Re: Porting from AVR to ARM
Hello Roberto,
I too am very excited about an ARM based head unit; and have been considering Spark Core, and also reaserching Udoo.
Udoo seems interesting with both ARM i.MX6 CPU and ARM SAM3X8E Atmel, and according to website "ADK 2012 enabled - UDOO can act simultaneously as an Android host device and its connected ADK."
I'm sure a lot of us are wondering if you could estimate any timescale you might have in mind for a ARM based head unit with Android?
Regards,
Carlos
I too am very excited about an ARM based head unit; and have been considering Spark Core, and also reaserching Udoo.
Udoo seems interesting with both ARM i.MX6 CPU and ARM SAM3X8E Atmel, and according to website "ADK 2012 enabled - UDOO can act simultaneously as an Android host device and its connected ADK."
The features list seems amazing: HDMI and LVDS + Touch, USB OTG, camera connection. This is the direction I would love ReefAngel to go too; I can imagine an awesome aquarium controller already, especially with all the experience from ReefAngel community.rimai wrote:The main goal here is to be able to support the protocol standard USB OTG (On the Go).
You mentioned your progress with the Spark Core, have you also looked at the Udoo?rimai wrote:I received a prototype board this week and was able to get the Android ADK working on it so far.
I still need to see if the internal RTC works. All the other features are pretty standard and should be no problem for using them.
I'm sure a lot of us are wondering if you could estimate any timescale you might have in mind for a ARM based head unit with Android?
Regards,
Carlos
-
- Posts: 3
- Joined: Tue Jul 30, 2013 2:46 am
Re: Porting from AVR to ARM
Any News on the porting? No new post since 4 months
Re: Porting from AVR to ARM
Hi Roberto,
Any news on a port to a different MCU?
Any news on a port to a different MCU?
Re: Porting from AVR to ARM
I started it, but never went forward with it.
There were some issues with libraries in too early stages of being used yet, so I decided to wait out a bit.
There were some issues with libraries in too early stages of being used yet, so I decided to wait out a bit.
Roberto.