In the past I have done exactly what you're trying to do, go from an
Atmel Arm processor design to an NXP processor. The main difference I
found had to do with the interrupt vectoring and set up. Not to
mention the some low level drivers needed to interface to the
difference in peripherals. Once you've mastered the low level routines
by converting them over to the specific processor, your C application
code should port over quite well.
--- In l..., "rsturmer" wrote:
> --- In l..., "email_kc" wrote:
> > I have some codes and projects from Atmel Arm processors. Most are C
> > codes. How complicated will it be to convert this to NXP processors ?
> > I am new to embedded programming.
> > Thanks in advances!
> > I'm new to the NXP lineup as well, but in my experience, ease of
> migration varies wildly from project to project. If your codes are
> more processing and less use of peripherals, porting is fairly easy...
> if your code makes heavy use of the devices peripherals (which is fair
> more likely) You've got more work on your hands.
> It also depends heavily on how modularized the functionality of your
> codes are. A program for example that uses a get_spi_byte() function
> when a byte is retrieved from the SPI hardware, or say,
> set_pwm(channel, duty) to set a channel to a specified duty cycle
> value ,has a much easier time porting than code that communicates with
> the hardware directly each time one of these functions is needed,
> since the code that deals with the peripherals themselves is mostly
> what needs changing, and a modularized design means that such code
> needs only change in one place.
> Hope this helps?