Page 1 of 2

Pin out research thread - comments

Posted: Sun Nov 23, 2008 11:01 pm
by Fred
Because its going to be a long thread and i've locked it to keep it contiguous... you may want to comment , hence this :-)

http://www.diyefi.org/forum/viewtopic.php?f=9&t=510

Fred.

Re: Pin out research thread - comments

Posted: Mon Nov 24, 2008 2:52 am
by jharvey
Fred wrote:Actually, there is nothing stopping Jared and Dave from decoding that into meaningful information!
You underestimate ignorance. So what are these blocks? I see 0ff, 1ff, 2ff, I'm assuming that the three pages of memeory, but I don't know what they are.

Re: Pin out research thread - comments

Posted: Mon Nov 24, 2008 7:02 am
by Fred
3 0x100 long blocks of memory. The memory range is listed at the beggenning of the blocks.

Registers on our device start at 0x0000 and extend to 0x0800, the port control stuff is the low end of that :-)

We'll get there. If you think you have better things to do, go ahead and do them. I'll get this done soon enough.

Fred.

Re: Pin out research thread - comments

Posted: Mon Nov 24, 2008 10:20 am
by jharvey
So you've written software that specifies ports, now your looking to see what the code generated. Shouldn't we decide what the port should be and do, then write software to make it so?

I can start manuallly decoding this, however I think it would be better to make some kind of a table or program that decodes it for us. I'm sure we will have changes, if we had a spread sheet that we cut and paste this into, then we could have the spread sheet decode it. That way it can be quickly confirmed on a per build bases.

I guess I'll start reading up more about the ports and how they map out, or more importantly see if we can port the PDF data into a data-sheet some how.

Re: Pin out research thread - comments

Posted: Mon Nov 24, 2008 10:25 am
by Fred
No, you've misunderstood. This is a dump of the register states from the serial monitor codes running state. I doubt it can be done automatically. We won't be doing it again (if it changes a diff with these will make light work of the changes anyway).

We need to understand what things are in what state and why to know what to connect where and how to set the standard state for them in our code. See the thread in freeems general about configurable IO for a refresher.

I've made some observations about how they appear to act, and the registers reflect this so far, but it could be for many reasons, and I'd like to know for sure before making the hard decisions you and Dave require.

Fred.

Re: Pin out research thread - comments

Posted: Mon Nov 24, 2008 11:13 am
by MotoFab
Fred wrote:We need to understand what things are in what state and why to know what to connect where and how to set the standard state for them in our code.
By "standard state" are you talking about something like the desired post power up initialized configuration? Including setting all the peripherals etc?

If so, it's a common embedded ruggedizing technique for that block of initialization code to be placed so that it gets looped through once per cycle. A process loosely called 'housekeeping'. Once initialized some items, often most of the pins, require no changes to their state. Other items and peripherals also fall into that category, and they too can be added to the once-per-loop housekeeping list.

Either way I'll follow along here and see if I understand how what you're asking for is done in C and in the 9S12XDP512.h file.

Optional novice question. A question about the sizes of the three blocks. Is the last line in block 1, starting with 00000100:, one line too many? If the question makes no sense, well we'll have to get used to that. I'm thinking the hex digits in the first part of each line represent an 'offset' added to the address range. So I can't figure out how it can get to 0x001

- Jim

Re: Pin out research thread - comments

Posted: Mon Nov 24, 2008 11:37 am
by Fred
MotoFab wrote:By "standard state" are you talking about something like the desired post power up initialized configuration? Including setting all the peripherals etc?
I mean the off state of each pin which for some pins may be high and others low depending on where they are with the serial monitors state. The circuit layout will affect this too as some of these are internally pulled to particular states rather than driven there.
If so, it's a common embedded ruggedizing technique for that block of initialization code to be placed so that it gets looped through once per cycle. A process loosely called 'housekeeping'. Once initialized some items, often most of the pins, require no changes to their state. Other items and peripherals also fall into that category, and they too can be added to the once-per-loop housekeeping list.
An interesting idea, but one that will only mask bugs IMO. I think if something gets out of place this needs to be obvious and quickly found and fixed.
Optional novice question. A question about the sizes of the three blocks. Is the last line in block 1, starting with 00000100:, one line too many?
Good spotting! Not sure why that is except that the 0000 line fits with reality, so it is almost certainly the trailing line that is funky.

Fred.

Re: Pin out research thread - comments

Posted: Mon Nov 24, 2008 6:38 pm
by jharvey
Some thoughts, we may do this once now for the basics, again for the next add-on with more features, and again for the second add-on. If we haven't got the add-on card connected and feeding the AN lines, I think we want to configure those IO's for high impeadance removing things like the MUX, SAR, and such from getting in the way of things. Leaving unused IO in a high impeadance state is better for many reasons.

Also other variants like TypeB might do it for specifc features for the variant, that might differ from the features planned in 1.0 w/ add-ons.

I think it sure would be nice to be able to dump the mem map out, and have a program tell you portA-1 is AN and portA-2 is high impeadance.

I think a program might be the best route, I've started looking over the data sheets and I'm trying to get a grasp of how the sheet data can be taken out and used in a program or a spread sheet to help idenfity how the ports are configured.

However, software isn't my strong point.

Re: Pin out research thread - comments

Posted: Mon Nov 24, 2008 9:02 pm
by Fred
Guys, relax, I had a long hard think abut this on the way home and had a few revelations. I'll do all the work and report back in a new thread about the basics of freeems hardware design. Relax for now.

Fred.

Re: Pin out research thread - comments

Posted: Mon Nov 24, 2008 9:23 pm
by Fred
MotoFab wrote:Optional novice question. A question about the sizes of the three blocks. Is the last line in block 1, starting with 00000100:, one line too many?
Fixed, thanks for pointing that out. It was just a trailing prompt sequence and the next block or something. I've trimmed it and checked it against a fresh dump.

Fred.