Very interesting. One thing that we embedded "old-timer" keep forgetting is that there is no (need) for interrupt in the Propeller. A side effect is that it makes an emulator that emulates a true hardware device more practical as it doesn't have to deal with interrupts.
I will contact you shortly re: GEAR and our new C Propeller C compiler. Our native debug format for symbolic information is exceedingly easy to decode since it is in ASCII and very much C centric. Perhaps we can leverage the GEAR initiative in providing our customers with a debug environment.
// richard
It would not be in imagecraft's interests to lock out none users of their C complier from Gear if that were ever their intention. The SPIN/PASM user of today may be the C programmer of tommorow, keeping them onboard and happy would pay dividends.
QuattroRS4 said...
Will this mean Gear will not longer be free to the average punter ... as there is a $200 tag on the C compiler.
First of all, it will be GEAR's author's decision. I have not talked to them - yet. Will do so soon. GEAR's author obviously is doing GEAR for the love of the Propeller. If they do support our C compiler, may be they will charge for that portion, but the majority of the GEAR is still the same. I do not know whether GEAR's author intends to charge for GEAR eventually anyway and I don't see how our compiler would affect that.
Graham Stabler said...
It would not be in imagecraft's interests to lock out none users of their C complier from Gear if that were ever their intention. The SPIN/PASM user of today may be the C programmer of tommorow, keeping them onboard and happy would pay dividends.
Graham
Let it be on the record that I have no intention to lock out any one using asm/spin, or even working on other C compilers, or Basic, or whatever. We have lots of competitors in all our product line and my philosophy always is to create a compelling product and it will live or die based on its own merits. On the Propeller, I have begun talk with Bill Henning to see if we can leverage his work on the Large Memory Model, and the intention is to be fully compatible with his guidelines. If other languages or OS kernels were to use the guidelines, then so much better.
I really doubt Gear will go non-free, its on SourceForge and open source.
My talks with Richard are going very well, I believe we have an understanding - and frankly, he sounds like a great guy, and has committed to not breaking large model compatability and he plans to adhere to my guidelines for large model compilers and programs.
His attitide is refreshing compared to other software vendors I've worked with in the past, and I expect his products, and his participation, will be a welcome and useful addition to the Propeller community.
Best,
Bill
ImageCraft said...
Graham Stabler said...
It would not be in imagecraft's interests to lock out none users of their C complier from Gear if that were ever their intention. The SPIN/PASM user of today may be the C programmer of tommorow, keeping them onboard and happy would pay dividends.
Graham
Let it be on the record that I have no intention to lock out any one using asm/spin, or even working on other C compilers, or Basic, or whatever. We have lots of competitors in all our product line and my philosophy always is to create a compelling product and it will live or die based on its own merits. On the Propeller, I have begun talk with Bill Henning to see if we can leverage his work on the Large Memory Model, and the intention is to be fully compatible with his guidelines. If other languages or OS kernels were to use the guidelines, then so much better.
// richard
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com - a new blog about microcontrollers
Hi guys! After a VERY long absense... I am quazi-back. Here's a quick run down of what has happened to me over the course of the last few weeks
Sinus infection
5 day flu
multiple migrains.
My job is still keeping me extremely busy, and i've kicked out a few of my other neglected obligations, with more tragically waiting on my plate.
As far as implementing debugging help for the C compiler, it's a possibility if someone presented me with at the very least, a method of determining variables, stack frameing, source tabbing, and what not. I would love to allow for source level step through, but currently I don't have the data required to actually build the model.
And to answer the question of making gear a pay to use product, this will NEVER happen. It started first and foremost as a project for my learning, and evolved from there. I treat it as a tool for the education of others, not as a tool for my monetary gain.
Also, this program will at no point in the near future be 'real-time'. This is limitations of the .NET platform, not of my abilities. I designed it with the intention of it being accurate, not fast.
asterick - I just download Gear 1.11 today and ran it on Win2k (not the recommended XP) running on a Macbook under parallels. Everything worked great, and I am impressed with your work. I don't currently own any propeller boards, so now I need to decide if I should order online or wait for the ESC in San Jose and just live in Gear.
KeithE said...
asterick - I just download Gear 1.11 today and ran it on Win2k (not the recommended XP) running on a Macbook under parallels. Everything worked great, and I am impressed with your work. I don't currently own any propeller boards, so now I need to decide if I should order online or wait for the ESC in San Jose and just live in Gear.
Thanks for all of your hard work on this!
It's always the best policy to actually get the board itself. Gear still has some bugs with the spin interpreter, most of which I'm having problems locating. Those are the result of me making educated guesses on the inner workings of the interpreter from a reverse engineering session rather than having a nice parallax created document.
If something doesn't work in gear, it's not 100% positive that it won't work on the board.
asterick - are these problems with the interpreter because you can't include the revelent part of the ROM in your distribution? I'm very new to this part, and don't understand why the spin interpreter would present a special challenge if the binary for it were available to use. If it's a problem with distribution, then could you have the users get copies themselves? Sort of like what is done for Macintosh emulators, MAME, etcetera? Or maybe parallax would make more information available to you given the interest in this tool.
The problem lies in that Spin is an interpreted language. The code produces byte codes which correspond to dozens or hundreds of machine code instructions that are executed when that byte code is processed. What code the interpreter actually performs for each byte code is only a best-guess since Parallax does not release that information.
I saw in another thread (http://forums.parallax.com/forums/default.aspx?f=25&m=132607) that the boot loader and interpreter are encrypted/scrambled in ROM, so I guess this is why you have to interpret the bytecodes rather than just run the interpreter itself on the emulated processor. Maybe there are other reasons why this is a good idea like improved performance or being able to track the state of the interpreter at a high level?
What's a good reference for .NET for people that want to write plugins? Does your application code also look like the plugin code? I've never dealt with this, is it easy to get up to speed?
KeithE said...
I saw in another thread (http://forums.parallax.com/forums/default.aspx?f=25&m=132607) that the boot loader and interpreter are encrypted/scrambled in ROM, so I guess this is why you have to interpret the bytecodes rather than just run the interpreter itself on the emulated processor. Maybe there are other reasons why this is a good idea like improved performance or being able to track the state of the interpreter at a high level?
What's a good reference for .NET for people that want to write plugins? Does your application code also look like the plugin code? I've never dealt with this, is it easy to get up to speed?
-Keith
Essentially, any tab you see in the emulator window itself is a plugin, most of them are hardcoded into the application, but they are all built off the same base class. All the emulator does is uses object reflection and .NET's internal C# compiler to produce a runtime object. It's all very much voodoo. as far as a reference, there really isn't one. I would recommend just poking around with the provided plugins to get a general idea of how things work, and dink around with the source itself to see how things interface. I've not documented it mostly because I've not really settled on the interface for how I want things to work. the plugin base is pretty much where I want it to be, but as far as talking to the chip instead of just receiving events is kinda sketchy.
And I do not have access to the unencoded rom. I don't want access to it, and yes, the benefit of the emulator processing the bytecodes is speed and insystem debugging.
I tested Gear with the latest Mono (1.2) on linux. It worked. Some of the menus were a bit clunky and the screen refresh not perfect, especially the TV plugin, but it did work! (Gear 1.11.0, mono 1.2.3.1) Since I haven't bother trying it under windows, maybe thats kindof normal.
I also tried to build the source with MonoDevelop, but gave up on that, but I think that was just my lack of understanding of the tool in getting it to setup the project right.
For anyone who's using the Propeller, this is simply an amazing tool for getting answers to the quirks that appear in your code. The interface may be a little difficult because of the nature of the spin opcodes, but if you have the Propeller tool and Gear side-by-side then you can actually follow the code quite well.
I'm in the process of writing an interface to the ENC28J60 which is an SPI based Ethernet device. Gear has brought a massive boost to the debugging process - particularly the logic probe. (I must admit I was a little sceptical at first).
I did find that I wanted a couple of tweaks, so decided to have a look at the source code. This is my first bit of C# programming - coming from a Delphi background - so please go easy on me.
I've made primarily two changes:
1) Breakpoints may be set - 1 per cog. Click on a line where you want the breakpoint to occur. Click again to remove the breakpoint. Watch out! as when a breakpoint is triggered it may be on another cog.
2) The stepping in the native cog tries to keep the cursor in the middle section of the screen - as opposed to at the top line when using Follow PC mode. I've started looking at doing the same for the interpreted cog, but it's a bit more tricky, so thought I'd leave it til a little later.
I don't do SVN, but will look at getting the source code released into the main Gear development.
· repeat ··· !outa[noparse][[/noparse]13] ·
The code above will not show the expected result (A12 high, A13 toggling) It seems that setting a port in bit mode will affect other port states as well.
Err, yes. There was a little bug. How about a fix?
Anybody got an idea how to say the following using less words:
INDEXED_MEM_OP EFFECT OUTA POP BIT_CLEAR
This gives some idea of my idea of brief versus long opcodes, although at the moment it's very much mid-stream.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It's not all that hard to count the number of grains of sand on the beach. The hardest part is making a start - after that it just takes time.·· Mirror - 15 May 2007
I would request that the "Main Memory" view be searchable or at least selectable.
Even with out that feature though, the GEAR has enabled me to reproduce bugs in an environment conducive to debugging! Thank you, keep up the good work.
Gear has been a great tool for my very first project which involves 6 cogs all running assembly. Thanks very much for all the effort expended in creating it. I have one question and one suggestion.
Question: In every instance where I have used "CMP" in my assembly program it seems to be substituted with a "SUB". Is this intended? I realize a "SUB" can be used for comparison however when I try to compare what is going on in the Gear display vs. my program I keep tripping over the constant "CMP"->"SUB" substitution.
Suggestion: Would it be possible to manually change the value in a memory location in both COG and HUB memory. My application processes data sent via a serial port and it would be slick to be able to emulate this data by stopping execution, changing the value in memory, resume run or step mode.
Question: In every instance where I have used "CMP" in my assembly program it seems to be substituted with a "SUB". Is this intended? I realize a "SUB" can be used for comparison however when I try to compare what is going on in the Gear display vs. my program I keep tripping over the constant "CMP"->"SUB" substitution.
Several PASM instructions are the same save for the R flag.· So CMP = SUB NR, TEST = AND NR and·JMP = JMPRET NR.· (CALL and RET are also JMPRET under the covers.)
Question: In every instance where I have used "CMP" in my assembly program it seems to be substituted with a "SUB". Is this intended? I realize a "SUB" can be used for comparison however when I try to compare what is going on in the Gear display vs. my program I keep tripping over the constant "CMP"->"SUB" substitution.
Several PASM instructions are the same save for the R flag.· So CMP = SUB NR, TEST = AND NR and·JMP = JMPRET NR.· (CALL and RET are also JMPRET under the covers.)
GEAR is very nice·· I'm using it often now.· Today I found my first bug (in my code)·using it.· Great work so far.· Here are a couple suggestions that I think would make it even better.·
1) Ability to search Main Memory for specific bytes or byte sequences
- OR -
·Ability to copy main memory map to the clipboard·(so you can search it in another program)
2) Cog writes to Main Memory (via Byte[noparse][[/noparse]@variable] for instance) do not seem to update main memory, or I'm just not looking in the correct place.· It would be nice if the last main memory read/write were highlighted or something to make them easier to find.·
3) There should be some way to manually set the Ina port to high so they can be read by the cogs.· At this point they are always low (unless set in code),· so you cannot simulate external input.· In saying that I realize that you could just but some testing code in another cog for most operations, still it would be nice to be able to click a pin and set its state as if an external circuit was there.
I was wrong on point number 2) above, the main memory map is updating I just didn't understand the function of the PUSH_MAINMEM_BYTE operation. For those trying to figure this out, I found that it uses the last value on the stack as the main memory location to write to. That value is in decimal format, so it must be converted to Hex. The hex value is the memory loacation .
Comments
This is awesome, keep up the good work !!!·
*.*
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*.*
Ibsen
" It's nice to be important, but
·· more important to be nice... "
I will contact you shortly re: GEAR and our new C Propeller C compiler. Our native debug format for symbolic information is exceedingly easy to decode since it is in ASCII and very much C centric. Perhaps we can leverage the GEAR initiative in providing our customers with a debug environment.
// richard
Wow...That's an offer that should be accepted.
Rich
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Graham
First of all, it will be GEAR's author's decision. I have not talked to them - yet. Will do so soon. GEAR's author obviously is doing GEAR for the love of the Propeller. If they do support our C compiler, may be they will charge for that portion, but the majority of the GEAR is still the same. I do not know whether GEAR's author intends to charge for GEAR eventually anyway and I don't see how our compiler would affect that.
In other words, don't panic
// richard
Let it be on the record that I have no intention to lock out any one using asm/spin, or even working on other C compilers, or Basic, or whatever. We have lots of competitors in all our product line and my philosophy always is to create a compelling product and it will live or die based on its own merits. On the Propeller, I have begun talk with Bill Henning to see if we can leverage his work on the Large Memory Model, and the intention is to be fully compatible with his guidelines. If other languages or OS kernels were to use the guidelines, then so much better.
// richard
My talks with Richard are going very well, I believe we have an understanding - and frankly, he sounds like a great guy, and has committed to not breaking large model compatability and he plans to adhere to my guidelines for large model compilers and programs.
His attitide is refreshing compared to other software vendors I've worked with in the past, and I expect his products, and his participation, will be a welcome and useful addition to the Propeller community.
Best,
Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
Sinus infection
5 day flu
multiple migrains.
My job is still keeping me extremely busy, and i've kicked out a few of my other neglected obligations, with more tragically waiting on my plate.
As far as implementing debugging help for the C compiler, it's a possibility if someone presented me with at the very least, a method of determining variables, stack frameing, source tabbing, and what not. I would love to allow for source level step through, but currently I don't have the data required to actually build the model.
And to answer the question of making gear a pay to use product, this will NEVER happen. It started first and foremost as a project for my learning, and evolved from there. I treat it as a tool for the education of others, not as a tool for my monetary gain.
Also, this program will at no point in the near future be 'real-time'. This is limitations of the .NET platform, not of my abilities. I designed it with the intention of it being accurate, not fast.
Thanks for all of your hard work on this!
It's always the best policy to actually get the board itself. Gear still has some bugs with the spin interpreter, most of which I'm having problems locating. Those are the result of me making educated guesses on the inner workings of the interpreter from a reverse engineering session rather than having a nice parallax created document.
If something doesn't work in gear, it's not 100% positive that it won't work on the board.
-Martin
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
StampPlot - GUI and Plotting, and XBee Wireless Adapters
Southern Illinois University Carbondale, Electronic Systems Technologies
What's a good reference for .NET for people that want to write plugins? Does your application code also look like the plugin code? I've never dealt with this, is it easy to get up to speed?
-Keith
Essentially, any tab you see in the emulator window itself is a plugin, most of them are hardcoded into the application, but they are all built off the same base class. All the emulator does is uses object reflection and .NET's internal C# compiler to produce a runtime object. It's all very much voodoo. as far as a reference, there really isn't one. I would recommend just poking around with the provided plugins to get a general idea of how things work, and dink around with the source itself to see how things interface. I've not documented it mostly because I've not really settled on the interface for how I want things to work. the plugin base is pretty much where I want it to be, but as far as talking to the chip instead of just receiving events is kinda sketchy.
And I do not have access to the unencoded rom. I don't want access to it, and yes, the benefit of the emulator processing the bytecodes is speed and insystem debugging.
I also tried to build the source with MonoDevelop, but gave up on that, but I think that was just my lack of understanding of the tool in getting it to setup the project right.
For anyone who's using the Propeller, this is simply an amazing tool for getting answers to the quirks that appear in your code. The interface may be a little difficult because of the nature of the spin opcodes, but if you have the Propeller tool and Gear side-by-side then you can actually follow the code quite well.
I'm in the process of writing an interface to the ENC28J60 which is an SPI based Ethernet device. Gear has brought a massive boost to the debugging process - particularly the logic probe. (I must admit I was a little sceptical at first).
I did find that I wanted a couple of tweaks, so decided to have a look at the source code. This is my first bit of C# programming - coming from a Delphi background - so please go easy on me.
I've made primarily two changes:
1) Breakpoints may be set - 1 per cog. Click on a line where you want the breakpoint to occur. Click again to remove the breakpoint. Watch out! as when a breakpoint is triggered it may be on another cog.
2) The stepping in the native cog tries to keep the cursor in the middle section of the screen - as opposed to at the top line when using Follow PC mode. I've started looking at doing the same for the interpreted cog, but it's a bit more tricky, so thought I'd leave it til a little later.
I don't do SVN, but will look at getting the source code released into the main Gear development.
·· The GEAR is a great tool, and the scripting possibility is awsome! Congratulations!
· I have found a minor bug in the interpreter:
pub main
· dira[noparse][[/noparse]12..13]~~
· outa[noparse][[/noparse]12..13]~~·
· outa[noparse][[/noparse]12]~~·
· outa[noparse][[/noparse]13]~~
· waitcnt($10000)
···
· outa[noparse][[/noparse]12]~
· outa[noparse][[/noparse]12]~~
· repeat
··· !outa[noparse][[/noparse]13]
·
The code above will not show the expected result (A12 high, A13 toggling) It seems that setting a port in bit mode will affect other port states as well.
Regards,
· Attila
Anybody got an idea how to say the following using less words:
INDEXED_MEM_OP EFFECT OUTA POP BIT_CLEAR
This gives some idea of my idea of brief versus long opcodes, although at the moment it's very much mid-stream.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It's not all that hard to count the number of grains of sand on the beach. The hardest part is making a start - after that it just takes time.·· Mirror - 15 May 2007
I would request that the "Main Memory" view be searchable or at least selectable.
Even with out that feature though, the GEAR has enabled me to reproduce bugs in an environment conducive to debugging! Thank you, keep up the good work.
Question: In every instance where I have used "CMP" in my assembly program it seems to be substituted with a "SUB". Is this intended? I realize a "SUB" can be used for comparison however when I try to compare what is going on in the Gear display vs. my program I keep tripping over the constant "CMP"->"SUB" substitution.
Suggestion: Would it be possible to manually change the value in a memory location in both COG and HUB memory. My application processes data sent via a serial port and it would be slick to be able to emulate this data by stopping execution, changing the value in memory, resume run or step mode.
Again thanks for this great tool!
Craig
RDLONG = WRLONG NR
RDBYTE = WRBYTE NR
RDWORD = WRWORD NR
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
1) Ability to search Main Memory for specific bytes or byte sequences
·Ability to copy main memory map to the clipboard·(so you can search it in another program)
2) Cog writes to Main Memory (via Byte[noparse][[/noparse]@variable] for instance) do not seem to update main memory, or I'm just not looking in the correct place.· It would be nice if the last main memory read/write were highlighted or something to make them easier to find.·
3) There should be some way to manually set the Ina port to high so they can be read by the cogs.· At this point they are always low (unless set in code),· so you cannot simulate external input.· In saying that I realize that you could just but some testing code in another cog for most operations, still it would be nice to be able to click a pin and set its state as if an external circuit was there.