Dave,
IMHO NTSC is extremely important. There are cheap 4"-8" LCDs for car reversing cameras with good definition popping up all over the place. I bought one a couple of years ago for ~$26 and it can do 80 columns of text from P1.
I don't think PAL is as important now, but if it is simple then it makes sense too.
I expect that we could make the P2 do some simple HDMI, but from all the discussions proper HDMI will not be achievable. Sad but lets be realistic because apart from driving LCDs directly, Composite NTSC and HDMI are the future. VGA is going away slowly, but cheap new and used VGA capable monitors are plentiful. Don't bother with cheap HDMI to VGA cables (passive) - I bought one and found a weird wiring - all grounds to weird VGA pins with nothing wired to the VGA RGB pins at all I wanted to use an HDMI connector for VGA because of its small footprint and wanted a cheap cable to wire to VGA.
jmg,
Agreed ARM have HDMI covered. Just add a cheap ARM chip to a P2 just to do HDMI may be a good way to go.
I wonder if the extra NTSC block (not the streamer part) has other uses that could justify being in every cog???
Yep. There are a heap of "AV2HDMI" converters on the market for $12 and upwards. They're more likely to fall in price rather than go up in price, from here...
There's even room for a prop2 on the inside on most of them. I posted some photos here
I just uploaded new FPGA files at the top of this thread to fix this FIFO bug.
Thank you Chip! That has fixed the problem for me. My test harness with all the rd/wr byte/word/long tests runs without errors, both in my test harness code, and the instructions under test.
There's a problem with the last upload I made. I forgot to differentiate the loader ROM's, so everything looks like a Prop123-A7 board to PNut. I need to redo these FPGA files. The DE0-Nano and DE2-115 images are bad! Stand by....
jmg,
Agreed ARM have HDMI covered. Just add a cheap ARM chip to a P2 just to do HDMI may be a good way to go.
I wonder if the extra NTSC block (not the streamer part) has other uses that could justify being in every cog???
Good question.
It does give advanced phase modulation, but cannot decode the same signal, and I'm not sure it can do I-Q modulation...
Hard to think of a wide application area outside of Composite/Component video ?
Perhaps Sonar ?, but I think those are digital on the high power transmit and analog on receive.
Maybe ultrasonic flow meters ? ISTR some fine-adjusts needed there, that are outside the vanilla MCUs.
Fine phase control may help time-of-flight problems, but needs to be analog-drive to get most benefit.
There's a problem with the last upload I made. I forgot to differentiate the loader ROM's, so everything looks like a Prop123-A7 board to PNut. I need to redo these FPGA files. The DE0-Nano and DE2-115 images are bad! Stand by....
How are the Prop123-A9 boards coming? Any idea when they will be available?
There's a problem with the last upload I made. I forgot to differentiate the loader ROM's, so everything looks like a Prop123-A7 board to PNut. I need to redo these FPGA files. The DE0-Nano and DE2-115 images are bad! Stand by....
How are the Prop123-A9 boards coming? Any idea when they will be available?
They are sitting right next to me. I need to configure and test them, then send them back to Parallax for shipping to everyone. I'll be working on it today.
Chip,
Is the P1V Verilog code viable as a base to be used to make a P1+?
ie Is it considered production ready (debugged)?
It is the same code that made the P8X32A chip, translated from AHDL to Verilog. It should be. There's not much to the P1, anyway.
Thanks Chip. Those were my thoughts. And a number of us have done some interesting testing and variants on the P1V too.
Would you mind answering these too please?
Has Treehouse done whatever was necessary to get the P2 I/O manual layout ready to merge into the P2 Verilog/RTL?
Could this be used on a P1+, and if so, is it a lot of work/time/expense?
Could you guess at the cost to get sample chips of a P1+, presuming Verilog is complete?
OnSemi make CAT24C256/512's, so do they have standard eeprom cells available? If so, could the be put in P1+/P2?
Chip, just a minor housekeeping point but when you post the new files would you please consider naming them in ascending date format rather than the American numerical date. Nov 9, 2015 is clearly recognizable but 11/09/15b confuses us unnecessarily, is that the 11th of the 9th for instance. I end up renaming all these files in ascending order so that this file becomes Prop2_FPGA_151109b.zip and it is the one after Prop2_FPGA_151107.zip which is after Prop2_FPGA_151029.zip. No confusion whatsoever and they are all nicely in order as well even when you appended the time too YYMMDD-HHMMSS, all in ascending order. ISO8601 always wants the century too but the principle is the same.
Supply current goes up with increasing supply voltage. Is it possible for 180nm parts to run at 5 volts? I'm gonna guess there is a tiny linear voltage regulator inside those EEPROMs.
I would like to know how easy the option is for I/O pins operate with 5v when the core is 1.8v. If I was making a list for Prop2 features then 5v I/O would be on that list.
EDIT: I misread the datasheet. There is no indication of supply current vs supply voltage that I can see.
I would like to know how easy the option is for I/O pins operate with 5v when the core is 1.8v. If I was making a list for Prop2 features then 5v I/O would be on that list.
Some MCUs are 3v3 core and 5V tolerant, and some like the Infineon XMC1000 series (M0 core) operate from 1.8~5.5V
However, that does take special engineering, and special oxides (ie process).
I think it is off the table for P2.
That now becomes a general question. Is it really special engineering at all? I had assumed feature size defined operating voltage ... but I now suspect that was a wrong assumption. Maybe it's mostly thermal and speed factors, and with something like a block of, high density but not particularly fast, memory then it's pretty much all dark and cool running. So, raising the supply voltage becomes no issue then?
So, raising the supply voltage becomes no issue then?
Err, no, gate oxide thickness is what sets voltage tolerance, and those infineon parts will be using multiple oxide thicknesses and they will also have a core voltage regulator, so only the IO ring needs the ticker oxide.
So yes, it is special engineering.
... gate oxide thickness is what sets voltage tolerance, ...
I guess there must be a general relationship between feature size and oxide thickness. Presumably there is a need to make the insulator thinner as the features shrink ... and I suspect this comes back to power and speed.
Excellent. BTW: I don't know how easy it would be but, 1,2, and 4 bit streaming options might be nice for high resolution text and simple graphic outputs...
Excellent. BTW: I don't know how easy it would be but, 1,2, and 4 bit streaming options might be nice for high resolution text and simple graphic outputs...
So, ever since the trigger longs were moved to the top of hub ram, I thought that immediate mode for RDxxxx and WRxxxx seemed pretty useless. Can it be either removed and the space be given to more PTRx range/features, or modified so that immediate addresses get $FFF00 (or $7FF00?) added to them, so they access the top 256 bytes of hubram, which has the trigger longs (and debug pointers) and can also have other user-defined mailboxes?
So, ever since the trigger longs were moved to the top of hub ram, I thought that immediate mode for RDxxxx and WRxxxx seemed pretty useless. Can it be either removed and the space be given to more PTRx range/features, or modified so that immediate addresses get $FFF00 (or $7FF00?) added to them, so they access the top 256 bytes of hubram, which has the trigger longs (and debug pointers) and can also have other user-defined mailboxes?
I support that idea. Ideally an indexed ptr as each of S and D, such as:
rdlong ++ptra, ptrb--[1]
... style would be useful. However, I think that would need doubling up on the logic which manages the ptr increment/decrement and scaling.
Comments
IMHO NTSC is extremely important. There are cheap 4"-8" LCDs for car reversing cameras with good definition popping up all over the place. I bought one a couple of years ago for ~$26 and it can do 80 columns of text from P1.
I don't think PAL is as important now, but if it is simple then it makes sense too.
I expect that we could make the P2 do some simple HDMI, but from all the discussions proper HDMI will not be achievable. Sad but lets be realistic because apart from driving LCDs directly, Composite NTSC and HDMI are the future. VGA is going away slowly, but cheap new and used VGA capable monitors are plentiful. Don't bother with cheap HDMI to VGA cables (passive) - I bought one and found a weird wiring - all grounds to weird VGA pins with nothing wired to the VGA RGB pins at all
jmg,
Agreed ARM have HDMI covered. Just add a cheap ARM chip to a P2 just to do HDMI may be a good way to go.
I wonder if the extra NTSC block (not the streamer part) has other uses that could justify being in every cog???
There's even room for a prop2 on the inside on most of them. I posted some photos here
Works like a Champ on the two test program I have! Instruction can start on any byte boundary.
Thanks, Chip!!
Thank you Chip! That has fixed the problem for me. My test harness with all the rd/wr byte/word/long tests runs without errors, both in my test harness code, and the instructions under test.
PAL should 'come for free' in any good phase modulator.Most TV chipsets simply decode both, & PAL gives more resolution.
Good question.
It does give advanced phase modulation, but cannot decode the same signal, and I'm not sure it can do I-Q modulation...
Hard to think of a wide application area outside of Composite/Component video ?
Perhaps Sonar ?, but I think those are digital on the high power transmit and analog on receive.
Maybe ultrasonic flow meters ? ISTR some fine-adjusts needed there, that are outside the vanilla MCUs.
Fine phase control may help time-of-flight problems, but needs to be analog-drive to get most benefit.
They are sitting right next to me. I need to configure and test them, then send them back to Parallax for shipping to everyone. I'll be working on it today.
Quick question. How viable is the P1V code?
What do you mean?
Is the P1V Verilog code viable as a base to be used to make a P1+?
ie Is it considered production ready (debugged)?
It is the same code that made the P8X32A chip, translated from AHDL to Verilog. It should be. There's not much to the P1, anyway.
Would you mind answering these too please?
Has Treehouse done whatever was necessary to get the P2 I/O manual layout ready to merge into the P2 Verilog/RTL?
Could this be used on a P1+, and if so, is it a lot of work/time/expense?
Could you guess at the cost to get sample chips of a P1+, presuming Verilog is complete?
OnSemi make CAT24C256/512's, so do they have standard eeprom cells available? If so, could the be put in P1+/P2?
I would like to know how easy the option is for I/O pins operate with 5v when the core is 1.8v. If I was making a list for Prop2 features then 5v I/O would be on that list.
EDIT: I misread the datasheet. There is no indication of supply current vs supply voltage that I can see.
However, that does take special engineering, and special oxides (ie process).
I think it is off the table for P2.
Err, no, gate oxide thickness is what sets voltage tolerance, and those infineon parts will be using multiple oxide thicknesses and they will also have a core voltage regulator, so only the IO ring needs the ticker oxide.
So yes, it is special engineering.
Try it and see
EDIT: Nope, it's definitely a linear regulator, at just 32 MHz it turns out there is some real low-power ARMs out there.
I guess there must be a general relationship between feature size and oxide thickness. Presumably there is a need to make the insulator thinner as the features shrink ... and I suspect this comes back to power and speed.
...that Chip has provided clues as to how to use the streamer...
Certainly. I hope to get that documented today.
It's all in there, already.
Everything working.