We've used Rabbit based modules in the past, but have moved onto ARM CPUs,
and have now done a couple of ports of RCM3xxx based modules to ARM CPUs.
We're wondering if there is enough interest out there to do a RCM3xxx pin
compatible module with an ARM processor.
While Dynamic C is not ANSI standard, in many cases it's close enough to
move code, and in the ARM the RAM paging is not an issue.
bringing ARM CPUs into the RCM modules
Started by ●January 4, 2013
Reply by ●January 4, 20132013-01-04
yes! sound good, interesting for me.
Take in consideration RCM2xxx parts too.
But the real issue for my market, is the price.
Hernan - Embedded Systems Developer.
Country: Argentina.
--- In r..., "basicnode" wrote:
>
> We've used Rabbit based modules in the past, but have moved onto ARM CPUs, and have now done a couple of ports of RCM3xxx based modules to ARM CPUs.
>
> We're wondering if there is enough interest out there to do a RCM3xxx pin compatible module with an ARM processor.
>
> While Dynamic C is not ANSI standard, in many cases it's close enough to move code, and in the ARM the RAM paging is not an issue.
>
Take in consideration RCM2xxx parts too.
But the real issue for my market, is the price.
Hernan - Embedded Systems Developer.
Country: Argentina.
--- In r..., "basicnode" wrote:
>
> We've used Rabbit based modules in the past, but have moved onto ARM CPUs, and have now done a couple of ports of RCM3xxx based modules to ARM CPUs.
>
> We're wondering if there is enough interest out there to do a RCM3xxx pin compatible module with an ARM processor.
>
> While Dynamic C is not ANSI standard, in many cases it's close enough to move code, and in the ARM the RAM paging is not an issue.
>
Reply by ●January 4, 20132013-01-04
On 1/4/2013 11:22 AM, hemonserrat wrote:
> yes! sound good, interesting for me.
> Take in consideration RCM2xxx parts too.
> But the real issue for my market, is the price.
>
> Hernan - Embedded Systems Developer.
> Country: Argentina.
>
> --- In r..., "basicnode" wrote:
>> >
>> > We've used Rabbit based modules in the past, but have moved onto ARM CPUs, and have now done a couple of ports of RCM3xxx based modules to ARM CPUs.
>> >
>> > We're wondering if there is enough interest out there to do a RCM3xxx pin compatible module with an ARM processor.
>> >
>> > While Dynamic C is not ANSI standard, in many cases it's close enough to move code, and in the ARM the RAM paging is not an issue.
>> >
I have been working on replacing my modules with PIC32 chips. Only issue
is they are only 128k RAM.
The Beagleboard and Rasberry Pi are also looking good to have several
orders of magnitude more processing power/memory at about the same cost.
I'm curious what you are using for ARM development tools.
--
------
Scott G. Henion, Consultant
Web site: http://SHDesigns.org
------
> yes! sound good, interesting for me.
> Take in consideration RCM2xxx parts too.
> But the real issue for my market, is the price.
>
> Hernan - Embedded Systems Developer.
> Country: Argentina.
>
> --- In r..., "basicnode" wrote:
>> >
>> > We've used Rabbit based modules in the past, but have moved onto ARM CPUs, and have now done a couple of ports of RCM3xxx based modules to ARM CPUs.
>> >
>> > We're wondering if there is enough interest out there to do a RCM3xxx pin compatible module with an ARM processor.
>> >
>> > While Dynamic C is not ANSI standard, in many cases it's close enough to move code, and in the ARM the RAM paging is not an issue.
>> >
I have been working on replacing my modules with PIC32 chips. Only issue
is they are only 128k RAM.
The Beagleboard and Rasberry Pi are also looking good to have several
orders of magnitude more processing power/memory at about the same cost.
I'm curious what you are using for ARM development tools.
--
------
Scott G. Henion, Consultant
Web site: http://SHDesigns.org
------
Reply by ●January 4, 20132013-01-04
I speculate that the reason this hasn't been done to date (I've
thought about this idea several years ago) is because it would be practically
impossible to match the Rabbit module pricing, especially the Ethernet
modules.
Also, under the current license, you cannot port Dynamic C libs to an ARM (even with DC-specific changes removed). TCP/IP isn't an issue because the Open Source lwIP stack is far superior to DC's TCP/IP stack and they have a beta with IPv6 as well. Making a wireless ARM module would be a huge undertaking. End user code could relatively easily be ported - I wrote DC2ANSI which is used to convert the DC stack to ANSI C for Softools. There were still some changes required but it did 95% of the job.
Just my 3 cents worth...
Bill
--- In r..., "hemonserrat" wrote:
>
> yes! sound good, interesting for me.
> Take in consideration RCM2xxx parts too.
> But the real issue for my market, is the price.
>
> Hernan - Embedded Systems Developer.
> Country: Argentina.
>
> --- In r..., "basicnode" wrote:
> >
> > We've used Rabbit based modules in the past, but have moved onto ARM CPUs, and have now done a couple of ports of RCM3xxx based modules to ARM CPUs.
> >
> > We're wondering if there is enough interest out there to do a RCM3xxx pin compatible module with an ARM processor.
> >
> > While Dynamic C is not ANSI standard, in many cases it's close enough to move code, and in the ARM the RAM paging is not an issue.
>
Also, under the current license, you cannot port Dynamic C libs to an ARM (even with DC-specific changes removed). TCP/IP isn't an issue because the Open Source lwIP stack is far superior to DC's TCP/IP stack and they have a beta with IPv6 as well. Making a wireless ARM module would be a huge undertaking. End user code could relatively easily be ported - I wrote DC2ANSI which is used to convert the DC stack to ANSI C for Softools. There were still some changes required but it did 95% of the job.
Just my 3 cents worth...
Bill
--- In r..., "hemonserrat" wrote:
>
> yes! sound good, interesting for me.
> Take in consideration RCM2xxx parts too.
> But the real issue for my market, is the price.
>
> Hernan - Embedded Systems Developer.
> Country: Argentina.
>
> --- In r..., "basicnode" wrote:
> >
> > We've used Rabbit based modules in the past, but have moved onto ARM CPUs, and have now done a couple of ports of RCM3xxx based modules to ARM CPUs.
> >
> > We're wondering if there is enough interest out there to do a RCM3xxx pin compatible module with an ARM processor.
> >
> > While Dynamic C is not ANSI standard, in many cases it's close enough to move code, and in the ARM the RAM paging is not an issue.
>
Reply by ●January 4, 20132013-01-04
I would be interested in an ARM based board compatible with the Rabbit Core
Modules, e.g. RCM5760.
Email me direct if you need any details.
On Fri, Jan 4, 2013 at 8:28 AM, Scott Henion wrote:
> **
> On 1/4/2013 11:22 AM, hemonserrat wrote:
> > yes! sound good, interesting for me.
> > Take in consideration RCM2xxx parts too.
> > But the real issue for my market, is the price.
> >
> > Hernan - Embedded Systems Developer.
> > Country: Argentina.
> >
> > --- In r..., "basicnode" wrote:
> >> >
> >> > We've used Rabbit based modules in the past, but have moved onto ARM
> CPUs, and have now done a couple of ports of RCM3xxx based modules to ARM
> CPUs.
> >> >
> >> > We're wondering if there is enough interest out there to do a RCM3xxx
> pin compatible module with an ARM processor.
> >> >
> >> > While Dynamic C is not ANSI standard, in many cases it's close enough
> to move code, and in the ARM the RAM paging is not an issue.
> >> > I have been working on replacing my modules with PIC32 chips. Only issue
> is they are only 128k RAM.
>
> The Beagleboard and Rasberry Pi are also looking good to have several
> orders of magnitude more processing power/memory at about the same cost.
>
> I'm curious what you are using for ARM development tools.
>
> --
> ------
> Scott G. Henion, Consultant
> Web site: http://SHDesigns.org
> ------
>
>
>
Modules, e.g. RCM5760.
Email me direct if you need any details.
On Fri, Jan 4, 2013 at 8:28 AM, Scott Henion wrote:
> **
> On 1/4/2013 11:22 AM, hemonserrat wrote:
> > yes! sound good, interesting for me.
> > Take in consideration RCM2xxx parts too.
> > But the real issue for my market, is the price.
> >
> > Hernan - Embedded Systems Developer.
> > Country: Argentina.
> >
> > --- In r..., "basicnode" wrote:
> >> >
> >> > We've used Rabbit based modules in the past, but have moved onto ARM
> CPUs, and have now done a couple of ports of RCM3xxx based modules to ARM
> CPUs.
> >> >
> >> > We're wondering if there is enough interest out there to do a RCM3xxx
> pin compatible module with an ARM processor.
> >> >
> >> > While Dynamic C is not ANSI standard, in many cases it's close enough
> to move code, and in the ARM the RAM paging is not an issue.
> >> > I have been working on replacing my modules with PIC32 chips. Only issue
> is they are only 128k RAM.
>
> The Beagleboard and Rasberry Pi are also looking good to have several
> orders of magnitude more processing power/memory at about the same cost.
>
> I'm curious what you are using for ARM development tools.
>
> --
> ------
> Scott G. Henion, Consultant
> Web site: http://SHDesigns.org
> ------
>
>
>
Reply by ●January 4, 20132013-01-04
Il 04/01/2013 17:34, BillA ha scritto:
>
>
> I speculate that the reason this hasn't been done to date (I've
> thought about this idea several years ago) is because it would be
> practically impossible to match the Rabbit module pricing, especially
> the Ethernet modules.
>
This is not true today and in the past 5-6 years was the same.
> Also, under the current license, you cannot port Dynamic C libs to an
> ARM (even with DC-specific changes removed). TCP/IP isn't an issue
> because the Open Source lwIP stack is far superior to DC's TCP/IP
> stack and they have a beta with IPv6 as well. Making a wireless ARM
> module would be a huge undertaking. End user code could relatively
> easily be ported - I wrote DC2ANSI which is used to convert the DC
> stack to ANSI C for Softools. There were still some changes required
> but it did 95% of the job.
>
There are many Courts in USA and around the world said that an API can't
be patented except under very particular conditions that DC doesn't
meet. So using the same prototypes could be done rewriting the functions
implementation. And also being more conservative you could just need a
little refactoring of function names to change also the API calls.
> Just my 3 cents worth...
>
> Bill
>
> --- In r...
> , "hemonserrat" wrote:
> >
> > yes! sound good, interesting for me.
> > Take in consideration RCM2xxx parts too.
> > But the real issue for my market, is the price.
> >
> > Hernan - Embedded Systems Developer.
> > Country: Argentina.
> >
> > --- In r...
> , "basicnode" wrote:
> > >
> > > We've used Rabbit based modules in the past, but have moved onto
> ARM CPUs, and have now done a couple of ports of RCM3xxx based modules
> to ARM CPUs.
> > >
> > > We're wondering if there is enough interest out there to do a
> RCM3xxx pin compatible module with an ARM processor.
> > >
> > > While Dynamic C is not ANSI standard, in many cases it's close
> enough to move code, and in the ARM the RAM paging is not an issue.
> > >
> >
>
>
> I speculate that the reason this hasn't been done to date (I've
> thought about this idea several years ago) is because it would be
> practically impossible to match the Rabbit module pricing, especially
> the Ethernet modules.
>
This is not true today and in the past 5-6 years was the same.
> Also, under the current license, you cannot port Dynamic C libs to an
> ARM (even with DC-specific changes removed). TCP/IP isn't an issue
> because the Open Source lwIP stack is far superior to DC's TCP/IP
> stack and they have a beta with IPv6 as well. Making a wireless ARM
> module would be a huge undertaking. End user code could relatively
> easily be ported - I wrote DC2ANSI which is used to convert the DC
> stack to ANSI C for Softools. There were still some changes required
> but it did 95% of the job.
>
There are many Courts in USA and around the world said that an API can't
be patented except under very particular conditions that DC doesn't
meet. So using the same prototypes could be done rewriting the functions
implementation. And also being more conservative you could just need a
little refactoring of function names to change also the API calls.
> Just my 3 cents worth...
>
> Bill
>
> --- In r...
> , "hemonserrat" wrote:
> >
> > yes! sound good, interesting for me.
> > Take in consideration RCM2xxx parts too.
> > But the real issue for my market, is the price.
> >
> > Hernan - Embedded Systems Developer.
> > Country: Argentina.
> >
> > --- In r...
> , "basicnode" wrote:
> > >
> > > We've used Rabbit based modules in the past, but have moved onto
> ARM CPUs, and have now done a couple of ports of RCM3xxx based modules
> to ARM CPUs.
> > >
> > > We're wondering if there is enough interest out there to do a
> RCM3xxx pin compatible module with an ARM processor.
> > >
> > > While Dynamic C is not ANSI standard, in many cases it's close
> enough to move code, and in the ARM the RAM paging is not an issue.
> > >
> >
Reply by ●January 4, 20132013-01-04
--- In r..., "M. Manca" wrote:
>
> On 04/01/2013 17:34, BillA wrote:
> >
> >
> > I speculate that the reason this hasn't been done to date (I've
> > thought about this idea several years ago) is because it would be
> > practically impossible to match the Rabbit module pricing, especially
> > the Ethernet modules.
> >
> This is not true today and in the past 5-6 years was the same.
When someone designs this pin compatible ARM module then comes up with a price to sell it through DigiKey and Mouser they will make next to nothing on it. Sure, you'd make more marketing direct but cut out these big distributors and you'll have a lot of trouble selling.
> There are many Courts in USA and around the world said that an API can't
> be patented except under very particular conditions that DC doesn't
> meet. So using the same prototypes could be done rewriting the functions
> implementation. And also being more conservative you could just need a
> little refactoring of function names to change also the API calls.
Who said anything about API? I know I didn't.
Bill
>
> On 04/01/2013 17:34, BillA wrote:
> >
> >
> > I speculate that the reason this hasn't been done to date (I've
> > thought about this idea several years ago) is because it would be
> > practically impossible to match the Rabbit module pricing, especially
> > the Ethernet modules.
> >
> This is not true today and in the past 5-6 years was the same.
When someone designs this pin compatible ARM module then comes up with a price to sell it through DigiKey and Mouser they will make next to nothing on it. Sure, you'd make more marketing direct but cut out these big distributors and you'll have a lot of trouble selling.
> There are many Courts in USA and around the world said that an API can't
> be patented except under very particular conditions that DC doesn't
> meet. So using the same prototypes could be done rewriting the functions
> implementation. And also being more conservative you could just need a
> little refactoring of function names to change also the API calls.
Who said anything about API? I know I didn't.
Bill
Reply by ●January 8, 20132013-01-08
We’d be potentially be interested in a replacement RCM3000 module.
Cheers,
Ian Lovatt
Embedded Software Engineer
t-mac Technologies
[footer6 copy]
t-mac Technologies Ltd
Stand Park, Sheffield Road, Chesterfield, Derbyshire, S41 8JT
T. +44 (0)844 287 0007 F. +44 (0)844 287 0006
Technical Support. +44 (0)203 322 3001
E. i...@t-mac.co.uk W. www.t-mac.co.uk
B. blog.t-mac.co.uk/
From: r... [mailto:r...] On Behalf Of basicnode
Sent: 04 January 2013 15:36
To: r...
Subject: [rabbit-semi] bringing ARM CPUs into the RCM modules
We've used Rabbit based modules in the past, but have moved onto ARM CPUs, and have now done a couple of ports of RCM3xxx based modules to ARM CPUs.
We're wondering if there is enough interest out there to do a RCM3xxx pin compatible module with an ARM processor.
While Dynamic C is not ANSI standard, in many cases it's close enough to move code, and in the ARM the RAM paging is not an issue.
________________________________
http://www.t-mac.co.uk/ Monitor, Meter, Manage, Control. BMS & Energy Management.
Telephone: 0844 287 0007 (International +44 (0)1246 233 632)
Support: 0203 322 3001 (International +44 (0) 203 322 3001 )
Fax: 0844 287 0006 (International +44 (0)1246 201193)
Please consider the environment before printing this email message.
E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. t-mac Technologies therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.
t-mac Technologies Ltd. Registered in England. Company No 5254756. Stand Park. Sheffield Road. Chesterfield. S41 8JT.
Cheers,
Ian Lovatt
Embedded Software Engineer
t-mac Technologies
[footer6 copy]
t-mac Technologies Ltd
Stand Park, Sheffield Road, Chesterfield, Derbyshire, S41 8JT
T. +44 (0)844 287 0007 F. +44 (0)844 287 0006
Technical Support. +44 (0)203 322 3001
E. i...@t-mac.co.uk W. www.t-mac.co.uk
B. blog.t-mac.co.uk/
From: r... [mailto:r...] On Behalf Of basicnode
Sent: 04 January 2013 15:36
To: r...
Subject: [rabbit-semi] bringing ARM CPUs into the RCM modules
We've used Rabbit based modules in the past, but have moved onto ARM CPUs, and have now done a couple of ports of RCM3xxx based modules to ARM CPUs.
We're wondering if there is enough interest out there to do a RCM3xxx pin compatible module with an ARM processor.
While Dynamic C is not ANSI standard, in many cases it's close enough to move code, and in the ARM the RAM paging is not an issue.
________________________________
http://www.t-mac.co.uk/ Monitor, Meter, Manage, Control. BMS & Energy Management.
Telephone: 0844 287 0007 (International +44 (0)1246 233 632)
Support: 0203 322 3001 (International +44 (0) 203 322 3001 )
Fax: 0844 287 0006 (International +44 (0)1246 201193)
Please consider the environment before printing this email message.
E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. t-mac Technologies therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.
t-mac Technologies Ltd. Registered in England. Company No 5254756. Stand Park. Sheffield Road. Chesterfield. S41 8JT.
Reply by ●January 25, 20132013-01-25
I have contemplated the same thing but I always come back to just redesigning my
whole main board. If you were to go down the road of an "ARM3xxx" you might
look at these ARM procs from ST,
http://www.st.com/internet/mcu/subclass/1521.jsp
--- In r..., Ian Lovatt wrote:
>
> We’d be potentially be interested in a replacement RCM3000 module.
>
> Cheers,
>
>
> Ian Lovatt
> Embedded Software Engineer
> t-mac Technologies
>
>
> [footer6 copy]
>
>
> t-mac Technologies Ltd
> Stand Park, Sheffield Road, Chesterfield, Derbyshire, S41 8JT
>
> T. +44 (0)844 287 0007 F. +44 (0)844 287 0006
> Technical Support. +44 (0)203 322 3001
> E. ian.lovatt@... W. www.t-mac.co.uk
> B. blog.t-mac.co.uk/
>
>
>
> From: r... [mailto:r...] On Behalf Of basicnode
> Sent: 04 January 2013 15:36
> To: r...
> Subject: [rabbit-semi] bringing ARM CPUs into the RCM modules
>
>
>
>
> We've used Rabbit based modules in the past, but have moved onto ARM CPUs, and have now done a couple of ports of RCM3xxx based modules to ARM CPUs.
>
> We're wondering if there is enough interest out there to do a RCM3xxx pin compatible module with an ARM processor.
>
> While Dynamic C is not ANSI standard, in many cases it's close enough to move code, and in the ARM the RAM paging is not an issue.
>
>
>
>
> ________________________________
> http://www.t-mac.co.uk/ Monitor, Meter, Manage, Control. BMS & Energy Management.
> Telephone: 0844 287 0007 (International +44 (0)1246 233 632)
> Support: 0203 322 3001 (International +44 (0) 203 322 3001 )
> Fax: 0844 287 0006 (International +44 (0)1246 201193)
>
> Please consider the environment before printing this email message.
>
> E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. t-mac Technologies therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.
>
> t-mac Technologies Ltd. Registered in England. Company No 5254756. Stand Park. Sheffield Road. Chesterfield. S41 8JT.
>
--- In r..., Ian Lovatt wrote:
>
> We’d be potentially be interested in a replacement RCM3000 module.
>
> Cheers,
>
>
> Ian Lovatt
> Embedded Software Engineer
> t-mac Technologies
>
>
> [footer6 copy]
>
>
> t-mac Technologies Ltd
> Stand Park, Sheffield Road, Chesterfield, Derbyshire, S41 8JT
>
> T. +44 (0)844 287 0007 F. +44 (0)844 287 0006
> Technical Support. +44 (0)203 322 3001
> E. ian.lovatt@... W. www.t-mac.co.uk
> B. blog.t-mac.co.uk/
>
>
>
> From: r... [mailto:r...] On Behalf Of basicnode
> Sent: 04 January 2013 15:36
> To: r...
> Subject: [rabbit-semi] bringing ARM CPUs into the RCM modules
>
>
>
>
> We've used Rabbit based modules in the past, but have moved onto ARM CPUs, and have now done a couple of ports of RCM3xxx based modules to ARM CPUs.
>
> We're wondering if there is enough interest out there to do a RCM3xxx pin compatible module with an ARM processor.
>
> While Dynamic C is not ANSI standard, in many cases it's close enough to move code, and in the ARM the RAM paging is not an issue.
>
>
>
>
> ________________________________
> http://www.t-mac.co.uk/ Monitor, Meter, Manage, Control. BMS & Energy Management.
> Telephone: 0844 287 0007 (International +44 (0)1246 233 632)
> Support: 0203 322 3001 (International +44 (0) 203 322 3001 )
> Fax: 0844 287 0006 (International +44 (0)1246 201193)
>
> Please consider the environment before printing this email message.
>
> E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. t-mac Technologies therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.
>
> t-mac Technologies Ltd. Registered in England. Company No 5254756. Stand Park. Sheffield Road. Chesterfield. S41 8JT.
>
Reply by ●January 26, 20132013-01-26
I think the Freescale Kinetis K60 parts would make a good fit for an ARM3xxx
board.
512K Flash
6 x Uart
Ethernet
Usb
Cheers
Martin
--- In r..., "Steven" wrote:
> I have contemplated the same thing but I always come back to just redesigning my whole main board. If you were to go down the road of an "ARM3xxx" you might look at these ARM procs from ST, http://www.st.com/internet/mcu/subclass/1521.jsp
>
>
> --- In r..., Ian Lovatt wrote:
512K Flash
6 x Uart
Ethernet
Usb
Cheers
Martin
--- In r..., "Steven" wrote:
> I have contemplated the same thing but I always come back to just redesigning my whole main board. If you were to go down the road of an "ARM3xxx" you might look at these ARM procs from ST, http://www.st.com/internet/mcu/subclass/1521.jsp
>
>
> --- In r..., Ian Lovatt wrote:
