View unanswered posts | View active topics It is currently Tue Dec 11, 2018 9:02 am



Reply to topic  [ 18 posts ]  Go to page 1, 2  Next
Pin out research thread - comments 
Author Message
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15200
Location: Home sweet home!
Because its going to be a long thread and i've locked it to keep it contiguous... you may want to comment , hence this :-)

viewtopic.php?f=9&t=510

Fred.

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Sun Nov 23, 2008 11:01 pm
Profile WWW
1N4001 - Signed up
User avatar

Joined: Tue Jun 10, 2008 5:17 pm
Posts: 1607
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.


Mon Nov 24, 2008 2:52 am
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15200
Location: Home sweet home!
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.

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Mon Nov 24, 2008 7:02 am
Profile WWW
1N4001 - Signed up
User avatar

Joined: Tue Jun 10, 2008 5:17 pm
Posts: 1607
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.


Mon Nov 24, 2008 10:20 am
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15200
Location: Home sweet home!
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.

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Mon Nov 24, 2008 10:25 am
Profile WWW
1N4001 - Signed up

Joined: Thu May 29, 2008 1:23 am
Posts: 307
Location: Long Beach CA
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


Mon Nov 24, 2008 11:13 am
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15200
Location: Home sweet home!
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.

Quote:
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.

Quote:
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.

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Mon Nov 24, 2008 11:37 am
Profile WWW
1N4001 - Signed up
User avatar

Joined: Tue Jun 10, 2008 5:17 pm
Posts: 1607
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.


Mon Nov 24, 2008 6:38 pm
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15200
Location: Home sweet home!
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.

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Mon Nov 24, 2008 9:02 pm
Profile WWW
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15200
Location: Home sweet home!
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.

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Mon Nov 24, 2008 9:23 pm
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 18 posts ]  Go to page 1, 2  Next

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software for PTF. ColorizeIt.