This may not be compatible with FastSpin (which I don't use), but it does seem to work in standard Spin. My MS_001 constant is configured for 200MHz which I have standardized on.
To make it clear: I love interrupts, even if they can be seen to behave a little "insidiously", insisting on "infiltrating" wherever they can, whenever one is not expecting them to be even "admissible".
That said, perhaps there is another way to encapsulate such kind of code, without ever having to take care about any previous condition of interrupts (being enabled or not/occuring or not) and, at the same time, sparing one instruction:
pub get_ms() : ms | lo, hi
'' Return milliseconds after reset (32 bits).
'' -- system counter is fixed; cannot be changed by user
org
rep #5,#1 ' executes once; protects code block from being interrupted
getct hi wc ' get cnt (now)
getct lo
' stalli ' stall interrupts to protect cordic operation
setq hi ' divide cnt by ticks/ms
qdiv lo, ##MS_001
getqx ms
' allowi ' allow interrupts
end
That said, perhaps there is another way to encapsulate such kind of code, without ever having to take care about any previous condition of interrupts (being enabled or not/occuring or not) and, at the same time, sparing one instruction:
I was following what Chip does in the Spin interpreter for the getsec() instruction.
To make GETMS () work, I took the remainder from the GETSEC () division, did a QFRAC with CLKFREQ, multiplied that by 1000 and took the upper long of the product. This gives GETMS () the same lifespan as GETSEC (), which is $1_0000_0000 seconds, or 136.19 years. In that time, GETMS () will roll over 1,000 times before both GETSEC () and GETMS () will return $FFFF_FFFF and some other value, terminally.
Does that lose resolution of getms()? You want millisecond resolution for getms() so it should roll over much faster.
or are you saying that you have to do getsec() and then getms() after to get the ms portion? That sounds terribad also.
After computing seconds, which is the 64-bit counter divided by CLKFREQ, you have remainder between 0 and CLKFREQ-1. There is plenty of resolution to determine milliseconds from that remainder. And the milliseconds are always congruous to the seconds. I thought about many ways in which to compute milliseconds, and this was the only one that was practical.
This sounds good. So do we have both a GETMS() and a GETSEC() method now, is that how it works? I had thought you needed to replace GETSEC() to make GETMS() fit?
[
To make it clear: I love interrupts, even if they can be seen to behave a little "insidiously", insisting on "infiltrating" wherever they can, whenever one is not expecting them to be even "admissible".
That said, perhaps there is another way to encapsulate such kind of code, without ever having to take care about any previous condition of interrupts (being enabled or not/occuring or not) and, at the same time, sparing one instruction:
pub get_ms() : ms | lo, hi
'' Return milliseconds after reset (32 bits).
'' -- system counter is fixed; cannot be changed by user
org
rep #5,#1 ' executes once; protects code block from being interrupted
getct hi wc ' get cnt (now)
getct lo
' stalli ' stall interrupts to protect cordic operation
setq hi ' divide cnt by ticks/ms
qdiv lo, ##MS_001
getqx ms
' allowi ' allow interrupts
end
Hope it could help
Henrique
Excellent! Disabling Blocking interrupts with REP should go in the Tips & Tricks thread, wherever that is now.
This sounds good. So do we have both a GETMS() and a GETSEC() method now, is that how it works? I had thought you needed to replace GETSEC() to make GETMS() fit?
Yes, we have both. I hope to get a new version out in the next few days.
(I'm sorry if this is off topic... but I know that Chip reads this thread!)
@Chip
Do have a midi object that I can use? I saw your awesome presentation on audio processing with pitchbend, chourus and midi on YouTube. I don't want to reinvent the wheel if there is something I can just drop in and use out of the box.
(I'm sorry if this is off topic... but I know that Chip reads this thread!)
@Chip
Do have a midi object that I can use? I saw your awesome presentation on audio processing with pitchbend, chourus and midi on YouTube. I don't want to reinvent the wheel if there is something I can just drop in and use out of the box.
All I have is in the zip file at the top of this thread. To run DEBUG_MIDI, you'll need to get MIDI into the P2. I used this:
@Chip
Do have a midi object that I can use? I saw your awesome presentation on audio processing with pitchbend, chourus and midi on YouTube. I don't want to reinvent the wheel if there is something I can just drop in and use out of the box.
The DEBUG_MIDI program doesn't actually process the MIDI data; it simply captures the serial input from the MIDI device and passes it to the MIDI DEBUG window which handles the Note On and Note Off messages.
I am starting on a standard MIDI object. What features are you looking for? I'm trying to write an object that can accommodate all legal MIDI 1.0 messages, including the system level messages.
@Chip
Thanks.. I will look in the archive for any goodies!
@JonnyMac
Great to hear that you have started implementing a MIDI object, it will be plenty useful for many things I do. For now I will just use the basic features of the MIDI 1.0 standard. Note on/off, control change, patch change, ptich bend etc.
I got interested in anti-aliasing graphics for the DEBUG displays, because pixels are so coarse. I worked all night and made an anti-aliasing line-draw routine in Delphi. I need to fix it up so that it properly positions at 1/$10000 screen pixels for start and end points.
I was thinking about this yesterday, looking at various graphics packages I could use, but everything was overwrought. I finally just figured I could probably make it, myself. I need to add clipping to it, yet.
Looks very nice. But for the scope waveform I wonder if the anti aliasing would probably mask small steps, slow changes or dithering. I'd prefer seeing as many details as possible even if it doesn't look nice. For all other graphics like the hub/cog wheel it is definitively an improvement.
<Party pooper mode>These are not lab grade 'scopes, and quibbling over features is only delaying the release of Propeller Tool with DEBUG features integrated.</PPM>
Looks very nice. But for the scope waveform I wonder if the anti aliasing would probably mask small steps, slow changes or dithering. I'd prefer seeing as many details as possible even if it doesn't look nice. For all other graphics like the hub/cog wheel it is definitively an improvement.
I used to think this, too, but what it really does is increase the resolution by 256x.
I think what you are asking for is a mode where each sample is shown as a vertically-positioned horizontal line. We can do that better with anti-aliasing.
I was thinking about this yesterday, looking at various graphics packages I could use, but everything was overwrought. I finally just figured I could probably make it, myself. I need to add clipping to it, yet.
Take another look at OpenGL with GLFW. OpenGL has a lot of complications you can probably ignore since you aren't writing a game with fancy graphics.
This introduction looks like it might be good for you: https://en.wikibooks.org/wiki/OpenGL_Programming/Scientific_OpenGL_Tutorial_01. You'll probably be happier ignoring all the stuff there about GLUT and using GLFW instead, since GLUT forces you to use its own main loop while GLFW lets you have your own; you can find a GLFW example which draws a spinning colored triangle here, with an explanation here; start with this and replace the drawing stuff and shaders with the ones in the Scientific OpenGL tutorial.
There are Delphi bindings for GLFW and OpenGL here: https://github.com/neslib/DelphiGlfw. Don't use the old glNewList() calls their examples use; do it as in the Scientific OpenGL Tutorial with gl{Gen,Bind,Map}Buffer-type functions. You should be able to get OpenGL to directly process your plot data without having to convert it to some other format first - this is what I do in my plotting software.
I should be able to help you with this, since I have experience with drawing graphs in OpenGL. I hope I can publish my graphing software soon, together with some interesting Propeller examples.
Electrodude, thanks for the pointers. I will look into that after I get a few more things out of the way. I've almost got the anti-aliasing done, but I will need to get some other compiler work finished before I can get back into this graphic stuff, which is really fascinating.
Last week I had to sit for 5 hours, so I brought a clipboard with me and worked out how to do 2D anti-aliasing. I'm now drawing anti-aliased shapes faster than Windows' built-in routines can draw aliased shapes.
This is what PLOT output looks like now:
I found a way to do it that is very simple and deterministic. I want to make a PLOT animation to demonstrate the technique. A kindergartner could understand the principle, but it was the hardest thing I've worked out in a few years. If I hadn't been stuck sitting, I might not have gotten in done.
Now I'm working on a line-draw that has begin- and end-points in 256ths of a pixel. This is needed for the scope-type displays. I kind of had this working, at first, but it used whole pixel positions for start and end and the the endpoint pixels were messy. This new one is going to be as good as possible.
Is there any pseudo-official place yet that has a list of all the PASM learning resources in specific? I've seen several community members' troves and resources, but here is the reason for my question:
I'm learning PASM. It's fun! However, there many opcodes, register interactions and bitfield considerations to keep in mind. I'll get there, but like a lot of the community here, I know I'm particularly interested and particularly persistent.
Still, I know the docs and learning materials are not yet complete, and this is part of the work of releasing the P2 officially. I'm thinking we need to build a PASM programming guide somewhere, for P2 PASM specifically. Something that includes things like "different approaches to looping" and "emulating what PinWrite does" and maybe even a round description of each and every opcode. I'm just wondering where the best place is to help work on such a thing. I don't have bandwidth outside of my day job to take this on by myself, but I would certainly like to have it as a resource, use it, test it out, and help make it better with contributions. I suspect there are others here who would be interested in doing so. So, @cgracey Is this something that Parallax is wrangling in a dedicated internal effort, or is there something like this that we can iterate on as a community?
What is the best way for early adopters to help out?
If there isn't something like this, we might be able to stand up a git repo with something like gitbook for others to contribute to. Should we think of doing something like this, or should we hold our horses for a bit?
Twyyx, I agree that we need these learning resources. Not sure what to do about it, yet, myself. Just trying to get the tool done. I'm glad you are interested, anyway. If you have any ideas...
Comments
To make it clear: I love interrupts, even if they can be seen to behave a little "insidiously", insisting on "infiltrating" wherever they can, whenever one is not expecting them to be even "admissible".
That said, perhaps there is another way to encapsulate such kind of code, without ever having to take care about any previous condition of interrupts (being enabled or not/occuring or not) and, at the same time, sparing one instruction:
pub get_ms() : ms | lo, hi '' Return milliseconds after reset (32 bits). '' -- system counter is fixed; cannot be changed by user org rep #5,#1 ' executes once; protects code block from being interrupted getct hi wc ' get cnt (now) getct lo ' stalli ' stall interrupts to protect cordic operation setq hi ' divide cnt by ticks/ms qdiv lo, ##MS_001 getqx ms ' allowi ' allow interrupts endHope it could help
Henrique
or are you saying that you have to do getsec() and then getms() after to get the ms portion? That sounds terribad also.
After computing seconds, which is the 64-bit counter divided by CLKFREQ, you have remainder between 0 and CLKFREQ-1. There is plenty of resolution to determine milliseconds from that remainder. And the milliseconds are always congruous to the seconds. I thought about many ways in which to compute milliseconds, and this was the only one that was practical.
You just do a GETMS () instruction.
Excellent! Disabling Blocking interrupts with REP should go in the Tips & Tricks thread, wherever that is now.
Yes, we have both. I hope to get a new version out in the next few days.
I know that you know about it, but, in case someone just feels confused by
... and thanks TonyB, acknowledgeing your suggestion:
https://forums.parallax.com/discussion/comment/1507194/#Comment_1507194
@Chip
Do have a midi object that I can use? I saw your awesome presentation on audio processing with pitchbend, chourus and midi on YouTube. I don't want to reinvent the wheel if there is something I can just drop in and use out of the box.
All I have is in the zip file at the top of this thread. To run DEBUG_MIDI, you'll need to get MIDI into the P2. I used this:
http://ubld.it/products/midi-breakout-board/
The DEBUG_MIDI program doesn't actually process the MIDI data; it simply captures the serial input from the MIDI device and passes it to the MIDI DEBUG window which handles the Note On and Note Off messages.
I am starting on a standard MIDI object. What features are you looking for? I'm trying to write an object that can accommodate all legal MIDI 1.0 messages, including the system level messages.
Thanks.. I will look in the archive for any goodies!
@JonnyMac
Great to hear that you have started implementing a MIDI object, it will be plenty useful for many things I do. For now I will just use the basic features of the MIDI 1.0 standard. Note on/off, control change, patch change, ptich bend etc.
I was thinking about this yesterday, looking at various graphics packages I could use, but everything was overwrought. I finally just figured I could probably make it, myself. I need to add clipping to it, yet.
I used to think this, too, but what it really does is increase the resolution by 256x.
I think what you are asking for is a mode where each sample is shown as a vertically-positioned horizontal line. We can do that better with anti-aliasing.
Take another look at OpenGL with GLFW. OpenGL has a lot of complications you can probably ignore since you aren't writing a game with fancy graphics.
This introduction looks like it might be good for you: https://en.wikibooks.org/wiki/OpenGL_Programming/Scientific_OpenGL_Tutorial_01. You'll probably be happier ignoring all the stuff there about GLUT and using GLFW instead, since GLUT forces you to use its own main loop while GLFW lets you have your own; you can find a GLFW example which draws a spinning colored triangle here, with an explanation here; start with this and replace the drawing stuff and shaders with the ones in the Scientific OpenGL tutorial.
There are Delphi bindings for GLFW and OpenGL here: https://github.com/neslib/DelphiGlfw. Don't use the old glNewList() calls their examples use; do it as in the Scientific OpenGL Tutorial with gl{Gen,Bind,Map}Buffer-type functions. You should be able to get OpenGL to directly process your plot data without having to convert it to some other format first - this is what I do in my plotting software.
I should be able to help you with this, since I have experience with drawing graphs in OpenGL. I hope I can publish my graphing software soon, together with some interesting Propeller examples.
This is what PLOT output looks like now:
I found a way to do it that is very simple and deterministic. I want to make a PLOT animation to demonstrate the technique. A kindergartner could understand the principle, but it was the hardest thing I've worked out in a few years. If I hadn't been stuck sitting, I might not have gotten in done.
Now I'm working on a line-draw that has begin- and end-points in 256ths of a pixel. This is needed for the scope-type displays. I kind of had this working, at first, but it used whole pixel positions for start and end and the the endpoint pixels were messy. This new one is going to be as good as possible.
I'm learning PASM. It's fun! However, there many opcodes, register interactions and bitfield considerations to keep in mind. I'll get there, but like a lot of the community here, I know I'm particularly interested and particularly persistent.
Still, I know the docs and learning materials are not yet complete, and this is part of the work of releasing the P2 officially. I'm thinking we need to build a PASM programming guide somewhere, for P2 PASM specifically. Something that includes things like "different approaches to looping" and "emulating what PinWrite does" and maybe even a round description of each and every opcode. I'm just wondering where the best place is to help work on such a thing. I don't have bandwidth outside of my day job to take this on by myself, but I would certainly like to have it as a resource, use it, test it out, and help make it better with contributions. I suspect there are others here who would be interested in doing so. So, @cgracey Is this something that Parallax is wrangling in a dedicated internal effort, or is there something like this that we can iterate on as a community?
What is the best way for early adopters to help out?
If there isn't something like this, we might be able to stand up a git repo with something like gitbook for others to contribute to. Should we think of doing something like this, or should we hold our horses for a bit?