XGATE

Official FreeEMS vanilla firmware development, the heart and soul of the system!
johnsop1
DIP8 - Involved
Posts: 26
Joined: Tue Jan 13, 2009 1:56 am

XGATE

Post by johnsop1 »

I have been spending some time learning about XGATE, and think that I understand how set up and use it.

It turns out that XGATE must run out of ram. The x12 must copy the XGATE code from flash to ram before the XGATE program can be run. This brings up the question, “Can we allocate a block for flash and and a block of ram for the XGATE program?”

The next question is “What should we use the XGATE for?” The thing that jumps to my mind is the decoder.

I am looking forward to questions and ideas.

Philip
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: XGATE

Post by Fred »

johnsop1 wrote:It turns out that XGATE must run out of ram. The x12 must copy the XGATE code from flash to ram before the XGATE program can be run.
Are you certain about that? Can you provide page/section references that state that? That is not what I understood to be the case.
This brings up the question, “Can we allocate a block for flash and and a block of ram for the XGATE program?”
I was hoping to only allocate whatever shared memory is required for it to communicate with the master program. We'll do what we have to though I guess.
The next question is “What should we use the XGATE for?” The thing that jumps to my mind is the decoder.
I thought the next question was "how do we compile ASM for it and integrate with the main code?" - but your next question is fine too :-)

I don't think decoding is the best use, rather I think Ignition bit banging is, and communications data pumping is. There is a reference document showing how to do the comms on it. I still think everything should be got working without it first though. I think that because of the overhead and complexity of integrating it and messing around with binary formats and compilers etc etc.

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!
User avatar
SleepyKeys
LQFP144 - On Top Of The Game
Posts: 549
Joined: Mon Feb 11, 2008 10:52 pm
Location: Arizona
Contact:

Re: XGATE

Post by SleepyKeys »

Anything coms or bit bang related would be sweet to run on xgate. Before we do that we should have a complete working system in C(at this point were still changing a lot of stuff), then after the dust settles optimize/trick it out to the MAX :twisted:
You snooze, you lose!
johnsop1
DIP8 - Involved
Posts: 26
Joined: Tue Jan 13, 2009 1:56 am

Re: XGATE

Post by johnsop1 »

This is from page 291 of MC9S12XDP512RMV2.pdf
The recommended initialization of the XGATE is as follows:
1. Clear the XGE bit to suppress any incoming service requests.
2. Make sure that no thread is running on the XGATE. This can be done in several ways:
a) Poll the XGCHID register until it reads $00. Also poll XGDBG and XGSWEIF to make sure
that the XGATE has not been stopped.
b) Enter Debug Mode by setting the XGDBG bit. Clear the XGCHID register. Clear the XGDBG
bit.
The recommended method is a).
3. Set the XGVBR register to the lowest address of the XGATE vector space.
4. Clear all Channel ID flags.
5. Copy XGATE vectors and code into the RAM.
6. Initialize the S12X_INT module.
7. Enable the XGATE by setting the XGE bit.


From AN3224.pdf
You may now be thinking, “Why not run the XGATE out of FLASH memory?” We must consider the
speed of access to different memory types. The RAM memory can respond to addressing of its memory
and deliver the data much more quickly than FLASH memory. FLASH accesses are unable to keep up with
the demands of an 80 MHz bus access, while the RAM and the MCU registers can handle this access
speed. Running the XGATE using code executing in FLASH rather than RAM would reduce the XGATE’s
performance by at least fifty percent. Furthermore, the CPU spends a lot of time accessing FLASH (but is
not held back by doing this as it runs at 40 MHz); however, the XGATE would be held back every time it
every time it had to access the FLASH memory. RAM is therefore a much preferred memory type to run
the XGATE code from.
Maybe XGATE will run from flash, but it seems it is faster running from ram.

You guys may be right. Lets get somthing running first and worry about XGATE later.
User avatar
SleepyKeys
LQFP144 - On Top Of The Game
Posts: 549
Joined: Mon Feb 11, 2008 10:52 pm
Location: Arizona
Contact:

Re: XGATE

Post by SleepyKeys »

"You guys may be right. Lets get something running first and worry about XGATE later."

Features like xgate can make it easy to forget that were already working with 2x the speed and 5x or so the resources of the c64, but pretty cool to think of what we can do though huh. Definitely not a dead end platform.
You snooze, you lose!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: XGATE

Post by Fred »

Thanks for the info Phil!

I guess reality is that the code we use on it will be small anyway. If I get a chance I'll take a look at how to split up the RAM for this purpose. I can happily move around any of the 8k of linear RAM for this. There is currently 3k free and will be 2k free once I get scheduling working (probably).

I'm happy to get it setup sooner than later because it's nice to know what we will and won't have resource wise. Also, the sooner it is setup the sooner people can play with it.

It sounds like the way to go might be to create an s19 from the perl builder and then translate that into an array of bytes to be linked in with the other stuff. Then we could just refer to it by pointer and known length and copy it up like anything else.

Thoughts?

Does the PERL program have some docs on integration?

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!
johnsop1
DIP8 - Involved
Posts: 26
Joined: Tue Jan 13, 2009 1:56 am

Re: XGATE

Post by johnsop1 »

I like the idea of using some external assembler or compiler and then translating the output to an array that we can put in the gcc code. I have found two ways to assemble code, The James binutils and the Perl assembler. I did manage to setup James binutils, call it from the makefile and build some xgate code.

The down side of these two tools is they are only assemblers. I am leaning toward using Cosmic's C compiler. It is a windows app, but will run under wine. Writing XGATE code in C is more in line with the goals of this project.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: XGATE

Post by Fred »

johnsop1 wrote:I like the idea of using some external assembler or compiler and then translating the output to an array that we can put in the gcc code.
Cool, I think it's a clean solution, though there may be others too.
I have found two ways to assemble code, The James binutils and the Perl assembler. I did manage to setup James binutils, call it from the makefile and build some xgate code.
Tell me, did it produce the same exact binary code as the PERL unit? If so, I wonder why he is calling it buggy? Or do you have an updated version?
The down side of these two tools is they are only assemblers. I am leaning toward using Cosmic's C compiler. It is a windows app, but will run under wine.
Provided the assembly is included we can have it as a file just like any other and therefore treat it as a library. I for one have no idea what is happening inside the couple of lib calls that we make. I do now know that memcpy clobbers registers it shouldn't though.
Writing XGATE code in C is more in line with the goals of this project.
While that is true, if we are optimising at all, we may as well go nuts. Having said that, careful C should be exactly the same as ASM. BTW, your checksum implementation was 20% smaller than mine ;-) I tried reverting to mine the other day when I had that issue and diffed the S19 files.

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!
johnsop1
DIP8 - Involved
Posts: 26
Joined: Tue Jan 13, 2009 1:56 am

Re: XGATE

Post by johnsop1 »

I used Cosmic's free eval compiler to compile Fred's commsISRs.c into XGATE code. It compiled into about 825 bytes. If there was a segment of ram assigned to run it out of (hint hint), I could see if runs.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: XGATE

Post by Fred »

I'll see what I can manage in the morning. No real excuse now that I have 2 gig of RAM.

I'm not sure how that will work. You might find that it doesn't work well with other ISR code doing stuff under it. I have kinda relied on ISR code being uninterruptable for concurrency stuff. Needs some thought anyway.

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!
Post Reply