K20

[bgamari]

Fix the IRQ vectors and rework the pin interface. @bharrisau do you remember where this vector table came from?

[farcaller]

The vector table looks completely different now, huh.

[bharrisau]

Vector table depends on which chip I was reading the data sheet from. It is
very device specific (along with the memory map).
On 21/10/2014 2:58 am, "Vladimir Pouzanov" [email protected] wrote:

The vector table looks completely different now, huh.

—
Reply to this email directly or view it on GitHub
#204 (comment).

[bgamari]

@bharrisau the vector table should be the same across the entire K20 family according to the family reference manual (document number K20P48M50SF0RM, Rev. 2)

[bgamari]

I think it would be a good idea to as a rule include provenance information in the source so that we can confirm we're working from the same documentation.

[bharrisau]

K20_72 has way more peripheral ISRs than the smaller iterations so it will
be different. Unless we are taking of different things?
On 21/10/2014 4:34 am, "Ben Gamari" [email protected] wrote:

I think it would be a good idea to as a rule include provenance
information in the source so that we can confirm we're working from the
same documentation.

—
Reply to this email directly or view it on GitHub
#204 (comment).

[bgamari]

I don't understand why MCU manufacturers must all have 37 different names for their products. What is K20_72?

[bgamari]

Alright, indeed I found another "K20 sub-family reference manual" that describes a different set of products with more peripherals (document number K20P120M100SF2RM). Where did you find the name K20_72?

[bgamari]

Ahh, these names are listed on Freescale's products page it seems (but are naturally no where to be seen in the technical documentation).

[bharrisau]

It is the frequency I think? But yeah, K20_72 is closer to K10_72 than
K20_50 (or whatever the cheapest speed grade is). Somewhat confusing.
On 21/10/2014 4:44 am, "Ben Gamari" [email protected] wrote:

Ahh, these names are listed on Freescale's products page
http://www.freescale.com/webapp/sps/site/taxonomy.jsp?code=K20_USB_MCU&cof=0&am=0
it seems (but are naturally no where to be seen in the technical
documentation).

—
Reply to this email directly or view it on GitHub
#204 (comment).

[bgamari]

@bharrisau how does the branch look now? Just need to find a way to set the cfgs.

[bharrisau]

From memory three things need to be abstracted from Zinc into a device
specific module. Vendor vectors, memory map and pins.

Actual peripheral drivers are pretty constant for a vendor, with some
slight complication due to optional features in a peripheral.

The ARM vectors, peripherals and memory map are the simplest, with optional
peripherals the only complication.
On 21/10/2014 4:55 am, "Ben Harris" [email protected] wrote:

It is the frequency I think? But yeah, K20_72 is closer to K10_72 than
K20_50 (or whatever the cheapest speed grade is). Somewhat confusing.
On 21/10/2014 4:44 am, "Ben Gamari" [email protected] wrote:

Ahh, these names are listed on Freescale's products page
http://www.freescale.com/webapp/sps/site/taxonomy.jsp?code=K20_USB_MCU&cof=0&am=0
it seems (but are naturally no where to be seen in the technical
documentation).

—
Reply to this email directly or view it on GitHub
#204 (comment).

[bharrisau]

Sorry, no review for a couple of days. Still in transit.

[bgamari]

Perhaps now would be a good time to address the peripheral definition problem.

[bharrisau]

Can we move these vector definitions out and have the end application import them? I haven't thought it all through, but it would hopefully avoid all the cfgs. It is on my todo as part of the move to cargo with the flexible target specs (which I'm running behind on completing).

[bgamari]

@bharrisau in my opinion I think it's reasonable to give the user as much support in this area as we can. Linker scripts are a hassle when starting a project and very easy to get things wrong. It seems to me that cfgs are nice in that they provide a uniform way to allow the user to easily specify their target. Moreover they are pretty low impact on the library side.