The "monitor" actually sounds nicer when Chip explains it now... It's more like a "serial command and control interface" than just a "monitor"...
I wonder, Can the "monitor" be used to implement the coveted "SD Loader", bootstrapping via a few logic gates or maybe jumpers between Prop II Pins to drive the T/R lines?
I wonder, Can the "monitor" be used to implement the coveted "SD Loader", bootstrapping via a few logic gates or maybe jumpers between Prop II Pins to drive the T/R lines?
I don't think you can load from SD using the monitor, but you could "squirt a little program into memory and launch it into a cog" to do it. I still don't understand why the ROM monitor is worth sacrificing hub RAM. Maybe it will be obvious once we get our hands on the chip. BTW, if basic development tools aren't ready the day the P2 starts shipping then I would think this would make potential customers think twice about Parallax. From what I can tell, the main reason for the ROM monitor is to talk to the chip without having the basic development tools. This seems like a really odd design choice since you won't need the monitor after the tools are available, but we'll never be able to recoup the lost RAM because of it.
I don't think you can load from SD using the monitor, but you could "squirt a little program into memory and launch it into a cog" to do it. I still don't understand why the ROM monitor is worth sacrificing hub RAM. Maybe it will be obvious once we get our hands on the chip. BTW, if basic development tools aren't ready the day the P2 starts shipping then I would think this would make potential customers think twice about Parallax. From what I can tell, the main reason for the ROM monitor is to talk to the chip without having the basic development tools. This seems like a really odd design choice since you won't need the monitor after the tools are available, but we'll never be able to recoup the lost RAM because of it.
I think that it actually would be useful and save space if you think about it. Let's say once got an application that uses two Prop II chips. One is the slave and the other is the master. You really wouldn't need to use another EEPROM or any kind of code preloaded on it because you can use the master prop to send commands to the monitor to help program the other prop.
@Sapieha
Thanks, that makes sense, but I thought since most of the spin code was the same maybe only a patch would be needed or something, not necessarily a rewrite. But your insight helps me understand a lot, so thanks!
I've been thinking about "encouraging development tools"
Perhaps Chip is thinking beyond the current C / SPIN, etc... tools we have today. If bootstrapping the chip is easy, which is the case with the monitor there, one doesn't need a whole lot to build with it. Serial + copy paste + some minimal storage. A mere P1 could be used to get started... This path does not require crypto be used at all, and in-fact prevents it!
Reading the post above carefully, a signed package is required for any kind of key access. Signature of 0 is required to enter that mode of operation. Going in through the monitor more or less hides that from the user, so it's safe, easy, consistent, lean, accessible. Seems to me, that's always a valid use case scenario. Any tool chain built that way more or less means the user can ignore the security keys entirely, treating it mostly like a P1 gets treated today.
Then there is the case of I/O expander. That's pretty much always a potential use case. Edit: I just saw Sonic cite the multi-prop use case. Seems reasonable there too.
Does this rom monitor affect the ability of the Prop II to communicate with existing tools such as propGCC or even the Spin tool IDE?
I don't think we know the answer to that question yet. I've tried to get a description of the new download protocol but haven't received a reply. Of course, Parallax will certainly make sure that their own tools work with P2 including PropGCC and their Spin tools.
Then there is the case of I/O expander. That's pretty much always a potential use case. Edit: I just saw Sonic cite the multi-prop use case. Seems reasonable there too.
Would it really be cost effective to use a P2 chip as an I/O expander or is this a red herring?
Which brings us back to accessibility... as Chip indicated.
Personally, I don't see the RAM as a big deal. Really, it's 2K, because the booter and such need to be there no matter what, due to where things ended up in the design path. When it's all told, there won't be a significant difference in how people use the chip, nor when they decide to go to the external RAM configuration.
And on that basis, I am a fan of Chip "going his own way" on this and many other Propeller design choices. The tech is accessible on a very basic level, and I personally think that's worth a lot. Can't wait to get a P2.
Which brings us back to accessibility... as Chip indicated.
Personally, I don't see the RAM as a big deal. Really, it's 2K, because the booter and such need to be there no matter what, due to where things ended up in the design path. When it's all told, there won't be a significant difference in how people use the chip, nor when they decide to go to the external RAM configuration.
And on that basis, I am a fan of Chip "going his own way" on this and many other Propeller design choices. The tech is accessible on a very basic level, and I personally think that's worth a lot. Can't wait to get a P2.
While I'm not a big fan of losing 2K of RAM for this feature, I'm also not interested in this issue slowing down the release of P2. I'm hoping that Parallax and Chip in particular are ignoring our suggestions here and concentrating on getting the P2 out the door! :-)
I do not believe Chip impacted the critical path. The synth work had some latency, which he used to develop the ROM.
It's time to ship it. Don't ship it broken, or wrong, or badly of course, but ship it. As things stand now, given what they've shared with us, it's a great chip! Time to play!
While I'm not a big fan of losing 2K of RAM for this feature, I'm also not interested in this issue slowing down the release of P2. I'm hoping that Parallax and Chip in particular are ignoring our suggestions here and concentrating on getting the P2 out the door! :-)
True but this isn't a bug. It's a feature trade-off that I happen to disagree with but that will not make the P2 useless. As others have said, losing 2K of RAM probably isn't going to be a make-or-break issue for anyone.
Yes, we don't want the P2 delayed because of the discussion here. Hopefully, Chip is ignoring the forum until P2 gets sent to the foundry. But, just in case -- Chip, I think the monitor is a great idea! Don't change a thing. I'm sure there will be many applications built around the monitor. The Forth guys are probably already writing a kernel that is based on the monitor.
In a much earlier incarnation of my business, I used the Z8671 in control applications, with multiple units in an RS422 network. The Z8671 was a Zilog Z8 with a BASIC interpreter/debug monitor in ROM. The monitor automatically ran on reset and checked first for an autostart program in EEPROM. If there was none, it entered immediate command mode, in which a person could either write and execute BASIC programs or execute single lines of BASIC code in immediate mode. My Z8 assembly programs always included ways (^C soft interrupt, ^T hard interrupt, ^R reset) to exit back to the ROM monitor for testing/debugging purposes. The monitor proved to be extremely valuable, in that I could query, test, and upload RAM-resident programs to remote units on the plant floor from the comfort of the control room, just by typing a sequence of BASIC commands. It was always there in ROM, so I didn't have to worry about it getting clobbered. Moreover, it contained adequate hooks to predefined RAM locations that its operation could be modified, which I took advantage of later with my own extensions to BASIC. Oh, and BTW, the entire BASIC/debug monitor required only 2K bytes of ROM.
I guess the point of this rambling is that a monitor program for the Prop2, if done with care, and possessing a rich enough command structure, could be a very valuable tool. We'll just have to wait and see what Chip came up with.
I guess the point of this rambling is that a monitor program for the Prop2, if done with care, and possessing a rich enough command structure, could be a very valuable tool. We'll just have to wait and see what Chip came up with.
-Phil
Didn't he publish the source in an earlier message in this thread? I think we already know what he came up with. :-)
True, if "we" refers only to those who actually read it.
For my part, I'm more or less just waiting for the dust to settle and see the final result. At this point in the game, trying to influence the design is pointless, and discussing "what ifs" is a waste of time.
... The Forth guys are probably already writing a kernel that is based on the monitor.
Ya, that's what I was thinking all along. It goes along with the idea of a self contained development environment. Maybe when the apocalypse comes forth will become the dominant computer language. I certainly won't care at that point
Ya, that's what I was thinking all along. It goes along with the idea of a self contained development environment. Maybe when the apocalypse comes forth will become the dominant computer language. I certainly won't care at that point
This is why I suggested a while back that a monitor be written in terms of a simple Forth interpreter. I guess Chip didn't like that idea.
Would it really be cost effective to use a P2 chip as an I/O expander or is this a red herring?
I think there are many slave applications, but they do sit above a "bucket of ''595" replacement.
Implicit here is I/O Expander above some minimal IQ...
To me, an I./O expander via Prop II would be more along the lines of a PSoC, CPLD or FPGA intelligent peripheral expander.
The idea is the code running in the Prop II is absolute minimal, and stable
- if you want Timers via registers, and Pin access, a ROM Loader+ stub would give that.
This is cheap, but fixes you to one link choice to host, and you are at register-mimic level coding.
So this is actually less plug-and-go than the steps below -- you can skip PASM, but do need to understand Prop Timers
Next step I can see is tiny local storage (i2c?), say 16kb, that allows a COG-sized intelligent peripheral
I see that being mainly via library blocks, (see Cypress) and that opens up Multiple UARTS / FIFO / Comms/ Multi Function timer/Counters,
with a choice of links to the host.
At this step, you do not need to know Prop II at the register level.
Final step is best value SPI, and there 36c/reel, gets you 1MByte, QuadSPI, and now your I/O expander can include up to display-drivers.
The monitor looks great. One big advantage I see is that it should work with just about any form of RF comms straight up (ascii text characters and a non-timing critical protocol).
More than anything I think it's a nice "human" touch by the designer - something you can converse with and meets you half way. A few of us have looked at loading AtTinys, PICs, PSoC's, FPGAs etc as slave peripheral devices to the Prop, but their native protocol tends to get in the way. Doing the equivalent with Prop2 (as a slave to anything) is going to be much easier thanks to this monitor.
I think anyone who gets a design to 124K full really would be doing themselves a favor by hooking up some extra external ram for future growth, as opposed to lamenting that lost 2k.
Means an existing Forth, running on anything, can be extended to a P2 pretty easy. A P1 right now could have a few words redefined to start employing a P2 with existing programs, driving the P2 directly through the monitor as it stands now.
A P1 right now could have a few words redefined to start employing a P2 with existing programs, driving the P2 directly through the monitor as it stands now.
Of course it would be possible to drive the P2 through the monitor. That wasn't what I was talking about though. I thought it would be better to have Forth in ROM instead of the monitor. A few Forth words could perform the functions that are defined in Chip's monitor while the programmable nature of Forth would allow the user to write his/her own programs. This is something that a simple monitor will be unable to do. I think having an interactive programming language in the ROM would be far more useful than just a handful of commands. Maybe something like that can be done in P3...
I agree with you in that being able to write programs would be great. Do you think that would have cost more or less RAM?
I would think it could have been done in about the same amount of space especially if Chip was writing the code. He has an unbelievable ability to sequeeze a lot out of hardly any memory!
The monitor looks great. One big advantage I see is that it should work with just about any form of RF comms straight up (ascii text characters and a non-timing critical protocol). .......
Yes I also see this as the big andvantage of the monitor.
But for that the ROM only needs to implement the Autobaud and some download protocol. XMODEM instead of a full monitor would need much lesser ROM space, and you can download the monitor then as a file from the Terminal first, before you use it. As an alternative to the monitor you can also download a Forth, a BASIC or a full development system from the Terminal via XMODEM. XMODEM protocol is already supported by most terminal software, and is really easy to implement.
Comments
I wonder, Can the "monitor" be used to implement the coveted "SD Loader", bootstrapping via a few logic gates or maybe jumpers between Prop II Pins to drive the T/R lines?
That is when is is back from fabrication and they start testing first silicon?
Also is there a number of years it has taken to develop this part?
cheers,
rich
As both of them need rewrite (existing ones are not code compatible) - so I don't see any problems.
But if I understand functions in monitor -- It will simplify write Yours own Loader.
I think that it actually would be useful and save space if you think about it. Let's say once got an application that uses two Prop II chips. One is the slave and the other is the master. You really wouldn't need to use another EEPROM or any kind of code preloaded on it because you can use the master prop to send commands to the monitor to help program the other prop.
@Sapieha
Thanks, that makes sense, but I thought since most of the spin code was the same maybe only a patch would be needed or something, not necessarily a rewrite. But your insight helps me understand a lot, so thanks!
Perhaps Chip is thinking beyond the current C / SPIN, etc... tools we have today. If bootstrapping the chip is easy, which is the case with the monitor there, one doesn't need a whole lot to build with it. Serial + copy paste + some minimal storage. A mere P1 could be used to get started... This path does not require crypto be used at all, and in-fact prevents it!
Reading the post above carefully, a signed package is required for any kind of key access. Signature of 0 is required to enter that mode of operation. Going in through the monitor more or less hides that from the user, so it's safe, easy, consistent, lean, accessible. Seems to me, that's always a valid use case scenario. Any tool chain built that way more or less means the user can ignore the security keys entirely, treating it mostly like a P1 gets treated today.
Then there is the case of I/O expander. That's pretty much always a potential use case. Edit: I just saw Sonic cite the multi-prop use case. Seems reasonable there too.
Personally, I do value the "forget it even has keys" use case highly.
Personally, I don't see the RAM as a big deal. Really, it's 2K, because the booter and such need to be there no matter what, due to where things ended up in the design path. When it's all told, there won't be a significant difference in how people use the chip, nor when they decide to go to the external RAM configuration.
And on that basis, I am a fan of Chip "going his own way" on this and many other Propeller design choices. The tech is accessible on a very basic level, and I personally think that's worth a lot. Can't wait to get a P2.
I do not believe Chip impacted the critical path. The synth work had some latency, which he used to develop the ROM.
It's time to ship it. Don't ship it broken, or wrong, or badly of course, but ship it. As things stand now, given what they've shared with us, it's a great chip! Time to play!
Better one month delay -- That have buggy IC.
I guess the point of this rambling is that a monitor program for the Prop2, if done with care, and possessing a rich enough command structure, could be a very valuable tool. We'll just have to wait and see what Chip came up with.
-Phil
Didn't he publish the source in an earlier message in this thread? I think we already know what he came up with. :-)
True, if "we" refers only to those who actually read it.
For my part, I'm more or less just waiting for the dust to settle and see the final result. At this point in the game, trying to influence the design is pointless, and discussing "what ifs" is a waste of time.
-Phil
Ya, that's what I was thinking all along. It goes along with the idea of a self contained development environment. Maybe when the apocalypse comes forth will become the dominant computer language. I certainly won't care at that point
I think there are many slave applications, but they do sit above a "bucket of ''595" replacement.
Implicit here is I/O Expander above some minimal IQ...
To me, an I./O expander via Prop II would be more along the lines of a PSoC, CPLD or FPGA intelligent peripheral expander.
The idea is the code running in the Prop II is absolute minimal, and stable
- if you want Timers via registers, and Pin access, a ROM Loader+ stub would give that.
This is cheap, but fixes you to one link choice to host, and you are at register-mimic level coding.
So this is actually less plug-and-go than the steps below -- you can skip PASM, but do need to understand Prop Timers
Next step I can see is tiny local storage (i2c?), say 16kb, that allows a COG-sized intelligent peripheral
I see that being mainly via library blocks, (see Cypress) and that opens up Multiple UARTS / FIFO / Comms/ Multi Function timer/Counters,
with a choice of links to the host.
At this step, you do not need to know Prop II at the register level.
Final step is best value SPI, and there 36c/reel, gets you 1MByte, QuadSPI, and now your I/O expander can include up to display-drivers.
More than anything I think it's a nice "human" touch by the designer - something you can converse with and meets you half way. A few of us have looked at loading AtTinys, PICs, PSoC's, FPGAs etc as slave peripheral devices to the Prop, but their native protocol tends to get in the way. Doing the equivalent with Prop2 (as a slave to anything) is going to be much easier thanks to this monitor.
I think anyone who gets a design to 124K full really would be doing themselves a favor by hooking up some extra external ram for future growth, as opposed to lamenting that lost 2k.
Good stuff Chip
cheers
tubular
A quick look at this: http://pygmy.utoh.org/3ins4th.html
Means an existing Forth, running on anything, can be extended to a P2 pretty easy. A P1 right now could have a few words redefined to start employing a P2 with existing programs, driving the P2 directly through the monitor as it stands now.
(Forth is very interesting, in this way.)
Yes I also see this as the big andvantage of the monitor.
But for that the ROM only needs to implement the Autobaud and some download protocol. XMODEM instead of a full monitor would need much lesser ROM space, and you can download the monitor then as a file from the Terminal first, before you use it. As an alternative to the monitor you can also download a Forth, a BASIC or a full development system from the Terminal via XMODEM. XMODEM protocol is already supported by most terminal software, and is really easy to implement.
Andy