>Meh, leave this up to the second stage boot loader code, seems likes a waste of ROM to me...
But if SPI-flash is empty how are you gone get it to be a first stage boot loader? (and no FDI chip on board)
If you can boot from SD, why not have one more check for a number so it jumps to the same copy to spi-flash as the Rom's Serial boot routine have.
And putting LED(s) on CS lines does not add any code as you need to twiddle with these pins anyway.
Just add a delay before you copy code (led goes off) so you can release the button you are holding down to temp disable the working spi-flash.
Or rom code should try to communicate with Spi-flash and a released button will show a read success and then start writing, but timeouts after 5 seconds of tries.
A non working spi-flash (empty or corrupt) don't need you to temp override it.
>Meh, leave this up to the second stage boot loader code, seems likes a waste of ROM to me...
But if SPI-flash is empty how are you gone get it to be a first stage boot loader? (and no FDI chip on board)
If you can boot from SD, why not have one more check for a number so it jumps to the same copy to spi-flash as the Rom's Serial boot routine have.
And putting LED(s) on CS lines does not add any code as you need to twiddle with these pins anyway.
You are making my point for me. *IF* (big IF) you could boot from a removable media, your boot program on the media would copy the program to FLASH if the data in flash isn't the same. The ROM code doesn't need to be involved in this, and a bi-color LED for status is an end-user choice. I would also point out that LEDs can cause current drive problems when connected directly to logic lines that are shared. I had a problem with an LED pulling down the logic line on the FTDI chip and browning out the Propeller, so I installed a larger resistor.
Since the ROM is composed of hardcoded RAM bits it might be more useful to leave the remaining space as RAM.
I had some similar thoughts. Though I figured it would be better to use the whole COG space if you could. An extra 512 bytes of memory may not be as useful as additional features in the ROM. I don't think the ROM should grow larger than 2KB unless it was tucked into some leftover nook in the chip.
>your boot program on the media would copy the program to FLASH if the data in flash isn't the same
But then you would have to pad your code with this routine, with prop1 you don't have to pad your code with its serial programming as copy-to-eeprom is in ROM.
It would add two longs to the SD boot routine, so it behaves the same way the prop1 does it's eeprom programming.
Why not have it so you can grab any demo code from obex , compile it and have prop tool save it to SD card.
Sure it could be an option in prop-tool to add the padded code that do the re-transfer to SPI-Flash.
@Chip: Agreed on validation. That's the upside of having the extra layer of complexity for sure. "hate" is too strong of word. Really, for my own stuff, it's not a worry. For the greater community, the option is needed big. Bottom line is I probably will make at least one P-Brick. LOL!!
Re: Forth.
I'm not serious about it at all, particularly if it wouldn't fit into the space we have. I have dabbled with Forth now and totally get why people would want it in there. Wouldn't take much to fire up a prop and send a whole environment to the thing. Of course, a nice monitor is the next best thing, and probably the much better thing.
Enter monitor, then send Forth, run it, send the dictionary desired, and carry on from there, the advantage being one can pick their Forth too. Bootstrapping a minimal setup, or new board would be trivial for anyone who has developed even moderate Forth skill. That's all pretty compelling to me on a lot of levels honestly. It's a lean path. There are lots of other paths and they are great, necessary. Don't get me wrong there. Not about that, or which is better, just baseline options.
If pressed on it, I really would like the monitor, and a good one would fit too.
I've been thinking about the auto-baud-detection problem and I think I came up with a solution:
<enter> / $0D would be the best value to auto-baud from because people will naturally hit the <enter> key initially and often.
Here it is serialized: 1..0_10110000_1..1
This could be detected by measuring incoming low and high times on RX into a circular buffer and looking for the following pattern:
1 for >8x clocks to ensure registration (dead time before $0D, could be generated by $FF)
0 for x clocks (start bit)
1 for x clocks (data bit 0)
0 for x clocks (data bit 1)
1 for 2x clocks (data bits 2 and 3)
0 for 4x clocks (data bits 4 through 7)
You would have to allow for maybe 1/4x slop in your detector, but once that pattern came in, you would know that you just got an $0D and you would be able to set the bit period (baud rate) right then. The detector would always be running as a task that would get switched to frequently. Any time a set of pulses came in that met the criteria, the baud rate would be set anew. The CTR now has mechanisms for measuring pulses, so it wouldn't require high-bandwidth task switching to pick up the values from it. At ~20MHz internal RC frequency and 115.2k baud, you would have 20M/115.2k = ~173 clocks per bit, or 0.576% error, not considering incoming jitter.
Enter monitor, then send Forth, run it, send the dictionary desired, and carry on from there, the advantage being one can pick their Forth too.
Yeah, I guess if you have a serial connection to the P2 then you probably also have the ability to squirt the full interactive language of your choice (maybe Forth or even Basic) into the chip using just a simple monitor "write long" command.
Maybe we could reuse two boot pins to drive a bi-color LED for boot signalling.
Sounds a good idea, but remember a common use will be a large QuadSPI Flash, with Font Tables.
- so an LED will also be active/flickering during user runtime.
Not a huge issue, as it will be a Board status led.
A bi-Colour LED could go on the /HOLD /WE pins, so a 1-bit SPI user would have independent LED control,
or a Uni-Colour LED could be active on CS=H, and any of D1.2.3 == !LED when SPI is de-selected.
Here, if a Font user wanted better LED info, they would code their SPI driver to update Dn with LED info on CS=H.
It would dim slightly on Font fetch.
Checking some more, I see the spec point for IOL on SPI parts is quite low, 1mA for Microchip, 1.6mA for Winbond.
Maybe then CS and CLK, as they are Prop-control pins, and the LED has no load-impact on light pullups, or assumes any drive ability of Loader Chip ? CLK needs to be defined when CS goes low, but outside that setup time, it can move when CS is hi.
I also see that Microchip support only SPI Mode 0, whilst Winbond & SST support both Mode 0 and Mode 3.
So that means a SPI ROM loader should be a Mode 0 loader.
I've been thinking about the auto-baud-detection problem and I think I came up with a solution:
<enter> / $0D would be the best value to auto-baud from because people will naturally hit the <enter> key initially and often.
Here it is serialized: 1..0_10110000_1..1
This could be detected by measuring incoming low and high times on RX into a circular buffer and looking for the following pattern:
1 for >8x clocks to ensure registration (dead time before $0D, could be generated by $FF)
0 for x clocks (start bit)
1 for x clocks (data bit 0)
0 for x clocks (data bit 1)
1 for 2x clocks (data bits 2 and 3)
0 for 4x clocks (data bits 4 through 7)
You would have to allow for maybe 1/4x slop in your detector, but once that pattern came in, you would know that you just got an $0D and you would be able to set the bit period (baud rate) right then. The detector would always be running as a task that would get switched to frequently. Any time a set of pulses came in that met the criteria, the baud rate would be set anew. The CTR now has mechanisms for measuring pulses, so it wouldn't require high-bandwidth task switching to pick up the values from it. At ~20MHz internal RC frequency and 115.2k baud, you would have 20M/115.2k = ~173 clocks per bit, or 0.576% error, not considering incoming jitter.
Does anyone see any weakness in this?
It does not need to be that complex - as long as you have a single bit low and/or a single bit hi, you can measure the smallest-value, in a Get-Time-Between-Edges capture system, and you are done.
Your example of 1..0_10110000_1..1 meets this single bit requirement twice.
You may be able to use the new capture feature in timers, to drop the code size of this ?
If you wanted to add some noise immunity, you could add a count/vote to the Smallest value check. Char above gives 2, or use 'U' and get 8 results in your smallest value bin.
Requiring consecutive narrow-low and narrow-hi and > (eg) 1us, would be a simple way to remove single event miss-fires.
What is the point of having a monitor in ROM? Either:
a) it goes through booting, fails, and loads the monitor. To do what? there's nothing to monitor
b) it manages to load some code, somehow, and the monitor is enabled. Why not just include it in RAM then? You don't have to argue about features (Forth, etc.). Just use what you want. And it will still take up a cog...
If you want it so that you can start with a bare chip why not just use the RX/TX protocol to load in a program?
As for ROM vs. RAM: 1 ROM bit is something like 1 transistor, while 1 RAM bit is 6 IIRC. So assuming ROM and RAM are tradeable, then you get 6x the amount of memory in ROM vs RAM.
It does not need to be that complex - as long as you have a single bit low and/or a single bit hi, you can measure the smallest-value, in a Get-Time-Between-Edges capture system, and you are done.
Your example of 1..0_10110000_1..1 meets this single bit requirement twice.
But what if the clock rate goes up and down? It won't adapt if it's always looking for an ever-shorter 0/1, right?
As for ROM vs. RAM: 1 ROM bit is something like 1 transistor, while 1 RAM bit is 6 IIRC. So assuming ROM and RAM are tradeable, then you get 6x the amount of memory in ROM vs RAM.
That would be true if the ROM was built from ROM cells. However, I think in this case the ROM is actually built from hard-wired RAM cells.
What is the point of having a monitor in ROM? Either:
a) it goes through booting, fails, and loads the monitor. To do what? there's nothing to monitor
b) it manages to load some code, somehow, and the monitor is enabled. Why not just include it in RAM then? You don't have to argue about features (Forth, etc.). Just use what you want. And it will still take up a cog...
If you want it so that you can start with a bare chip why not just use the RX/TX protocol to load in a program?
As for ROM vs. RAM: 1 ROM bit is something like 1 transistor, while 1 RAM bit is 6 IIRC. So assuming ROM and RAM are tradeable, then you get 6x the amount of memory in ROM vs RAM.
It would just be a very simple and friendly thing that would enable people to ease into the chip without any tools. It would also enable simple tool building. It would lower the threshold way down for what it takes to make the chip do something. A serial terminal is all you'd need. You could paste in multi-line commands and run programs that way. It's something for when we all get old.
When we place ROM bits into hub memory, it's true that they are only 1 transistor, but they snap in the place of what was meant for a 6-transistor SRAM cell.
A complete boot strap is possible from any other hardware platform, including just a terminal. Type it all in, if you want.
Chip got there first. LOL: "When we all get old." So true!
I was actually thinking of those "Learning PASM" threads we've had. A monitor is a nice tool to have for those basic, low level concepts. Of course, one could be written, and should for P1, and maybe it should for P2 as well, but since there are those bytes sitting around....
Well, stuff that gets built gets old too. I've had to use a monitor on several devices to get something up and running to get data and such in the past, or to do diagnostics. It's not a bad option to have.
Would anyone have any opposition to putting the ROM at the BOTTOM of memory, so that it builds up from $00000?
This way, there's no ugly caveat at the end of memory which would inhibit one from allocating a huge top-justified block of RAM. I think this would lead to more efficient use of RAM. Also, RAM could begin right away after the bare necessities of ROM code, never minding any 2k rule.
Also, since immediate-address RDxxxx/WRxxxx would be pointless because of ROM, all immediate S values could be pointers, giving us one more bit of scaled offset, so instead of -16..+15 offsets, we could express -32..+31 offsets.
Now, if your monitor could provide commands for setting pin direction and reading/writing pins the Prop II would make a great I/O expander without having to write a line of code for it:)
There is a lot of merit in that suggestion - smart IO and good pin control is valuable.
No added parts/no user code has appeal.
Such a scheme would need full control register access, and ideally access to all timers.
The same tiny code could clone into all slave COGs.
Challenge is making such a mode 'safely tucked into a corner', so perhaps one more Pin-Value test after 'no boot devices found' ?
It also needs to be as fast as possible, as an I/O expander this smart, can swallow a lot of data.
That give place for more ROM -- And as You said no ugly caveat at the end of memory
As ROM needs only in BOOT sequence I don't think that give any problems
NOT only RAM -- BUT even ROM --- As I think it simplify addressing of them
Would anyone have any opposition to putting the ROM at the BOTTOM of memory, so that it builds up from $00000?
This way, there's no ugly caveat at the end of memory which would inhibit one from allocating a huge top-justified block of RAM. I think this would lead to more efficient use of RAM. Also, RAM could begin right away after the bare necessities of ROM code, never minding any 2k rule.
There is a lot of merit in that suggestion - smart IO and good pin control is valuable.
No added parts/no user code has appeal.
Such a scheme would need full control register access, and ideally access to all timers.
The same tiny code could clone into all slave COGs.
Challenge is making such a mode 'safely tucked into a corner', so perhaps one more Pin-Value test after 'no boot devices found' ?
It also needs to be as fast as possible, as an I/O expander this smart, can swallow a lot of data.
Q: Did a SPI Slave capability make the cut ?
I agree about the I/O expander, but it's hard to nail down what all it should do. It quickly starts needing code. We could have simple command sets they could issue serially to actually deliver software that then processes more serial commands.
No SPI slave stuff was made. What are your ideas about this?
But what if the clock rate goes up and down? It won't adapt if it's always looking for an ever-shorter 0/1, right?
That depends on how you code it. It would be easy to allow slow changes of << 2:1, to avoid false-snaps.
You would need a similar system on your single-key character, as I think these are similar
1..0_10110000_1..1
1..0_01100111_1=0_00000001_1..1
The bottom one, is a byte pair, at true baudrate, that could trigger a baud-snap to half-rate, if no other qualify is used ?
Would anyone have any opposition to putting the ROM at the BOTTOM of memory, so that it builds up from $00000?
This way, there's no ugly caveat at the end of memory which would inhibit one from allocating a huge top-justified block of RAM. I think this would lead to more efficient use of RAM. Also, RAM could begin right away after the bare necessities of ROM code, never minding any 2k rule.
Also, since immediate-address RDxxxx/WRxxxx would be pointless because of ROM, all immediate S values could be pointers, giving us one more bit of scaled offset, so instead of -16..+15 offsets, we could express -32..+31 offsets.
I don't see a problem with putting the ROM at location 0. The larger pointer offset range sounds like a good idea. I don't think I've ever used an immediate address with the RD/WR instructions anyway.
I agree about the I/O expander, but it's hard to nail down what all it should do. It quickly starts needing code. We could have simple command sets they could issue serially to actually deliver software that then processes more serial commands.
I think the smartest way to manage I/O, is to side step the idea of 'commands', and provide simple memory map access.
Slave GOGs have a tiny kernal that scans main memory for a WriteAdr.WriteValue and ReadAdr.
Master Cog simply says I want this data to go to/from this address.
Where resource access is via opcode, that would be hidden, and memory(s) allocated.
Ideal (smallest) would be if slaves have 100% identical code, but some simple address shift/ID is needed.
If a Cog can 'check it's own number', that could be used, or a mask at each COGINIT copy ?
I've been thinking about the auto-baud-detection problem and I think I came up with a solution:
<enter> / $0D would be the best value to auto-baud from because people will naturally hit the <enter> key initially and often.
Here it is serialized: 1..0_10110000_1..1
This could be detected by measuring incoming low and high times on RX into a circular buffer and looking for the following pattern:
1 for >8x clocks to ensure registration (dead time before $0D, could be generated by $FF)
0 for x clocks (start bit)
1 for x clocks (data bit 0)
0 for x clocks (data bit 1)
1 for 2x clocks (data bits 2 and 3)
0 for 4x clocks (data bits 4 through 7)
You would have to allow for maybe 1/4x slop in your detector, but once that pattern came in, you would know that you just got an $0D and you would be able to set the bit period (baud rate) right then. The detector would always be running as a task that would get switched to frequently. Any time a set of pulses came in that met the criteria, the baud rate would be set anew. The CTR now has mechanisms for measuring pulses, so it wouldn't require high-bandwidth task switching to pick up the values from it. At ~20MHz internal RC frequency and 115.2k baud, you would have 20M/115.2k = ~173 clocks per bit, or 0.576% error, not considering incoming jitter.
For the uninitiated, using the lower $200 longs for ROM could make sense to differentiate between $0 COG and $0 Hub addresses. Some might have a mental block that doesn't allow them to grok the 2 different address spaces. Having ROM at $000-$1FF in Hub memory kinda helps convey that "RAM" is $000-$1FF in COG and $200-$1FFFF in Hub.
That depends on how you code it. It would be easy to allow slow changes of << 2:1, to avoid false-snaps.
You would need a similar system on your single-key character, as I think these are similar
1..0_10110000_1..1
1..0_01100111_1=0_00000001_1..1
The bottom one, is a byte pair, at true baudrate, that could trigger a baud-snap to half-rate, if no other qualify is used ?
While the monitor is running, you might turn on the crystal and PLL and switch up to 160MHz, or go back down to ~20MHz. It needs to accommodate anything.
I think a byte with minimal-time transitions (0101) and at least five contiguous 0's (can't be doubled without violating serial protocol), preceded by $FF (at least 9 contiguous 1's) would be a sure-fire way to auto-detect baud. A common value that would qualify would be <space> $20, which serializes to 1..0_00000100_1. If that was preceded by $FF, would that be a singularity among all possibilities?
For the uninitiated, using the lower $200 longs for ROM could make sense to differentiate between $0 COG and $0 Hub addresses. Some might have a mental block that doesn't allow them to grok the 2 different address spaces. Having ROM at $000-$1FF in Hub memory kinda helps convey that "RAM" is $000-$1FF in COG and $200-$1FFFF in Hub.
While the monitor is running, you might turn on the crystal and PLL and switch up to 160MHz, or go back down to ~20MHz. It needs to accommodate anything.
I think a byte with minimal-time transitions (0101) and at least five contiguous 0's (can't be doubled without violating serial protocol), preceded by $FF (at least 9 contiguous 1's) would be a sure-fire way to auto-detect baud. A common value that would qualify would be <space> $20, which serializes to 1..0_00000100_1. If that was preceded by $FF, would that be a singularity among all possibilities?
On many older 8 bit machines to find AUTO BAUD --- SPACE -- was used as detecting byte to that
I think it's special because it has minimal-time transitions and six 0's in a row (starting with the start bit), so it can't be doubled (twelve 0's in a row is NOT serial). For high-speed automated systems, they could send an $FF before the $20 to cause at least nine 1's in a row (ending with the stop bit). For a user sitting at a terminal, he'll have plenty of 1's (idle bit periods) between characters. SPACE it is!
Comments
But if SPI-flash is empty how are you gone get it to be a first stage boot loader? (and no FDI chip on board)
If you can boot from SD, why not have one more check for a number so it jumps to the same copy to spi-flash as the Rom's Serial boot routine have.
And putting LED(s) on CS lines does not add any code as you need to twiddle with these pins anyway.
Just add a delay before you copy code (led goes off) so you can release the button you are holding down to temp disable the working spi-flash.
Or rom code should try to communicate with Spi-flash and a released button will show a read success and then start writing, but timeouts after 5 seconds of tries.
A non working spi-flash (empty or corrupt) don't need you to temp override it.
You are making my point for me. *IF* (big IF) you could boot from a removable media, your boot program on the media would copy the program to FLASH if the data in flash isn't the same. The ROM code doesn't need to be involved in this, and a bi-color LED for status is an end-user choice. I would also point out that LEDs can cause current drive problems when connected directly to logic lines that are shared. I had a problem with an LED pulling down the logic line on the FTDI chip and browning out the Propeller, so I installed a larger resistor.
I had some similar thoughts. Though I figured it would be better to use the whole COG space if you could. An extra 512 bytes of memory may not be as useful as additional features in the ROM. I don't think the ROM should grow larger than 2KB unless it was tucked into some leftover nook in the chip.
But then you would have to pad your code with this routine, with prop1 you don't have to pad your code with its serial programming as copy-to-eeprom is in ROM.
It would add two longs to the SD boot routine, so it behaves the same way the prop1 does it's eeprom programming.
Why not have it so you can grab any demo code from obex , compile it and have prop tool save it to SD card.
Sure it could be an option in prop-tool to add the padded code that do the re-transfer to SPI-Flash.
Yes and no.
If ROM space have be swapped with RAM space ---- We have had Entire SPACE of xxx KB RAM --- And much more ROM
Re: Forth.
I'm not serious about it at all, particularly if it wouldn't fit into the space we have. I have dabbled with Forth now and totally get why people would want it in there. Wouldn't take much to fire up a prop and send a whole environment to the thing. Of course, a nice monitor is the next best thing, and probably the much better thing.
Enter monitor, then send Forth, run it, send the dictionary desired, and carry on from there, the advantage being one can pick their Forth too. Bootstrapping a minimal setup, or new board would be trivial for anyone who has developed even moderate Forth skill. That's all pretty compelling to me on a lot of levels honestly. It's a lean path. There are lots of other paths and they are great, necessary. Don't get me wrong there. Not about that, or which is better, just baseline options.
If pressed on it, I really would like the monitor, and a good one would fit too.
<enter> / $0D would be the best value to auto-baud from because people will naturally hit the <enter> key initially and often.
Here it is serialized: 1..0_10110000_1..1
This could be detected by measuring incoming low and high times on RX into a circular buffer and looking for the following pattern:
1 for >8x clocks to ensure registration (dead time before $0D, could be generated by $FF)
0 for x clocks (start bit)
1 for x clocks (data bit 0)
0 for x clocks (data bit 1)
1 for 2x clocks (data bits 2 and 3)
0 for 4x clocks (data bits 4 through 7)
You would have to allow for maybe 1/4x slop in your detector, but once that pattern came in, you would know that you just got an $0D and you would be able to set the bit period (baud rate) right then. The detector would always be running as a task that would get switched to frequently. Any time a set of pulses came in that met the criteria, the baud rate would be set anew. The CTR now has mechanisms for measuring pulses, so it wouldn't require high-bandwidth task switching to pick up the values from it. At ~20MHz internal RC frequency and 115.2k baud, you would have 20M/115.2k = ~173 clocks per bit, or 0.576% error, not considering incoming jitter.
Does anyone see any weakness in this?
Sounds a good idea, but remember a common use will be a large QuadSPI Flash, with Font Tables.
- so an LED will also be active/flickering during user runtime.
Not a huge issue, as it will be a Board status led.
A bi-Colour LED could go on the /HOLD /WE pins, so a 1-bit SPI user would have independent LED control,
or a Uni-Colour LED could be active on CS=H, and any of D1.2.3 == !LED when SPI is de-selected.
Here, if a Font user wanted better LED info, they would code their SPI driver to update Dn with LED info on CS=H.
It would dim slightly on Font fetch.
Checking some more, I see the spec point for IOL on SPI parts is quite low, 1mA for Microchip, 1.6mA for Winbond.
Maybe then CS and CLK, as they are Prop-control pins, and the LED has no load-impact on light pullups, or assumes any drive ability of Loader Chip ? CLK needs to be defined when CS goes low, but outside that setup time, it can move when CS is hi.
I also see that Microchip support only SPI Mode 0, whilst Winbond & SST support both Mode 0 and Mode 3.
So that means a SPI ROM loader should be a Mode 0 loader.
It does not need to be that complex - as long as you have a single bit low and/or a single bit hi, you can measure the smallest-value, in a Get-Time-Between-Edges capture system, and you are done.
Your example of 1..0_10110000_1..1 meets this single bit requirement twice.
You may be able to use the new capture feature in timers, to drop the code size of this ?
If you wanted to add some noise immunity, you could add a count/vote to the Smallest value check. Char above gives 2, or use 'U' and get 8 results in your smallest value bin.
Requiring consecutive narrow-low and narrow-hi and > (eg) 1us, would be a simple way to remove single event miss-fires.
a) it goes through booting, fails, and loads the monitor. To do what? there's nothing to monitor
b) it manages to load some code, somehow, and the monitor is enabled. Why not just include it in RAM then? You don't have to argue about features (Forth, etc.). Just use what you want. And it will still take up a cog...
If you want it so that you can start with a bare chip why not just use the RX/TX protocol to load in a program?
As for ROM vs. RAM: 1 ROM bit is something like 1 transistor, while 1 RAM bit is 6 IIRC. So assuming ROM and RAM are tradeable, then you get 6x the amount of memory in ROM vs RAM.
But what if the clock rate goes up and down? It won't adapt if it's always looking for an ever-shorter 0/1, right?
It would just be a very simple and friendly thing that would enable people to ease into the chip without any tools. It would also enable simple tool building. It would lower the threshold way down for what it takes to make the chip do something. A serial terminal is all you'd need. You could paste in multi-line commands and run programs that way. It's something for when we all get old.
When we place ROM bits into hub memory, it's true that they are only 1 transistor, but they snap in the place of what was meant for a 6-transistor SRAM cell.
Chip got there first. LOL: "When we all get old." So true!
I was actually thinking of those "Learning PASM" threads we've had. A monitor is a nice tool to have for those basic, low level concepts. Of course, one could be written, and should for P1, and maybe it should for P2 as well, but since there are those bytes sitting around....
Well, stuff that gets built gets old too. I've had to use a monitor on several devices to get something up and running to get data and such in the past, or to do diagnostics. It's not a bad option to have.
This way, there's no ugly caveat at the end of memory which would inhibit one from allocating a huge top-justified block of RAM. I think this would lead to more efficient use of RAM. Also, RAM could begin right away after the bare necessities of ROM code, never minding any 2k rule.
Also, since immediate-address RDxxxx/WRxxxx would be pointless because of ROM, all immediate S values could be pointers, giving us one more bit of scaled offset, so instead of -16..+15 offsets, we could express -32..+31 offsets.
There is a lot of merit in that suggestion - smart IO and good pin control is valuable.
No added parts/no user code has appeal.
Such a scheme would need full control register access, and ideally access to all timers.
The same tiny code could clone into all slave COGs.
Challenge is making such a mode 'safely tucked into a corner', so perhaps one more Pin-Value test after 'no boot devices found' ?
It also needs to be as fast as possible, as an I/O expander this smart, can swallow a lot of data.
Q: Did a SPI Slave capability make the cut ?
It is what I write to David.
That give place for more ROM -- And as You said no ugly caveat at the end of memory
As ROM needs only in BOOT sequence I don't think that give any problems
NOT only RAM -- BUT even ROM --- As I think it simplify addressing of them
I agree about the I/O expander, but it's hard to nail down what all it should do. It quickly starts needing code. We could have simple command sets they could issue serially to actually deliver software that then processes more serial commands.
No SPI slave stuff was made. What are your ideas about this?
That depends on how you code it. It would be easy to allow slow changes of << 2:1, to avoid false-snaps.
You would need a similar system on your single-key character, as I think these are similar
1..0_10110000_1..1
1..0_01100111_1=0_00000001_1..1
The bottom one, is a byte pair, at true baudrate, that could trigger a baud-snap to half-rate, if no other qualify is used ?
I think the smartest way to manage I/O, is to side step the idea of 'commands', and provide simple memory map access.
Slave GOGs have a tiny kernal that scans main memory for a WriteAdr.WriteValue and ReadAdr.
Master Cog simply says I want this data to go to/from this address.
Where resource access is via opcode, that would be hidden, and memory(s) allocated.
Ideal (smallest) would be if slaves have 100% identical code, but some simple address shift/ID is needed.
If a Cog can 'check it's own number', that could be used, or a mask at each COGINIT copy ?
A SPI slave here, would allow >> 10M Baud IO expander. LED drivers commonly slave to 50MHz or above.
Does the RCVSER, not have a slave mode ?
Why run it in task that give you smaller place for main program if You have possibility to load second COG to that.
And then by using Internal PORT test if OK:
In that mode You can run all COGs In boot mode and have plenty of program possibilitys
While the monitor is running, you might turn on the crystal and PLL and switch up to 160MHz, or go back down to ~20MHz. It needs to accommodate anything.
I think a byte with minimal-time transitions (0101) and at least five contiguous 0's (can't be doubled without violating serial protocol), preceded by $FF (at least 9 contiguous 1's) would be a sure-fire way to auto-detect baud. A common value that would qualify would be <space> $20, which serializes to 1..0_00000100_1. If that was preceded by $FF, would that be a singularity among all possibilities?
Good point!
On many older 8 bit machines to find AUTO BAUD --- SPACE -- was used as detecting byte to that
I think it's special because it has minimal-time transitions and six 0's in a row (starting with the start bit), so it can't be doubled (twelve 0's in a row is NOT serial). For high-speed automated systems, they could send an $FF before the $20 to cause at least nine 1's in a row (ending with the stop bit). For a user sitting at a terminal, he'll have plenty of 1's (idle bit periods) between characters. SPACE it is!