| Author |
Message |
BobTheDog
Joined: Feb 28, 2005
Posts: 4044
Location: England
Audio files: 32
G2 patch files: 15
|
 Posted: Wed Jul 02, 2008 8:58 am Post subject:
|
  |
|
Had a bit more of a look at the code, maybe we could do a joint venture on this.
I am up for the Rtem/C side of it, the DSP side would totally do my head in and may take months!
The main issue I see is sharing the host port with the code we are trying to debug. The way I have been working on this is that the coldfire sends an id first to select what is going to be changed on the dsp and then sends the data, and the same idea coming back.
Is this a valid way of doing it?
Cheers
Andy |
|
|
Back to top
|
|
 |
DrJustice
Joined: Sep 13, 2004
Posts: 2114
Location: Morokulien
Audio files: 4
|
| Posted: Wed Jul 02, 2008 3:16 pm Post subject:
|
|
|
Yes, there is the problem of sharing the host port with application traffic. If a breakpoint is fired in an interrupt, any ongoing host packets would have to be handled properly. Hand shaking on the host port using the host port flags can help with making the packets atomic, or at least signalling a debug-active state (that's what the debug.asm URL in a previous posting does).
Anyway, if you want a debugger running anytime soon, you should just hammer away since my capacity for Chameleon coding is rather low ATM. I'll follow the discussion if nothing else.
It's also worth considering that some simpler compiled in trace macros can go a long way too, if you just want to catch that pesky DMA interrupt for now... (easy if the debug session can have the host port to tself)...
DJ
-- |
|
|
Back to top
|
|
|
blue hell
Site Admin
Joined: Apr 03, 2004
Posts: 24083
Location: The Netherlands, Enschede
Audio files: 278
G2 patch files: 320
|
| Posted: Wed Jul 02, 2008 3:32 pm Post subject:
|
|
|
It looks like when you'd use something like this you could set up a communications protocol over the host port that would allow multiplexing of thwo independent data streams, one for debugging the other for control.
You'd have to write a PC application that connects to the real serial port and to two virtual ports, the debugger would connect to one virtual port and the usual communications would connect to the other virtual port. The PC application would wrap up stuff in packets to send it to the Chameleon and it would unwrap packages it receives from the Chameleon.
You'd also have to write a Chameleon application that takes over the serial port and implements it's own serial port API ... I'm not sure if this would be possible though.
_________________
Jan
also .. could someone please turn down the thermostat a bit.
 |
|
|
Back to top
|
|
|
DrJustice
Joined: Sep 13, 2004
Posts: 2114
Location: Morokulien
Audio files: 4
|
| Posted: Wed Jul 02, 2008 3:48 pm Post subject:
|
|
|
The Chameleon runs it's debug session against a Windows utility called Toolkit. The Toolkit is used to download code via the serial port, and in debug mode it displays a log that is written from the Chameleon host app. Unfortunately the sources for the Chameleon OS libraries are not available, so we're stuck with the debug output only (unless an input stream is implemented and undocumented).
As for the DSP side, supporting an interruptible packet stream with 'stream takeover' at breakpoint invocation requires a bit of fiddling, but it's doable.
DJ
-- |
|
|
Back to top
|
|
|
DrJustice
Joined: Sep 13, 2004
Posts: 2114
Location: Morokulien
Audio files: 4
|
| Posted: Wed Jul 02, 2008 4:34 pm Post subject:
|
|
|
Of course, the MIDI port is available for debugging with a PC based console...
DJ
-- |
|
|
Back to top
|
|
|
BobTheDog
Joined: Feb 28, 2005
Posts: 4044
Location: England
Audio files: 32
G2 patch files: 15
|
| Posted: Fri Jul 04, 2008 1:44 am Post subject:
|
|
|
| DrJustice wrote: |
As for the DSP side, supporting an interruptible packet stream with 'stream takeover' at breakpoint invocation requires a bit of fiddling, but it's doable.
DJ
-- |
Well in the end I decided to start from scratch and implement something like you mention (I think!).
I basically came to the conclusion that I have to create a host port system with the debugging support built in and then have all code use this system rather than trying to shoehorn it into the existing sample code.
Cheers
Andy |
|
|
Back to top
|
|
|
BobTheDog
Joined: Feb 28, 2005
Posts: 4044
Location: England
Audio files: 32
G2 patch files: 15
|
| Posted: Fri Jul 04, 2008 2:06 am Post subject:
|
|
|
| DrJustice wrote: | | BobTheDog wrote: | Aha, maybe its a viewpoint type of thing.
I was after a totally generic macro that could be used in any system by any programmers without any knowledge of the internals of the macros.
I already have it working using memory defined in the main memory map of the code but didn't like it as it was not fully contained in the macros.
Maybe I just need a shift in my perspective! Some comments at the top of the macro file detailing memory requirements and a label needed in the memory map maybe.
|
You can have that macro, it only needs support of a macro that allocates stack space (and whatever else you need). So making a small set of macros that provides monitor/debug facilities is one way.
In my mind these things are much simpler than what a C++ compiler does. You don't need to manipulate the stack explicitly in C, but you need to know how it works to program safely and efficiently.
DJ
-- |
Hi,
I worked it out in the end:
| Code: |
BreakpointAlloc macro
BreakpointMem:
ds 128
endm
|
And using it like this in the main asm:
| Code: |
;*******************************************************************************
org L:$000000
SampleMainInput:
ds 1 ; X:left, Y:right
SampleMainOutput:
ds 1 ; X:left, Y:right
InterruptStack:
ds 17
BreakpointAlloc
EndMemL:
|
Seems to work.
Andy |
|
|
Back to top
|
|
|
|
Forum index » Instruments and Equipment » Chameleon
FAQ
Calendar
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Chat Room
