Put the new random code in, works brilliantly, thanks Paul! (throw some thanks Chip's way too)
Increased the maximum number of samples per channel in the logic probe to 1024 instead of 256, so you can rewind further back in time.
I'm pretty sure I bug fixed something too since I last posted, I can't remember what it was though. >_>
I'm going to work on implementing a system for adding the DAC channels to the logic probe. Not sure how that's going to work though.
New version (1.6.0.0) has been posted, pretty small revision all things considered:
Implemented proper interpreted random output (thanks Paul and chip!)
Added analog channels to the logic view
Reduced inital pins in logic view to 32 (0 - 31) since those are the only ones anyone should be using anyway
Double clicking a channel in the logic view deletes it now
Added the ability to add digital channels (incase you deleted it)
Fixed CMPSUB, frequencys are properly calculated in TV based applications
Increased the number of samples allowed in the logic view from 256 to 1024
Added a good ammount of initial condition checking to the GUI (although there is something wrong if the events occur before the emulator is presented to a plugin)
Other little fixes here and there.
To add digital and analog channels, you need to put a comma seperated list in the box next to it, like "1,2,3"
+Digital would add 3 channels in the order provided.
+Analog would combine the pins provided to one analog channel, LSB first (weighted in powers of two)
asterick said...
Looking at your error trace, it has something to do with form components not getting initialized. The only thing I can think is that is the result of GDI+ not being up to date (IE: You are not running SP2)
Works now and look good. Nice work.
But when I push the '+Digital' button in the logic probe tab,
I get the warning 'Value has to be a valid number' an then the
window turns into a blank grid and doesn't show a trace anymore.
When I push the '+Analog' button, the same warning is shown and
afterwards the following exception occours:
System.NullReferenceException: Object reference not set to an instance of an object.
at Gear.GUI.LogicProbe.LogicAnalog.get_Name()
at Gear.GUI.LogicProbe.LogicView.Repaint(Boolean tick)
at Gear.GUI.Emulator.RepaintViews()
at Gear.GUI.Emulator.RunEmulatorStep(Object sender, EventArgs e)
at System.Windows.Forms.Timer.OnTick(EventArgs e)
at System.Windows.Forms.Timer.TimerNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Kloss said...
Works now and look good. Nice work.
But when I push the '+Digital' button in the logic probe tab,
I get the warning 'Value has to be a valid number' an then the
window turns into a blank grid and doesn't show a trace anymore.
When I push the '+Analog' button, the same warning is shown and
afterwards the following exception occours:
System.NullReferenceException: Object reference not set to an instance of an object.
at Gear.GUI.LogicProbe.LogicAnalog.get_Name()
at Gear.GUI.LogicProbe.LogicView.Repaint(Boolean tick)
at Gear.GUI.Emulator.RepaintViews()
at Gear.GUI.Emulator.RunEmulatorStep(Object sender, EventArgs e)
at System.Windows.Forms.Timer.OnTick(EventArgs e)
at System.Windows.Forms.Timer.TimerNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
cu Karl
There should be a text box next to the +Digital and +Analog buttons, you need to put a comma seperated list of pin numbers in there to get it to work. (Like 12,13,14 or 0,1,2,3)
It will be to the right.
The NullReferenceException is because it didn't have any pins. I'll fix that now.
Normally, I'm a stickler for null checks, but I get lazy with C#. I think it's becuase everything is usually preinitalized for me. I'll go over this Smile with a fine tooth comb eventually, but right now getting the interface closer to done is my top priority. I guess I should also add a TV component too, since who wants to actually use a VGA monitor? [noparse]:)[/noparse]
I compiled the example file (Ch3-Ex10)-Blinker2.spin and loaded it into Gear.
After starting it, it runs for a second and then Gear hangs completely, producing
100% system load.
I guess I should also add a TV component too, since who wants to actually use a VGA monitor? [noparse]:)[/noparse]
I like VGA. Mainly because I have a 640*480 VGA LCD with touch screen.
I'l make an interface and an object for the touch screen, so I can use it
as an ebook reader, or as a GUI for house automation.
But I think I'll build the CAN bus interface for the propeller first.
I'm more a hardware geek.
The machine frames the call to the object, then frames the indexing function, calls it, then calls the object. The problem there is that I use temporary values to store some indexes that get clobbered by the 2nd call frame. this results in the stack getting decimated, which results in the ReturnFromSub function getting stuck in a rather nasty loop. Needless to say, I'm going to work on fixing ReturnFromSub from ever getting to that point in the first place, and also work on the cummulative framing problem
I guess I should also add a TV component too, since who wants to actually use a VGA monitor? [noparse]:)[/noparse]
I like VGA. Mainly because I have a 640*480 VGA LCD with touch screen.
I'l make an interface and an object for the touch screen, so I can use it
as an ebook reader, or as a GUI for house automation.
But I think I'll build the CAN bus interface for the propeller first.
I'm more a hardware geek.
Neat. [noparse]:)[/noparse] I want to wire a propeller up to one of those sparkfun 128x128 OLEDs and make a handheld. I'm a tool for portables
It's fixed, and I went ahead and made it so the COGINIT boot frame is destroyed once the system starts up. This frees up 2 longs of stack memory, which is HUGE in certain cases (Kloss' example only provided >>9<< longs worth of stack to a child cog, which means that they would trash each other if I used up 2)
EDIT: I figured I would tell you that there is only 1 long used for cog variables, and that's the COGINIT ID. I would hide that value somewhere else, but there is no 'garunteed' free space in the memory map except maybe the end. I don't know if that's general purpose or not.
Ok, so this isn't an official release by any means, just a quick bug fix revision. I don't like anything that results in hardlocks.
This one is incapible of the ReturnFromSub loop, I resorted to using an internal stack to keep track of the call frame goodness (since there was no good way to sneek it into the interpreter stack) And as a side effect, it makes root function returns easier to monitor (the stack is empty if you try to return from the main function), and also includes the new fangled "improved" stack usage (8 extra bytes!)
It's on the first page, since I didn't want to risk people downloading the bad version.
I >>THINK<< I've added broadcast emulation. It's scary though (It uses 3 different PLLs, which is a bit extreme)
As it stands, what it does is uses the output from PLLB to enable / disable the output from the video generator at an extremely high frequency. This is not biased output (since there are only 3 bits of output) but the amplitude change is identical.
The aural pin works exactly the same way. PLL(aural) & PLLB
NOTE: Only one cog can hook a PLLA for aural output at a time. If another cog sets it's VCFG to the same aural PLL, the last one set gets the clock output from it.
If this is wrong, I'm sorry, just tell me and I'll fix it.
New version of gear (1.7.0.0) is release. Here is what is new:
Now you can add pin ranges in the text box (12..14 is the equilivent to 12,13,14)
Reduced stack usage for interpreted cogs
Fixed COGINIT/COGNEW for interpreted calls
Fixed nested function calls
Added broadcast emulation (possibly incorrect)
Changed the way PLLs work, allows for multiple aural hooks (since they are used now)
Here's what I did:
I started Gear 1.7.0.0. I opened the binary of the VGA_Demo.spin (the one from the 'Library' folder
of propeller tool 1.05.2). Then I opened the VGA plugin.
I clicked on 'Run'. The simulation ran, but no VGA output appeared.
Then I tried to close the loaded binary with the 'x' button and got the following exception:
************** Exception Text **************
System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'Icon'.
at System.Drawing.Icon.get_Handle()
at System.Drawing.Icon.get_Size()
at System.Drawing.Icon.ToBitmap()
at System.Windows.Forms.MdiControlStrip.GetTargetWindowIcon()
at System.Windows.Forms.MdiControlStrip..ctor(IWin32Window target)
at System.Windows.Forms.Form.UpdateMdiControlStrip(Boolean maximized)
at System.Windows.Forms.Form.WmSize(Message& m)
at System.Windows.Forms.Form.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Object name 'Icon'? Weird. There is something goofy with your system. [noparse]:)[/noparse]
I'll certainly look into it, but I don't think that is anything to do with me (it looks like that is something to do with microsoft's runtime, or the default settings for a MDI parent window)
Thanks to chip and his very informative info on the broadcast (which is severely incorrect), I'm currently working on retooling the PLL code so it's less spaghetti like to implement.
Currently, PLLs are p(expletive)ed by reference through the entire thing so the frequency handlers can properly adjust them, and the propeller knows the smallest execution step before something may change. I'm working on merging the 2 PLLs per cog into 1 mega module so the video generator pipes are less nasty, and working on making it so that the frequency generators are less offensive. There is only a little bit left to retool before it's what I would consider 'good'. While this system doesn't scale as well as the rest of my code, I don't think they will be increasing the number of PLLs per cog any time soon. I'm building it with the idea that parallax might increase elements later, like ram and cogs.
I'm desperately working on making the code more legible, and easier to understand so I can eventually open source this thing and not have to hide in a corner when people see how awful it looks.
Anyway... as it stands the broadcast code works, and modulates both the aural sub carrier and the broadcast video. It's scary, but it works. I don't really recommend anyone use it since it drives the PLLs are an insane rate, which results in a lot of load just to sync everything up.
I should also point out that the PLL emulation code is too accurate. Much more accurate than the Propeller's PLLs should or ever will be. I dumped out the duty counter / edge latching system since it wasn't stable enough, and resorted to having the frequency generators p(expletive) a divider any time you supply a FRQ* value, so that aspect of the emulator isn't very stable. I'm sure there is some function I could create that would allow it to simulate the jitter of various values, since only the top 3 bits of a FRQ are really garunteed to be jitter free... But this way at least people know that it's not their code, it's the hardware.
After this, I'll start working on processor compatibility, and resume work on the GUI.
EDIT: On a side note, I submitted a project description to sourceforge for approval.
Fixed a bug in the MIN/MAX/MINS/MAXS instructions. I was taking the minimum of the two values in MIN and the maximum value in MAX (which is backwards). It's repaired now.
My demoboard just came in as of like 5 minutes ago (Running your HSS demo right now YM)
This means I will be able to better understand certain things better hopefully very soon. Also as a side effect it also means that I'll probably be a little slow on the releases for awhile.
Fixed carry in addition \ subtraction operations (most of them at least)
Changed the VGA plug-in to be sensitive on sync edges.
First official open source release. (SVN is where the working source is kept)
Fixed HUBOP instruction (source and destination fields were switched)
Fixed PAR, now it's the 14 bit value passed, not the data stored at that address
Fixed jitter in the analog view
Comments
Increased the maximum number of samples per channel in the logic probe to 1024 instead of 256, so you can rewind further back in time.
I'm pretty sure I bug fixed something too since I last posted, I can't remember what it was though. >_>
I'm going to work on implementing a system for adding the DAC channels to the logic probe. Not sure how that's going to work though.
Implemented proper interpreted random output (thanks Paul and chip!)
Added analog channels to the logic view
Reduced inital pins in logic view to 32 (0 - 31) since those are the only ones anyone should be using anyway
Double clicking a channel in the logic view deletes it now
Added the ability to add digital channels (incase you deleted it)
Fixed CMPSUB, frequencys are properly calculated in TV based applications
Increased the number of samples allowed in the logic view from 256 to 1024
Added a good ammount of initial condition checking to the GUI (although there is something wrong if the events occur before the emulator is presented to a plugin)
Other little fixes here and there.
To add digital and analog channels, you need to put a comma seperated list in the box next to it, like "1,2,3"
+Digital would add 3 channels in the order provided.
+Analog would combine the pins provided to one analog channel, LSB first (weighted in powers of two)
SP2 of what? XP? I already have it.
SP2 of .net?
cu
Karl
But when I push the '+Digital' button in the logic probe tab,
I get the warning 'Value has to be a valid number' an then the
window turns into a blank grid and doesn't show a trace anymore.
When I push the '+Analog' button, the same warning is shown and
afterwards the following exception occours:
System.NullReferenceException: Object reference not set to an instance of an object.
at Gear.GUI.LogicProbe.LogicAnalog.get_Name()
at Gear.GUI.LogicProbe.LogicView.Repaint(Boolean tick)
at Gear.GUI.Emulator.RepaintViews()
at Gear.GUI.Emulator.RunEmulatorStep(Object sender, EventArgs e)
at System.Windows.Forms.Timer.OnTick(EventArgs e)
at System.Windows.Forms.Timer.TimerNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
cu Karl
There should be a text box next to the +Digital and +Analog buttons, you need to put a comma seperated list of pin numbers in there to get it to work. (Like 12,13,14 or 0,1,2,3)
It will be to the right.
The NullReferenceException is because it didn't have any pins. I'll fix that now.
Normally, I'm a stickler for null checks, but I get lazy with C#. I think it's becuase everything is usually preinitalized for me. I'll go over this Smile with a fine tooth comb eventually, but right now getting the interface closer to done is my top priority. I guess I should also add a TV component too, since who wants to actually use a VGA monitor? [noparse]:)[/noparse]
I compiled the example file (Ch3-Ex10)-Blinker2.spin and loaded it into Gear.
After starting it, it runs for a second and then Gear hangs completely, producing
100% system load.
Seems that you won't get bored again
I like VGA. Mainly because I have a 640*480 VGA LCD with touch screen.
I'l make an interface and an object for the touch screen, so I can use it
as an ebook reader, or as a GUI for house automation.
But I think I'll build the CAN bus interface for the propeller first.
I'm more a hardware geek.
Essentially, here is what the problem was.
Object[noparse][[/noparse]IndexingFunction].Call(...arguements...)
The machine frames the call to the object, then frames the indexing function, calls it, then calls the object. The problem there is that I use temporary values to store some indexes that get clobbered by the 2nd call frame. this results in the stack getting decimated, which results in the ReturnFromSub function getting stuck in a rather nasty loop. Needless to say, I'm going to work on fixing ReturnFromSub from ever getting to that point in the first place, and also work on the cummulative framing problem
Neat. [noparse]:)[/noparse] I want to wire a propeller up to one of those sparkfun 128x128 OLEDs and make a handheld. I'm a tool for portables
I was thinking the same thing when I saw them.
Just an update: At some point I botched COGINIT/COGNEW for interpreted cogs. I'm working on fixing it now, but it might be a bit.
EDIT: I figured I would tell you that there is only 1 long used for cog variables, and that's the COGINIT ID. I would hide that value somewhere else, but there is no 'garunteed' free space in the memory map except maybe the end. I don't know if that's general purpose or not.
Post Edited (asterick) : 1/25/2007 6:26:04 PM GMT
This one is incapible of the ReturnFromSub loop, I resorted to using an internal stack to keep track of the call frame goodness (since there was no good way to sneek it into the interpreter stack) And as a side effect, it makes root function returns easier to monitor (the stack is empty if you try to return from the main function), and also includes the new fangled "improved" stack usage (8 extra bytes!)
It's on the first page, since I didn't want to risk people downloading the bad version.
As it stands, what it does is uses the output from PLLB to enable / disable the output from the video generator at an extremely high frequency. This is not biased output (since there are only 3 bits of output) but the amplitude change is identical.
The aural pin works exactly the same way. PLL(aural) & PLLB
NOTE: Only one cog can hook a PLLA for aural output at a time. If another cog sets it's VCFG to the same aural PLL, the last one set gets the clock output from it.
If this is wrong, I'm sorry, just tell me and I'll fix it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Now you can add pin ranges in the text box (12..14 is the equilivent to 12,13,14)
Reduced stack usage for interpreted cogs
Fixed COGINIT/COGNEW for interpreted calls
Fixed nested function calls
Added broadcast emulation (possibly incorrect)
Changed the way PLLs work, allows for multiple aural hooks (since they are used now)
Here's what I did:
I started Gear 1.7.0.0. I opened the binary of the VGA_Demo.spin (the one from the 'Library' folder
of propeller tool 1.05.2). Then I opened the VGA plugin.
I clicked on 'Run'. The simulation ran, but no VGA output appeared.
Then I tried to close the loaded binary with the 'x' button and got the following exception:
************** Exception Text **************
System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'Icon'.
at System.Drawing.Icon.get_Handle()
at System.Drawing.Icon.get_Size()
at System.Drawing.Icon.ToBitmap()
at System.Windows.Forms.MdiControlStrip.GetTargetWindowIcon()
at System.Windows.Forms.MdiControlStrip..ctor(IWin32Window target)
at System.Windows.Forms.Form.UpdateMdiControlStrip(Boolean maximized)
at System.Windows.Forms.Form.WmSize(Message& m)
at System.Windows.Forms.Form.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
cu
Karl
I'll certainly look into it, but I don't think that is anything to do with me (it looks like that is something to do with microsoft's runtime, or the default settings for a MDI parent window)
Currently, PLLs are p(expletive)ed by reference through the entire thing so the frequency handlers can properly adjust them, and the propeller knows the smallest execution step before something may change. I'm working on merging the 2 PLLs per cog into 1 mega module so the video generator pipes are less nasty, and working on making it so that the frequency generators are less offensive. There is only a little bit left to retool before it's what I would consider 'good'. While this system doesn't scale as well as the rest of my code, I don't think they will be increasing the number of PLLs per cog any time soon. I'm building it with the idea that parallax might increase elements later, like ram and cogs.
I'm desperately working on making the code more legible, and easier to understand so I can eventually open source this thing and not have to hide in a corner when people see how awful it looks.
Anyway... as it stands the broadcast code works, and modulates both the aural sub carrier and the broadcast video. It's scary, but it works. I don't really recommend anyone use it since it drives the PLLs are an insane rate, which results in a lot of load just to sync everything up.
I should also point out that the PLL emulation code is too accurate. Much more accurate than the Propeller's PLLs should or ever will be. I dumped out the duty counter / edge latching system since it wasn't stable enough, and resorted to having the frequency generators p(expletive) a divider any time you supply a FRQ* value, so that aspect of the emulator isn't very stable. I'm sure there is some function I could create that would allow it to simulate the jitter of various values, since only the top 3 bits of a FRQ are really garunteed to be jitter free... But this way at least people know that it's not their code, it's the hardware.
After this, I'll start working on processor compatibility, and resume work on the GUI.
EDIT: On a side note, I submitted a project description to sourceforge for approval.
Post Edited (asterick) : 1/26/2007 5:04:03 PM GMT
Fixed MIN/MAX/MINS/MAXS instructions
Improved and Consolidated PLL code
General cleanups
Fixed broadcast video emulation
Now hosted on sourceforge. Working on getting the source cleaned up enough to post the source. Will be within the next 2 version.
Post Edited (asterick) : 1/26/2007 10:35:16 PM GMT
This means I will be able to better understand certain things better hopefully very soon. Also as a side effect it also means that I'll probably be a little slow on the releases for awhile.
Anyway... here is a screenshot as a teaser.
Fixed carry in addition \ subtraction operations (most of them at least)
Changed the VGA plug-in to be sensitive on sync edges.
First official open source release. (SVN is where the working source is kept)
That VGA plug-in looks sharp!
And I'm glad to hear someone in the world is listening to my music (lol) (j/k)
--Andrew Arsenault.
Fixed HUBOP instruction (source and destination fields were switched)
Fixed PAR, now it's the 14 bit value passed, not the data stored at that address
Fixed jitter in the analog view