Cortex-M1 ARM Dev Kit

--- Quote Start ---

Can any of the included software build tool examples be used in NiosII Eclipse for this dev kit? I tried to use a generated sopcinfo file to start a project but the cpu field is not included since there is no Nios cpu in the design (cortex M1 instead) There is no way to manually add this cpu field?

--- Quote End ---

Hello.

If you want to run example projects for one board on the other board the answer is "no" and it would not make any sense.

As an example it will not make any sense to run a tool that demonstrates the use of a RS-232 IP on an FPGA on an ARM processor (whose RS-232 is completely different from Altera's one) and vice versa.

If you only want to use the Nios II Eclipse as IDE for both Nios and ARM the answer is: It should be possible to integrate an ARM C compiler into the Nios II eclipse so both Nios and ARM C code can be compiled using the same IDE.

Martin

Hi Martin,

--- Quote Start ---

As an example it will not make any sense to run a tool that demonstrates the use of a RS-232 IP on an FPGA on an ARM processor (whose RS-232 is completely different from Altera's one) and vice versa.

--- Quote End ---

You've missed a critical piece of information; the Cortex-M1 is a soft-core ARM (Arrow supplies the IP).

An SOPC or Qsys system can be created with an ARM Cortex-M1 Avalon-MM master, and an Altera Avalon-MM slave UART, and hence the UART would be identical to that used for a Nios II processor.

I'm not sure that the Cortex-M1 gained much traction though. I haven't seen many people asking questions about its use on this forum.

Cheers,

Dave

--- Quote Start ---

I use the Eclipse IDE but compile with Keil and its RTX RTOS and TCPnet. Ended up porting over some examples of SGDMA and Ethernet TSE usage. Has not been an easy task.

--- Quote End ---

Not a glowing endorsement then, eh? :)

Why did you decide that a Cortex-M1 would be a better choice than a NIOS II processor?

If you've been building systems for a while, the processor architectures eventually all blur together. At that point, the best way to select the architecture is to base it on support; either from the vendor or the community.

I figure "when in Rome" (when in an FPGA), using the vendor's soft-core processing is the option least likely to cause pain.

Cheers,

Dave