electro-music.com   Dedicated to experimental electro-acoustic
and electronic music
 
    Front Page  |  Articles  |  Radio
 |  Media  |  Forum  |  Wiki  |  Links  |  Store
Forum with support of Syndicator RSS
 FAQFAQ   CalendarCalendar   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   LinksLinks
 RegisterRegister   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in  Chat RoomChat Room 
Live streaming at radio.electro-music.com

  host / artist show at your time
  EdisonRex Edison's Electronic Review
Please visit the chat
 Forum index » Instruments and Equipment » Chameleon
DSP Stack Push
Post new topic   Reply to topic
Page 2 of 2 [32 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
Goto page: Previous 1, 2
Author Message
BobTheDog



Joined: Feb 28, 2005
Posts: 3880
Location: England
Audio files: 32
G2 patch files: 15

PostPosted: Wed Jul 02, 2008 8:58 am    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message
DrJustice



Joined: Sep 13, 2004
Posts: 2054
Location: Morokulien
Audio files: 3

PostPosted: Wed Jul 02, 2008 3:16 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message Visit poster's website
Blue Hell
Site Admin


Joined: Apr 03, 2004
Posts: 20736
Location: The Netherlands, Enschede
Audio files: 158
G2 patch files: 318

PostPosted: Wed Jul 02, 2008 3:32 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
Back to top
View user's profile Send private message Visit poster's website
DrJustice



Joined: Sep 13, 2004
Posts: 2054
Location: Morokulien
Audio files: 3

PostPosted: Wed Jul 02, 2008 3:48 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message Visit poster's website
DrJustice



Joined: Sep 13, 2004
Posts: 2054
Location: Morokulien
Audio files: 3

PostPosted: Wed Jul 02, 2008 4:34 pm    Post subject: Reply with quote  Mark this post and the followings unread

Of course, the MIDI port is available for debugging with a PC based console...

DJ
--
Back to top
View user's profile Send private message Visit poster's website
BobTheDog



Joined: Feb 28, 2005
Posts: 3880
Location: England
Audio files: 32
G2 patch files: 15

PostPosted: Fri Jul 04, 2008 1:44 am    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message
BobTheDog



Joined: Feb 28, 2005
Posts: 3880
Location: England
Audio files: 32
G2 patch files: 15

PostPosted: Fri Jul 04, 2008 2:06 am    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic
Page 2 of 2 [32 Posts]
View unread posts
View new posts in the last week
Goto page: Previous 1, 2
Mark the topic unread :: View previous topic :: View next topic
 Forum index » Instruments and Equipment » Chameleon
Jump to:  

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 vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum
e-m mkii

Please support our site. If you click through and buy from
our affiliate partners, we earn a small commission.


Forum with support of Syndicator RSS
Powered by phpBB © 2001, 2005 phpBB Group
Copyright © 2003 through 2009 by electro-music.com - Conditions Of Use