Pi as developing board for ARM9 board and how to start my project

You might be better off considering the Beagleboard Black. It already has Angstrom on board and so your work would probably port more easily.

best,

Derek

Thank you for the advice! I'm checking it.

Ulrich

I'd suggest you setup a decent development environment in a Linux PC. You will have to use a cross compiler anyway, so the Raspberry Pi won't help you much, also compiling the kernel or other big chunks of code may take forever and put a lot of wear on the SD card or similar storage media.

I don't have the link to the detailed instructions at hand but you can start looking at http://www.angstrom-distribution.org/building-angstrom

My .02

Jorge

Thank you Jorge! Yes, that might be the better way to go. I also read that several users are having trouble using angström with the BeagleBone Black.

The link to the angström distribution I read before already. And again I'm a bit confused because I don't see any option there for a Linux PC processor - e.g. intel_x64. I will keep researching. 

Best regards,

Ulrich

@Jorge: Right now I'm struggeling a bit with what you wrote. I thought for my task I don't need to modify the Linux kernel (regularly), or is there something I don't understand? I thought I just need to write an application for handling the fieldbus and setup the webserver..

Ulrich

Just to be clear, I wasn't suggesting using a BBB as a development environment, necessarily. I was suggesting using it in place of your currently unavailable target hardware.

I'm curious to know which problems with Angstrom on the BBB discouraged you. My impression is that there will always be problems reported when people apply new hardware to their fields of interest. The Raspberry Pi has very similar discussions about getting things to work.

I think you are right, there is no obvious need to modify the Linux kernel for what you are doing. However, if you want to use Angstrom on a Raspberry Pi, then you will need to build it because no off the shelf prebuilt distribution exists (as far as I know). I note that there is a raspberry-pi branch of Angstrom which is a good sign. I note also that their wiki and FAQ page links are broken, which is not.

While I agree with jamodios comment about a host build environment, I still think the BBB is going to be a faster route to (my understanding of) where you want to be.

Derek

Ulrich, it's very interesting to hear that you're involved in KNX interfacing and control.  We have previously touched on fieldbus use (over in the BBB or SBC non-group), but that was for the industrial EtherCAT fieldbus which has relatively little traction compared to the more residentially oriented KNX.  Home and building automation seems very likely to bloom in the next few decades, so this is a promising topic with which to be involved.

One of the benefits of KNX which promotes its success is that it allows many different  topologies and physical implementations rather than being narrowly prescriptive.  On the downside though, while KNX has registered "standards" very widely (EN 50090, EN 13321-1, ISO/IEC 14543), the organization behind KNX seems rather inimical to open source, open hardware, and even open specification, so supporting them is not very palatable nor helpful.  With enough open source interest in KNX though, perhaps their eyes can be opened a bit.  Work like yours could help there.

Here's an article from a KNX conference which sounds like it might bear some relevance to your work:  "Controlling EIB/KNX devices from Linux using USB".  You haven't said to which KNX physical medium you're intending to couple, and KNX specifies all of TP, Powerline, RF, and Ethernet/IP, but they all have USB interfaces so this article is probably applicable to a wide range of KNX systems.

Even better, for real code and more ideas, visit these projects:  List of KNX Open Source or free software.

Regarding development platforms for this or any other work, I agree with what others have said here, that at this time, development is best done on a standard x86/amd64 Linux or *BSD box.  This will change as ARM systems get faster, gain more memory and provide better storage interfaces as standard, but right now serious development is much slower and generally less satisfactory when done natively on an ARM board.  For any non-trivial project, cross-compile on your powerful desktop to your desired ARM target.

I'd love to hear more technical details about your project.  The  feedback here is likely to be more helpful the more details you supply.

Hi,

I'm sorry for the late reply I have been on a trip.

Thank you for your replies.

@Derek: When I was reading more about the BBB, I noticed that the issues with Angström are related to what you said (<My impression is that there will always be problems reported when people apply new hardware to their fields of interest.>). So I guess it would be ok as an development board. However, I decided to buy the evaluation board to my MCU to make it more easy to port the software to the final board later.

@Morgaine: Thank you for your information! I have to tell that this is going to be a commercial project.. But since we are a small business I fully understand your difficulties with KNX - obviously there are different ideas of an "open" standard...

My project is going to be initially TP only. Later there might be an update for Ethernet/IP. I'm going to use ready made KNX libraries for the project since it would take to much resources to implement and certify the KNX stack myself.

I'm still not sure which development platform to use. Does it make sense to get an extra linux machine or would developing with PC+Eclipse+debugging on target be good enough?

Have a nice day!

Ulrich

Ulrich Steurenthaler wrote:

 

I'm still not sure which development platform to use. Does it make sense to get an extra linux machine or would developing with PC+Eclipse+debugging on target be good enough?

 

Yes

-J

I'd definitely recommend using a separate host platform. I have had great success using Eclipse and remote debugging. It is much easier to set up now than it used to be.

Unless your development board has something built in, you'll need an On Chip Debug (OCD) adapter, Olimex makes them among others. OpenOCD is the least expensive route and is also much better than it was. The adaptor has USB on one side and a JTAG connector on the other. Once set up it is much like using a debugger on a local program. The biggest difference is when debugging flash resident code where you are limited to hardware breakpoints.

Of course, you may know this already, just saying in case someone else finds this useful.