GEAR: Propeller Debugging Environment
asterick
Posts: 158
Download Gear 1.11.0.0
Gear project page
It's a debugging environment for people that would like to have a step through debugger.
It is NOT intended to be a replacement for the board, as it is considerably slower (for the sake of accuracy)
The entire system is written in C#, I'm currently working on cross platform compatibility (.NET2.0 in mono is lacking)
Currently it has:
* Full support for the current parallax native instruction set, with accurate timing, and HUB 'ring' emulation.
* A tabbed, visual studio like (multiple emulation instances are allowable in one application), support splitting the view (stacking two windows on top of each other),
or 'floating' a new window so you can put it where ever you like (as seen with the wave form viewer in the screenshot)
* Support for loading C# scripts (not-compiled) to extend the system, and wire up additional emulated components (like EEPROMs, or a television if you feel industrious)
* Stepping per cycle
* Runtime disassembler for both interpreted code and assembly code
* Loads the spin IDE's native output (.eeprom and .binary both supported)
* Main memory viewer
* Interpreted emulation - Emulates all known instructions (see www.sublab.net/spin.html) except QUIT.
* Emulated Frequency generators
* An internal editor for the C# component scripts
* Full PLL emulation
* Video Generator Output
Currently working on / Will be added:
* Verify compatibility of the emulator
* Split off cog memory into it's own window
* Better highlighting of functions in the spin viewer (currently displays only the first instruction)
* Syntax highlighting in the plugin editor (with 4 space tabs, rather than 8)
Possibly to be added:
* Internal compiler (source debugging and cross platform support mostly)
* SPIN Editor
* .eeprom and .binary upload support
Current attached version: 1.11.0.0
This program requires .NET Runtime 2.0 (windows users, this is downloadable through Windows Update Manager)
Included is a self calibrating VGA monitor plugin (wired up to pins 16-23, ala the propeller board).
Post Edited (asterick) : 2/12/2007 4:45:33 PM GMT
Gear project page
It's a debugging environment for people that would like to have a step through debugger.
It is NOT intended to be a replacement for the board, as it is considerably slower (for the sake of accuracy)
The entire system is written in C#, I'm currently working on cross platform compatibility (.NET2.0 in mono is lacking)
Currently it has:
* Full support for the current parallax native instruction set, with accurate timing, and HUB 'ring' emulation.
* A tabbed, visual studio like (multiple emulation instances are allowable in one application), support splitting the view (stacking two windows on top of each other),
or 'floating' a new window so you can put it where ever you like (as seen with the wave form viewer in the screenshot)
* Support for loading C# scripts (not-compiled) to extend the system, and wire up additional emulated components (like EEPROMs, or a television if you feel industrious)
* Stepping per cycle
* Runtime disassembler for both interpreted code and assembly code
* Loads the spin IDE's native output (.eeprom and .binary both supported)
* Main memory viewer
* Interpreted emulation - Emulates all known instructions (see www.sublab.net/spin.html) except QUIT.
* Emulated Frequency generators
* An internal editor for the C# component scripts
* Full PLL emulation
* Video Generator Output
Currently working on / Will be added:
* Verify compatibility of the emulator
* Split off cog memory into it's own window
* Better highlighting of functions in the spin viewer (currently displays only the first instruction)
* Syntax highlighting in the plugin editor (with 4 space tabs, rather than 8)
Possibly to be added:
* Internal compiler (source debugging and cross platform support mostly)
* SPIN Editor
* .eeprom and .binary upload support
Current attached version: 1.11.0.0
This program requires .NET Runtime 2.0 (windows users, this is downloadable through Windows Update Manager)
Included is a self calibrating VGA monitor plugin (wired up to pins 16-23, ala the propeller board).
Post Edited (asterick) : 2/12/2007 4:45:33 PM GMT
Comments
You know I'd be the first to write a Sound-Output component. (lol)
I can't wait to play with this!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
Audio output might be a bit of a stretch, since it's not a 1:1 realworld : emulated ratio. You could do buffered audio playback, but not realtime. Like I said, it's mostly for external components like storage devices and such.
Maybe a .wav disk writer would be cool. I don't know. Maybe I'm jumping the gun. (lol)
EDIT: And as far as the speaker component goes, I would display a graphical representation of the waveform data, with playback on demand. It mainly comes down to whether the DAC stuff in the counters is easy to emulate; if I can get a series of electrical voltages the rest is easy.
Post Edited (Bergamot) : 1/11/2007 6:36:11 PM GMT
The main issue with having help right now is the disassociated nature of the internet, it would slow me down on working on other parts and stuff. Not to mention the interface is lible to change on a whim.
</rant>
Just as an update: Interpreted emulation now supports all ops between 0x40 - 0xFF (including the 'effect' codes)
Currently working on adding the last 64.
Currently, it doesn't do the unknown opcode, the QUIT instruction because I can't remember how I got the compiler to produce it, so I don't remember how it operates...
And it can't spawn other interpreted mode cogs (currently working on this)
Once I get the new interpreted mode cogs running, I'll release an alpha version for you all.
This is what I have to deal with
coginit( 1, blarg, 0 ) 24: 37 PUSH_PACKED_LIT 0 -> 2 26: 35 PUSH_0 27: 15 MARK_INTERPRETED 28: 36 PUSH_1 29: 3f MEMORY_OP MEM_F PUSH 2b: 37 PUSH_PACKED_LIT 61 -> -4 2d: d1 POP_INDEXED_MAINMEM_LONG 2e: 2c COGINIT cognew( blarg, 0 ) 2f: 37 PUSH_PACKED_LIT 0 -> 2 31: 35 PUSH_0 32: 15 MARK_INTERPRETED 33: 2c COGINIT coginit( 1, blarg2(2,3), 0 ) 34: 37 PUSH_PACKED_LIT 0 -> 2 36: 37 PUSH_PACKED_LIT 21 -> 3 38: 39 PUSH_WORD_LIT 515 3b: 35 PUSH_0 3c: 15 MARK_INTERPRETED 3d: 36 PUSH_1 3e: 3f MEMORY_OP MEM_F PUSH 40: 37 PUSH_PACKED_LIT 61 -> -4 42: d1 POP_INDEXED_MAINMEM_LONG 43: 2c COGINIT cognew( blarg2(2,3), 0 ) 44: 37 PUSH_PACKED_LIT 0 -> 2 46: 37 PUSH_PACKED_LIT 21 -> 3 48: 39 PUSH_WORD_LIT 515 4b: 35 PUSH_0 4c: 15 MARK_INTERPRETED 4d: 2c COGINITThe -4 write writes the cog ID to some weird memory location defined by an unmarked register (woo)... the 515 thing is the function number with an arguement count mask
Post Edited (asterick) : 1/12/2007 8:21:25 PM GMT
It's essentially a growing long queue. If the stack pointer ever drops below it's inital value, than the spin code reboots (the root function returned)
Note: If you construct bytecodes to pop values off the stack that were not there originally, you'll get erratic behavior.
cog init block
word ObjectMemoryPointer
word VariableMemoryPointer
word LocalMemoryPointer
word StackMemoryPointer
local memory base
long result
long arg0
...
long argN
long var0
...
long varN
Stack Memory
long value0
...
long valueN
Call Frame
long PreviousObjBlock
long PreviousVarBlock
long PreviousLocalBlock
long PreviousPC
long ReturnFlags (Bit0 = Drop Return, Bit1 = Traps Aborts)
Local Memory
Stack Memory
Call Frame
Local Memory
Stack Memory
etc.
So, essentially, the total ammount of memory used in bytes is: 4 + TotalVariables * 4 + TotalArguements * 4 + ActiveCalls * 20 + NumbersOnStack * 4
Post Edited (asterick) : 1/12/2007 8:06:48 PM GMT
PLEASE don't message me with bug reports, I know the thing likes to freak out.
It's more or less just a good faith release.
Thanks Buddy.
--Andrew Arsenault
I've dome major bug fixing on the interpreted core (which was beyond broken in the current version, and for that I apologize)
All the known opcodes work (except QUIT, which I STILL cannot recreate). Random will not produce the same values as seen
on the propeller chip, as I have no way of deducing how it actually works.
Forward random is a right rotate (1 bit) then XOR
Reverse random is a XOR then left rotate (1 bit)
This provides pseudo random behavior, and is reversible.
I've nearly finalized the plug-in system, and i've quazi-settled on this API:
namespace Gear.PluginSupport { public abstract class BusModule : UserControl { public virtual void PresentChip(Propeller host) { } public virtual void OnClock(double time) { } public virtual void OnPinChange(double time, PinState[noparse][[/noparse]] pins) { } public virtual void Repaint(bool force) { } } }PresentChip occurs once the plugin is loaded. It gives you a reference to the propeller chip (so you can drive the pins)
OnClock occurs once every cycle, time is the current emulated time (in seconds).
OnPinChange occurs every time a pin has changed states. PinState tells you if either the propeller or another component has set the pin Hi or Lo, or if the pin is floating
Repaint occurs when the GUI has finished executing a emulation 'frame' (variable number of clocks). force is always true (this means that the call wants to 'force' an update, this is provided so you can pass a false for non-forced repaints)
The propeller class is likely to change, so I'll describe it later.
I would like to point out that the emulator emulates all 64 possible pins (rather than the current cap of 32). All pins default as floating.
Note: Other components do not cause events to occur. Also, when a component changes a pin, that value is committed (no ORing or anything like that) So, no bus sharing.
The Propeller's output takes priority over the components (so, if DIR* is set HI, the pin state's will be set to the output of the PROPELLER)
The plugin system does not provide any limitations on the main namespace, so you should take into account that someone could write a malicious plugin to delete things. Policies would only complicate matters, and since they are required to provide their source, it is up to the user to verify that the plugin will not do harmful things to their PCs. There will be a method of binding assembly references to plugins (although this behavior will be ill-advised)
By default, the following references will be applied:
System.Windows.Forms.dll
System.dll
System.Data.dll
System.Drawing.dll
System.Xml.dll
Currently, I'm working on getting the frequency generators / video generators working. Once those are done, I'll release an updated version (no plugins yet, however)
I'll add syntax highlighting eventually.
words, not longs. So it's only 12 * activecalls + the rest of the stuff.
Mike
I was refering to my stack. The stack I use for the emulated interpreter is most likely much different than the one used in the actual propeller chip. I've actually modified it considerably in the most recent version.
Currently, this is what is happening with the emulator:
The power is out in 50000 residences throughout the town that I live in. One of those 50000 is my apartment. This also means that the latest sourcecode for my emulator is currently being held ransom until the electric company restores power to my section of the grid. I'm planning on taking my tower to work with me tommarow.
As far as my stack is concerned, from memory, this is what it looks like...
Where the termination code is, I store the initalization variables for the chip. This is 4 words, local, boot PC, var and object pointers. Following this is the arguements and local variables for the entry function (these are only zero on the FIRST reset of the processor). Followed by this is a LONG value used to store the ID used for interpreted mode COGINIT instructions. It defaults to -1, and the value is forced into -1 after every COGINIT (also cognew) instruction. This value will never be tampered with so long as proper stack usage is maintained (which is always the case if you are using the default SPIN compiler)
When you call a function, it pushes the Object, Local, variable, PC and a mask variable (marks if the function would like a return value, and if it traps aborts). These values are LONG values to maintain a long alignment.
I will probably pack 4 of those down to words once I can work on the sourcecode again. Long alignment is EXTREMELY important for certain aspects of the emulator (since it uses the stack to initalize other cog's boot parameters).
It may not be efficient, but it's probably close to how the native interpreter operates.
I would speak more, but I'm currently staying with family until power comes back on, and it's time to play RISK with them, or else they are going to break my legs.
I'll post more tommarow.
Post Edited (asterick) : 1/16/2007 5:26:27 AM GMT
There are 2 variables in the initalization data... the end of eeprom (points to the byte IMMEDIATELY after the FF FF F9 FF FF FF F9 FF pattern in the binary)... that is the local variable frame, where the return value / arguements / locals are stored for the FIRST function. After that is the stack.
I clobber the FF FF F9 FF stuff with 4 initalization words. In ascending byte address order: Object Base Pointer, Variable Base Pointer, Local Frame Pointer, and Stack Frame Pointer. The Boot Param stores PC in the upper 16 bits of the boot param, the lower word is the location of the first function's local frame pointer. (I know it's redundant, but I couldn't think of anything else to put in the 4 words), the boot function loads the Local frame -8 .. -2 words into the variables, and starts a chuggin'. After the local variables, is a buried variable used for coginit (located in the previous post). It's stuffed there because it's a thread safe pointer, and doesn't require me to manipulate any of the variables in the initalization data. After that comes additional call frames. Each call frame consists of 4 words and 1 long (Stored in ascending order: Object Frame Pointer, Variable Frame Pointer, Local Frame Pointer, Return PC, and the return style mask (traps and wants return value)) followed by local variables and more stack space, etc. The stack pointer is not preserved, since it's implied where it would be apon returning.
So, CURRENTLY, 1 interpreted cog takes 4 bytes * Total variables pushed + 4 * (Functions Called + Total Local arguements + Total Variables) + 12 * Functions Called + 8 bytes init data. This is smaller than my previous statement. This should be about as close as you can get to the built in interpreter without using voodoo.
And I'm sorry, but there isn't a nightly build, or recent release since the previous version available. I'm at a mid-version point, and once I get closer to something that is usable, I will make more frequent releases. The Frequency generators are extremely high up on my priority list, followed by the video generator. Everything else is there and working. I would also like to clean up the source code so I won't be embarassed when I open source it.
That is about the jist of it. The frequency generators shouldn't take me long to implement, since they are essentially just counters (sans PWM/NCO)
As a result of this sudden need to think about implementation, I went ahead and released a new version. This one should run interpreted code just dandy, and will at least be partially usable. I've also included a demo plugin if anyone feels resourceful. I've not documented it since the interface is likely to change very soon (you can thank PLLs for that one *grumble*)
Once I get PLLs figured out, video should be a breeze (sans the aural subcarrier, since I don't know how that is overlayed on an NTSC signal)
So long as you don't use freq modes 1-3, or waitvid, you should be kosher.
I am not sure·it's only me or someone else also has the same problem with your GEAR. When I run GEAR (from the 1.1.0.0 zip) to load a binary file (generated by Propeller IDE), I always get the error message below
"System.NullReferenceException - Object reference not set to an instance of an object"
Could you check it out what would be the problem?
I am using Windows XP SP2 Chinese Edition.
Thanks in advance.
Best regards,
Paul
If you could, could you attach your binary? I'll attach the latest mid version, in case I just messed up. This actually has a bug fix in the frequency generator (I was processing the mode wrong, so the generators were always disabled)
Also: Make sure you have .net 2.0. That might result in certain container classes from not getting initalized.
The only other thought I might have is that when I'm constructing the monospaced fonts, it's not returning anything (which would cause issues)
Post Edited (asterick) : 1/17/2007 5:09:33 PM GMT
Thanks for the new version of GEAR and the advice about .net 2.0
Unfortunately, I tried the new .net 2.0 and your new GEAR without lucks.
Attached are the SPIN files and Binary files. The first is the Example01_BlinkingOneLED.spin and binary. The second is test.spin (an empty file) and binary. They all failed iwth the same expection.
I think it may be caused by the Chinese Edition of Windows XP.
Anyway, appreciate your help.
Paul
That is the only thing I can imagine would change between the EU/US and Chinese XP releases.
I'm including another mid-version that will default to a default font if it cannot find a monospace, this will make the interface look terrible, but it will work.
Thanks for the mid-version. However, it still not works.
Paul
PLLs are in, and they drive pins.
NOTE: The emulated PLLs will accurately dejitter just about any frequency. if the input frequency drops below 320khz, the PLL shuts itself off.
The PLL will ONLY change frequency on the rising edge of the input NCO, or if it doesn't see a rising edge in a period of 320khz or sooner.
Since there are 17 potential clock sources running now, emulation is slower. More so than before. It's plenty fast for step through debugging, but it's a far cry from realtime now.
I'm going to work on binding the PLLs to the video generators of the cogs, I'm not sure how I'm going to do that since it's severely breaches cross encapsulation (due to aural subcarrier)
I may ignore broadcast modes, and only emulate VGA and baseband... since those are what most people use anyway.
Input on this would be severely appreciated.
I included support for Frequency Generator modes 1-3 (PLL), and VGA video generators.
There is the new SPIN memory viewer, but it's incomplete, and I'll work on it more as time progresses.
Composite is coming, I just need to figure out some of the minor details.
Using Non-perfect FrameClocks (PixelClocks *16 or *32) May have behavior that does not match the native propeller.
I don't claim this stuff is accurate, but it's close.
Post Edited (asterick) : 1/19/2007 7:07:23 AM GMT
con _xinfreq = 5_000_000 _clkmode = XTAL1 + PLL16X pub start DIRA := -1 OUTA := -1 repeat while true OUTA++Just wanted to show you all what I've been working on, things to look forward to in the next update.
Note: Red mean logic output (it's light blue for input)
I'm going to add a horizontal scroll bar so you can go back in time, and allow you to adjust the time scale and vertical grid line spacing
(right now, vertical lines are every 256 / 80,000,000 of a second (typically, 256 system cycles)... and the time scale is 1/10000 of a second)
I may eventually add things like merging pins to decimal / hex output view (unsigned and 2's complement) for things like video output levels and such.
It's more or less just a quick and dirty bug fix release, it should run slightly better. I included a vga monitor plugin that most likely doesn't work. It is self calibrating.
Also, the views are now back buffered, so they do not flicker (except when floated)