I'm still working on the USB circuit. It's taken some time figuring out what the interface needs to be, as there are events and byte transfers to report and handle. The cog software needs to have an easy time with this. So, it's been slowly congealing what needs to be done. I think when I have it all figured out, the implementation will come together really simply.
Great news Chip.
Sorry I haven't been much help this time around.
Been too busy with getting P1 on chip compilation to work under FAT32 drivers and OS - buried way deep in a few bugs
Will surface shortly
I actually took a break from it over the weekend, so I'm behind where I could have been.
I'm still working on the USB circuit. It's taken some time figuring out what the interface needs to be, as there are events and byte transfers to report and handle. The cog software needs to have an easy time with this. So, it's been slowly congealing what needs to be done. I think when I have it all figured out, the implementation will come together really simply.
Great news Chip.
Sorry I haven't been much help this time around.
Been too busy with getting P1 on chip compilation to work under FAT32 drivers and OS - buried way deep in a few bugs
Will surface shortly
Sounds good.
What about using one Prop1 to target another? That way, if the target crashes due to a bug, you don't have to start over. That's how I've envisioned the Prop2 tools, anyway.
That is easy. All I/O goes via common hub longs (rendezvous locations in top hub ram). The cog drivers can be replaced with serial/video/keyboard or whatever without altering the OS or Compiler. Currently I am using a PCSIO driver which is loaded into a resident cog and communicates to PST running on a PC at 115,200 baud. Absolutely no reason why this cannot be another P1 !
If the compiler crashes it reboots the P1. It is running under my OS which uses the same indirection. The compiler is a 3 stage (LEX, CODEGEN & LINK) based on Michael Park's Sphinx Compiler, and runs on FAT16/32 using a modified version of Kye's SD_FATEngine. The OS includes Dir (sorted and * substitution), Copy, Ren, Del, Type (with a hex/ascii option too), Hubdump (hex/ascii), Free/Used (SD space), Help, Reboot, Run (a binary file), Program (the EEPROM lower or upper 32KB), Diff (difference between 2 files), and File Transfers between PC and Propeller SD card, etc. It can also read/write (transfer) CPM2.2 format disk files which we can use with the heater's Z80 emulation ZiCog and my RamBlade boards which have 512KB 55ns SRAM.
The EEPROM contains a simple and generic boot program that looks for two files on the SD card. It loads the first one found. If my OS is present then it will be loaded, if the first file is not found. There is no requirement for a PropPlug as files can be copied to the SD card on the PC.
Just need to get USB running properly on the P1, and ready for P2
I'm still working on the USB circuit. It's taken some time figuring out what the interface needs to be, as there are events and byte transfers to report and handle. The cog software needs to have an easy time with this. So, it's been slowly congealing what needs to be done. I think when I have it all figured out, the implementation will come together really simply.
Great news Chip.
Sorry I haven't been much help this time around.
Been too busy with getting P1 on chip compilation to work under FAT32 drivers and OS - buried way deep in a few bugs
Will surface shortly
Sounds good.
What about using one Prop1 to target another? That way, if the target crashes due to a bug, you don't have to start over. That's how I've envisioned the Prop2 tools, anyway.
That is easy. All I/O goes via common hub longs (rendezvous locations in top hub ram). The cog drivers can be replaced with serial/video/keyboard or whatever without altering the OS or Compiler. Currently I am using a PCSIO driver which is loaded into a resident cog and communicates to PST running on a PC at 115,200 baud. Absolutely no reason why this cannot be another P1 !
If the compiler crashes it reboots the P1. It is running under my OS which uses the same indirection. The compiler is a 3 stage (LEX, CODEGEN & LINK) based on Michael Park's Sphinx Compiler, and runs on FAT16/32 using a modified version of Kye's SD_FATEngine. The OS includes Dir (sorted and * substitution), Copy, Ren, Del, Type (with a hex/ascii option too), Hubdump (hex/ascii), Free/Used (SD space), Help, Reboot, Run (a binary file), Program (the EEPROM lower or upper 32KB), Diff (difference between 2 files), and File Transfers between PC and Propeller SD card, etc. It can also read/write (transfer) CPM2.2 format disk files which we can use with the heater's Z80 emulation ZiCog and my RamBlade boards which have 512KB 55ns SRAM.
The EEPROM contains a simple and generic boot program that looks for two files on the SD card. It loads the first one found. If my OS is present then it will be loaded, if the first file is not found. There is no requirement for a PropPlug as files can be copied to the SD card on the PC.
Just need to get USB running properly on the P1, and ready for P2
Reading about modes %10100 to %10111, I have a few questions:
* Are there any caveats if A and B point to the same pin?
* Do you have to pulse DIR to reset Z, or does it reset on PINGETZ also?
* For the "either edge" modes, is there a way to know which edge was encountered?
Also, does this mean that the alternate idea of capturing sysclk instead of count was not possible?
Also, a thought occurred to me about the modes that use $8000_0000 to indicate a timeout. These could all be extended slightly:
Value Interpretation
<$8000_0000 Normal timed event
=$8000_0000 Timeout
>$8000_0000 Missed event
In the case of the missed event, bits [30:0] would contain the same value as normal, but for the most recent measurement (or would it be cumulative?). In practice, the value in [30:0] probably won't be much use. Most of the time, the value will simply be used to detect a missed event.
Reading about modes %10100 to %10111, I have a few questions:
* Are there any caveats if A and B point to the same pin?
* Do you have to pulse DIR to reset Z, or does it reset on PINGETZ also?
* For the "either edge" modes, is there a way to know which edge was encountered?
Also, does this mean that the alternate idea of capturing sysclk instead of count was not possible?
Modes %101xx wait for the A-edge, then the B-edge. Then, they start over, and wait for A-edge, then the B-edge, again. If the edges are concurrent, it will wait for the next edge of interest. The Z value will be a new measurement, each time.
There is no way to know which edge came in, though that could be added very easily.
The sysclk (CT) capture could work. It's just not that way right now. It wouldn't be hard to do.
FYI All
Just a heads up to a change to the smart pin instruction format
In version 7z it was
D/# = %BBBB_AAAA_FFF_PPPPPPPPPPPPP_T_D_MMMMM_1
and in version 8 it is now
D/# = %AAAA_BBBB_FFF_PPPPPPPPPPPPP_TT_MMMMM_0
** Note pin selection position change and bit 0 inversion **
It might make sense to rearrange this as follows:
D/# = %PPPPPPPPPPPPP_FFF_AAAA_BBBB_TT_MMMMM_0
That way, where %PPPPPPPPPPPPP_FFF is zero, PINSETM would take only 6 clocks instead of 10. In half-duplex modes, where you are frequently switching between RX and TX, this could make a difference in maximum bit rate.
The smart pin section isn't too long - at least, the first part. I recommend everyone read that, along with whatever mode they are interested in.
I started re-reading the entire document. More than once, I though "I forgot about that!" It's amazing how much more powerful this is compared to the P1. Calling it "P2" really doesn't do it justice!
Incidentally, I notice that there are still two unused interrupt event sources. It seems a shame to leave them empty. If nothing else, it might make sense to trap reading from or writing to hub address zero (for null pointer detection).
Normally I don't read documentation, because it all looks Greek to me. I'm trying. It is nice having Brian around:)
Somewhere in there is the answer to this question, but I'll be damned if I can find it.
It is about Phil's camera. He didn't hook up the actual Hsync signal of the sensor... which is fine. He is using a data pin to indicate both Hsync and the start of each pixel data coming out (in serial snapshot mode). This means that you have to look for a gap in his "hsync-lite" pin to indicate the end of a line and then use the next signal from the same pin to indicate the beginning of the pixel data, which arrives without gaps, 8 bits at a time.
I handle this currently by just capturing all of the data, using wrfast and ina, and then worry about it later... big buffer:)
The data is valid on the negative clock(10MHz)... so I can invert this pin, but how do I use that clock with the smartpin in serial mode? Or can I?
Normally I don't read documentation, because it all looks Greek to me. I'm trying. It is nice having Brian around:)
Somewhere in there is the answer to this question, but I'll be damned if I can find it.
It is about Phil's camera. He didn't hook up the actual Hsync signal of the sensor... which is fine. He is using a data pin to indicate both Hsync and the start of each pixel data coming out (in serial snapshot mode). This means that you have to look for a gap in his "hsync-lite" pin to indicate the end of a line and then use the next signal from the same pin to indicate the beginning of the pixel data, which arrives without gaps, 8 bits at a time.
I handle this currently by just capturing all of the data, using wrfast and ina, and then worry about it later... big buffer:)
The data is valid on the negative clock(10MHz)... so I can invert this pin, but how do I use that clock with the smartpin in serial mode? Or can I?
So, you want to do synchronous serial input, but 8 bits wide?
If that's the case, the streamer would do a much better job than the smart pins, but it needs an external clock input. This is simple to add. Could you post a link to that camera doc, or just the relevant section?
FYI All
Just a heads up to a change to the smart pin instruction format
In version 7z it was
D/# = %BBBB_AAAA_FFF_PPPPPPPPPPPPP_T_D_MMMMM_1
and in version 8 it is now
D/# = %AAAA_BBBB_FFF_PPPPPPPPPPPPP_TT_MMMMM_0
** Note pin selection position change and bit 0 inversion **
It might make sense to rearrange this as follows:Hu
D/# = %PPPPPPPPPPPPP_FFF_AAAA_BBBB_TT_MMMMM_0
That way, where %PPPPPPPPPPPPP_FFF is zero, PINSETM would take only 6 clocks instead of 10. In half-duplex modes, where you are frequently switching between RX and TX, this could make a difference in maximum bit rate.
I put it the way it is so that P[7:0] is on a byte boundary, making it easy to set the DAC or comparator value. The P field is 13 bits, which is odd.
was hoping to test this real fast, but my serial output code is now broke...
Something must have changed. Don't think it's the serial output itself, just the code driving it...
Getting "0"s out instead of numbers and strings...
Also, a thought occurred to me about the modes that use $8000_0000 to indicate a timeout. These could all be extended slightly:
Value Interpretation
<$8000_0000 Normal timed event
=$8000_0000 Timeout
>$8000_0000 Missed event
In the case of the missed event, bits [30:0] would contain the same value as normal, but for the most recent measurement (or would it be cumulative?). In practice, the value in [30:0] probably won't be much use. Most of the time, the value will simply be used to detect a missed event.
Yes, the more usual Overflow Flag operation is simply a single sticky bit.
Other counter bits do not lose information - ie they continue to count.
(This is probably actually simpler in silicon. )
I have just used exactly this feature in another MCU, where I know it is going to overflow, but I also know the spread is not large, so I can still calibrate using a timer that overflowed many times in this case.
Also, does this mean that the alternate idea of capturing sysclk instead of count was not possible?
I'm not following this comment.
From my reading, Time Interval A-B modes are capturing SysCLK units ?
Or did you mean a method to capture both SysCLK and Count information, which Reciprocal Counting needs.
I have assumed always that would need 2 pin cells, but that it would be possible.
A quite similar situation occurs for Duty Cycle capture - you ideally want two numbers, (here they are both dT) that relate to the exact same edge(s)
Two pin cells should be able to do this ? but can they ?
What is missing from this Time Interval A-B mode, is a means to handle missed events.
Users are forced to assume & hope that only one capture occurred.
A sudden jump in calculated frequency can result, if the dT is actually more than one event.
Comments
I actually took a break from it over the weekend, so I'm behind where I could have been.
That is easy. All I/O goes via common hub longs (rendezvous locations in top hub ram). The cog drivers can be replaced with serial/video/keyboard or whatever without altering the OS or Compiler. Currently I am using a PCSIO driver which is loaded into a resident cog and communicates to PST running on a PC at 115,200 baud. Absolutely no reason why this cannot be another P1 !
If the compiler crashes it reboots the P1. It is running under my OS which uses the same indirection. The compiler is a 3 stage (LEX, CODEGEN & LINK) based on Michael Park's Sphinx Compiler, and runs on FAT16/32 using a modified version of Kye's SD_FATEngine. The OS includes Dir (sorted and * substitution), Copy, Ren, Del, Type (with a hex/ascii option too), Hubdump (hex/ascii), Free/Used (SD space), Help, Reboot, Run (a binary file), Program (the EEPROM lower or upper 32KB), Diff (difference between 2 files), and File Transfers between PC and Propeller SD card, etc. It can also read/write (transfer) CPM2.2 format disk files which we can use with the heater's Z80 emulation ZiCog and my RamBlade boards which have 512KB 55ns SRAM.
The EEPROM contains a simple and generic boot program that looks for two files on the SD card. It loads the first one found. If my OS is present then it will be loaded, if the first file is not found. There is no requirement for a PropPlug as files can be copied to the SD card on the PC.
Just need to get USB running properly on the P1, and ready for P2
That sounds great!
Smart pin docs are all updated, too.
Exciting!
Just a heads up to a change to the smart pin instruction format ** Note pin selection position change and bit 0 inversion **
Good idea.
Good catch! That would have caused quite a bit of head scratching!
Reading about modes %10100 to %10111, I have a few questions:
* Are there any caveats if A and B point to the same pin?
* Do you have to pulse DIR to reset Z, or does it reset on PINGETZ also?
* For the "either edge" modes, is there a way to know which edge was encountered?
Also, does this mean that the alternate idea of capturing sysclk instead of count was not possible?
The smart pin section isn't too long - at least, the first part. I recommend everyone read that, along with whatever mode they are interested in.
In the case of the missed event, bits [30:0] would contain the same value as normal, but for the most recent measurement (or would it be cumulative?). In practice, the value in [30:0] probably won't be much use. Most of the time, the value will simply be used to detect a missed event.
Modes %101xx wait for the A-edge, then the B-edge. Then, they start over, and wait for A-edge, then the B-edge, again. If the edges are concurrent, it will wait for the next edge of interest. The Z value will be a new measurement, each time.
There is no way to know which edge came in, though that could be added very easily.
The sysclk (CT) capture could work. It's just not that way right now. It wouldn't be hard to do.
I had some problems with copy/paste. It looked ok in PNUTv8, but didn't run right. Second time was a charm.
So I'm posting your code as an attachment.
It might make sense to rearrange this as follows:
That way, where %PPPPPPPPPPPPP_FFF is zero, PINSETM would take only 6 clocks instead of 10. In half-duplex modes, where you are frequently switching between RX and TX, this could make a difference in maximum bit rate.
I started re-reading the entire document. More than once, I though "I forgot about that!" It's amazing how much more powerful this is compared to the P1. Calling it "P2" really doesn't do it justice!
Incidentally, I notice that there are still two unused interrupt event sources. It seems a shame to leave them empty. If nothing else, it might make sense to trap reading from or writing to hub address zero (for null pointer detection).
Thank you!!!
Normally I don't read documentation, because it all looks Greek to me. I'm trying. It is nice having Brian around:)
Somewhere in there is the answer to this question, but I'll be damned if I can find it.
It is about Phil's camera. He didn't hook up the actual Hsync signal of the sensor... which is fine. He is using a data pin to indicate both Hsync and the start of each pixel data coming out (in serial snapshot mode). This means that you have to look for a gap in his "hsync-lite" pin to indicate the end of a line and then use the next signal from the same pin to indicate the beginning of the pixel data, which arrives without gaps, 8 bits at a time.
I handle this currently by just capturing all of the data, using wrfast and ina, and then worry about it later... big buffer:)
The data is valid on the negative clock(10MHz)... so I can invert this pin, but how do I use that clock with the smartpin in serial mode? Or can I?
So, you want to do synchronous serial input, but 8 bits wide?
If that's the case, the streamer would do a much better job than the smart pins, but it needs an external clock input. This is simple to add. Could you post a link to that camera doc, or just the relevant section?
I put it the way it is so that P[7:0] is on a byte boundary, making it easy to set the DAC or comparator value. The P field is 13 bits, which is odd.
product info/data sheet
sensor data sheet
Something must have changed. Don't think it's the serial output itself, just the code driving it...
Getting "0"s out instead of numbers and strings...
Old (broke):
send_char pinsety tx_char,#TX_PIN 'send character send_char_wait pingetz temp,#TX_PIN testb temp,#31 wz,wc if_nz jmp #send_char_wait ret wz,wcOz (works):send_char pingetz temp,#tx_pin wc 'wait if busy if_c jmp #send_char pinsety tx_char,#tx_pin ret wz,wcYes, the more usual Overflow Flag operation is simply a single sticky bit.
Other counter bits do not lose information - ie they continue to count.
(This is probably actually simpler in silicon. )
I have just used exactly this feature in another MCU, where I know it is going to overflow, but I also know the spread is not large, so I can still calibrate using a timer that overflowed many times in this case.
From my reading, Time Interval A-B modes are capturing SysCLK units ?
Or did you mean a method to capture both SysCLK and Count information, which Reciprocal Counting needs.
I have assumed always that would need 2 pin cells, but that it would be possible.
A quite similar situation occurs for Duty Cycle capture - you ideally want two numbers, (here they are both dT) that relate to the exact same edge(s)
Two pin cells should be able to do this ? but can they ?
What is missing from this Time Interval A-B mode, is a means to handle missed events.
Users are forced to assume & hope that only one capture occurred.
A sudden jump in calculated frequency can result, if the dT is actually more than one event.