For me the best demo would be a c64 like computer.
Let me explain some minimum features required
640*360 via hdmi 8 Bit Color Display This is 1/4 720p
4 Channels digital sound out like an Old Amiga
Sprites like in C64
PS2 or usb Keyboard support
SD Memory with some form of DOS like commands
Basic on board with a line editor like in C128
4–5 „Plug and Play“ io slots with „boot Rom“ option and device finding mechanism
@pedward
@cgracey
Years ago when I got into the P1 there was a board that was designed by someone who I will not mention and in a magazine that I asked about how did he do it. The response was not nice. I decided to learn how to do it myself.
I copied a board with a surface mount p1 and made the same with dips. It had monitor of the time connection, keyboard, tv, and the audio chip. I was able to solder the audio chip and had switches to turn off and on the other stuff so you could still access the pins selectively. I am looking at doing that again with the p2. Any ideas would be helpful to modernize the board. Would hdmi and the old screen connection at the same time be appropriate??
Thanks.
and @cgracy
thanks to all of your great employees who brought the genius out of me.
Plus Chantal is awesome.
I just came across a maybe trivial but sometimes very helpful feature that is unique about the P2.
A source level single step debugger (which is currently not available for the P2, yet, AFAIK) is very handy for testing new algorithms. But it doesn't help much in realtime systems. You can't single step through the code of a machine controller where you must not miss a single ADC sample or pin change event. Printfs or logfiles are sometimes not fast enough even though the P2 supports very high data rates.
But the "one fast DAC per pin" feature helps to get out of this dilemma. You can output any 16 bit value to a pin with very little overhead. You can watch multiple signals concurrently with the scope, trigger on events like out-of-bounds, glitches...
I just came across a maybe trivial but sometimes very helpful feature that is unique about the P2.
A source level single step debugger (which is currently not available for the P2, yet, AFAIK) is very handy for testing new algorithms. But it doesn't help much in realtime systems. You can't single step through the code of a machine controller where you must not miss a single ADC sample or pin change event. Printfs or logfiles are sometimes not fast enough even though the P2 supports very high data rates.
But the "one fast DAC per pin" feature helps to get out of this dilemma. You can output any 16 bit value to a pin with very little overhead. You can watch multiple signals concurrently with the scope, trigger on events like out-of-bounds, glitches...
Often you can squeeze in a few checkpoints in your main routine, for example a wrlong of each ADC value or a SETQ wrlong, to a fixed hub location(s) where another COG can pick up that data for outputting somewhere for debugging.
Alternately, if you copy variables to LUT (which is faster) and you have shared LUT invoked with the adjoining COG doing the monitoring.
You can even use the interrupt/signal another cog instruction.
If it's digital I/O you doing, then sampling (ie snooping) with adjacent spare smartpins using the streamer in another cog is yet another method. I was working on something like this about 2 years ago, which was an extension to the work Brian or Roger did with the streamer. I was working towards displaying the waveforms on a 1920x1080 VGA in realtime.
There are many options here, depending on precisely what you're doing and time/instruction availability. Use those spare cogs/cores for something useful
A source level single step debugger (which is currently not available for the P2, yet, AFAIK) is very handy for testing new algorithms. But it doesn't help much in realtime systems. You can't single step through the code of a machine controller where you must not miss a single ADC sample or pin change event. Printfs or logfiles are sometimes not fast enough even though the P2 supports very high data rates.
Verbose printf's will be an issue in any system, but you can use some tricks with P2 and P2D2 to get very fast, useful tag reports.
The UB3 on P2D2 can manage bursts of 8M.n.8.2 RX, and a P2 pin can serially send 32 bits, so you can emit 3 bytes of UART tag info in a single pin write, that does not slow down P2 at all.
The average rate of those reports, needs to be below the UB3-USB path of ~3-4MB/s, and they can be as close together as 4us.
At the moment I see the P2 as a kind of coprocessor for things that are difficult or impossible to do on a PC. That goes a bit in the direction of a RaspPi replacement. Specifically, I calculate data on the PC, send it via serial to the P2 and it turns it into a composite video signal that is visible on a monitor.
What would be good to show the P2 doing? I'm trying to think of some things that it can do uniquely well, without a lot of effort and code. We need some vehicles for getting the idea across to the world.
It seems the P2 might do well measuring NTC thermistors, with a common value being 100k, B Constant 4250 ?
10uA into 100k is ~ 1V, and I think at that level, the ADC load effect injects another ~ 1.2uA - both the 10uA and 1.2uA will have tempcos and tolerances.
Zero and VCC cal could be done by brief direct CMOS drive, and so cals with the same resistor as measures Vt.
GND drive shorts node to gnd, for 0mW into Vcc drive for CAL would see about 0.11mW power into the 100k.
An electronics workbench would be great. Oscilloscope, logic analyzer, signal generator, component tester. Setup to measure frequency response. Setup to measure impulse response. Setup to measure battery capacity. User interface via PC.
Power supply, P2, memory, SD card, USB serial, rot encoder, and a few opamps on a board. Power opamps. Configuration with patch cords and software modules.
Comments
Let me explain some minimum features required
640*360 via hdmi 8 Bit Color Display This is 1/4 720p
4 Channels digital sound out like an Old Amiga
Sprites like in C64
PS2 or usb Keyboard support
SD Memory with some form of DOS like commands
Basic on board with a line editor like in C128
4–5 „Plug and Play“ io slots with „boot Rom“ option and device finding mechanism
All code in source available
serial terminal at the same time.
Bill M.
@cgracey
Years ago when I got into the P1 there was a board that was designed by someone who I will not mention and in a magazine that I asked about how did he do it. The response was not nice. I decided to learn how to do it myself.
I copied a board with a surface mount p1 and made the same with dips. It had monitor of the time connection, keyboard, tv, and the audio chip. I was able to solder the audio chip and had switches to turn off and on the other stuff so you could still access the pins selectively. I am looking at doing that again with the p2. Any ideas would be helpful to modernize the board. Would hdmi and the old screen connection at the same time be appropriate??
Thanks.
and @cgracy
thanks to all of your great employees who brought the genius out of me.
Plus Chantal is awesome.
+100
A source level single step debugger (which is currently not available for the P2, yet, AFAIK) is very handy for testing new algorithms. But it doesn't help much in realtime systems. You can't single step through the code of a machine controller where you must not miss a single ADC sample or pin change event. Printfs or logfiles are sometimes not fast enough even though the P2 supports very high data rates.
But the "one fast DAC per pin" feature helps to get out of this dilemma. You can output any 16 bit value to a pin with very little overhead. You can watch multiple signals concurrently with the scope, trigger on events like out-of-bounds, glitches...
Alternately, if you copy variables to LUT (which is faster) and you have shared LUT invoked with the adjoining COG doing the monitoring.
You can even use the interrupt/signal another cog instruction.
If it's digital I/O you doing, then sampling (ie snooping) with adjacent spare smartpins using the streamer in another cog is yet another method. I was working on something like this about 2 years ago, which was an extension to the work Brian or Roger did with the streamer. I was working towards displaying the waveforms on a 1920x1080 VGA in realtime.
There are many options here, depending on precisely what you're doing and time/instruction availability. Use those spare cogs/cores for something useful
The UB3 on P2D2 can manage bursts of 8M.n.8.2 RX, and a P2 pin can serially send 32 bits, so you can emit 3 bytes of UART tag info in a single pin write, that does not slow down P2 at all.
The average rate of those reports, needs to be below the UB3-USB path of ~3-4MB/s, and they can be as close together as 4us.
10uA into 100k is ~ 1V, and I think at that level, the ADC load effect injects another ~ 1.2uA - both the 10uA and 1.2uA will have tempcos and tolerances.
Zero and VCC cal could be done by brief direct CMOS drive, and so cals with the same resistor as measures Vt.
GND drive shorts node to gnd, for 0mW into Vcc drive for CAL would see about 0.11mW power into the 100k.
Power supply, P2, memory, SD card, USB serial, rot encoder, and a few opamps on a board. Power opamps. Configuration with patch cords and software modules.