Graphical DEBUG Source Code
cgracey
Posts: 14,133
in Propeller 2
Here is the Delphi and x86 source code that some of you wanted for the graphical DEBUG displays.
These files will not compile into an application, but they contain the critical code that makes up the graphical displays.
If you follow from SerialUnit.pas and look at the StartDebug procedure, you can follow the execution. The debug.asm file (8 spaces per tab) contains the parser and symbol-table code that looks at the DEBUG strings which begin with the "`" character.
These files will not compile into an application, but they contain the critical code that makes up the graphical displays.
If you follow from SerialUnit.pas and look at the StartDebug procedure, you can follow the execution. The debug.asm file (8 spaces per tab) contains the parser and symbol-table code that looks at the DEBUG strings which begin with the "`" character.
Comments
A while back I found we can get reasonable performance with VGA at 1080p at 8bpp when it's overclocked. Bitmaps could come from other areas of HyperRAM (or HyperFlash), and blitting images to regions is now supported. If you need 24bpp then yeah 1080p is asking too much but higher bit depths could still be served with lower resolutions over VGA like XGA, SVGA etc. Chip mentioned double buffering from two banks of HyperRAM too, I think this is an interesting thought to consider. Right now my HyperRAM driver was designed to support multiple devices mapped to different address ranges (yet untested as I only have one HyperRAM module here), but my video driver must currently nominate its source from only one external memory mailbox. I'll have to think whether it could be extended somehow to support two mailboxes which are then dynamically selected by the actual video address. I'm expecting that just might not fit in the video driver...
As was mentioned in the presentation, a multi-bit capable logic level trace would be good to try to display, as well as bar charts per channel which might be useful for monitoring ADC values etc, and also a single hi/lo coloured block like an LED being on/off for high/low pin state indication. The background BMP idea is handy for pretty overlays like gauges that would be hard or slow to fully draw dynamically. This could still work with the P2 approach if you have these bitmap images pre-stored in HyperFlash or HyperRAM as they can be copied over into a render buffer and drawn over. Entire screen page flipping is already supported too, and the 16MB of RAM is plenty for this.
From a cross-platform point of view, I think something like SDL should be investigated for the window display stuff on the PC, in addition to something like using FreePascal or maybe the recent cross platform versions of Delphi. If you start to tie everything to Windows only now it will restrict the target audience and only make porting harder later. But it's the protocol that matters more I guess, and others might be able to extend things based on that.
This came up a week ago again. While I agree with JonnyMac that we need standard libraries and standard tools, but I don't think those standard libraries would come any faster if Chip has to do something he doesn't really like and don't tickle his fancy and fulfill his standalone vision. After all, Parallax is here because Chip did stuff he really liked doing, and thus created the Propeller and the P2 that has capabilities that other microcontrollers just don't. Stifling Chip's creativity to get done things that need to be done like the standard libs and documentation, it seems to me that there are better people to do that.
Now it seems we are getting a P2Edge with 32MB of PSRAM, and microSD slot, Chip will have a standard platform that he can distribute his code to. So, it seems to me @cgracey, if you can excuse more unsolicited advice, you should build your vision for a stand-alone system and let others create the standard tools. It seems bazaar to me that you would spend time with x86 Assembly and Delphi which live on a platform that sucks. I would love to see you port first PNut's debug over to the P2(even if you need a second one), and then maybe the rest of the assembler/spin compiler. I would love to see your vision developed.
Take Care,
Doug
Having a development and debugging environment on the P2 would be like that reliable Schwinn bike....no dealing with all of the complexity of the PC. If you don't do it, somebody else will, and it won't be as good. Until then, we have TAQOZ.
Thanks, Hinv!
All I need is a little encouragement to go completely nuts.
I am looking forward to the 32MB Edge, because it will allow this sort of development system very nicely.
Ohhhhh! I like that drop. I’m attempting to write my Linux based debug view and this will help a lot 😍
That's what I wanted to hear! You've done amazing things, like the Propeller and P2 because you were inspired.
Have you seen the Next Thing Inc PocketChip?
https://shop.pocketchip.co/collections/frontpage/products/pocket-c-h-i-p-new
If not, PM me your addy, I'd gladly send you one of mine to play with. Having your hands one would be helpful.
Parallax could build something similar with a socket for the P2Edge32MB on the back. Breakouts and BNC option for scope probes at the top, etc. Hopefully a better screen and keyboard and audio too, but similar form factor would make it an AWESOME educational tool, portable dev platform, goto bench instrument, but having the tools native to the P2 would be necessary requirement.
I agree with this. It's the protocol that needs to be well defined. Same thing for the Propeller Tool/PNut with the actual compiling and editor done on the P2 itself. Then on the multiplatform host computer side could be kept light, weather it be a tablet, another P2, Rpi, Linux desktop, Winblows, or Mac, do mostly color terminal with the Parallax font done on JavaScript, or PythonTK or Tcl/Tk or whatever multi-platform language, with the option of both host and P2 file access. All that is needed from @cgracey would be PNut ported to the P2 with the interface protocol to the front end. I would guess it would be best for Chip to make the human interface side in whatever he feels comfortable with, probably Delphi. The key is to keep the 2 sides of dev platform (human front end vs compiler, assembler, linker back end) separate. The human interface side could be as simple as a color terminal with file access and Function Keys to trigger fast compiles and such. With a well defined protocol, XBee, WiFi, Bluetooth, LoRa, or whatever could be put in the middle. Parallax would have less multiplatform support to do with a lighter front end.
If the link is fast enough, even a ramless P2 could use swap space and file access on the served from the multiplatform front end. That would be a bit more complicated on both sides of the protocol, but it could work, albeit slowly, for all P2 boards, and still be less complex on the multiplatform side for parallax to support since the compiler would be a binary to download into the P2, which is the same on every platform distribution.
A good start to this would be a hex display of hub ram similar to the PropellerTools hex display function.
One could also do a hex display it for any target cog if that cog has a little code to dump it's contents to hub.
Anyways, just some thoughts. Unfortunately, I'm not even close to as good a coder as I think I am with these ideas. What say you?
Take Care,
hinv
@rogloh, I was just thinking, that if cog that served up the external PSRAM had a standard protocol, it could be swapped out for one with HyperRAM, or one with SRAM or DRAM or even swap-to-host or swap-to-microSD or swap-to-flash without programs that need more memory than hub provides having to know any more details that the size, expected performance, and size. I think a graphics driver would need tighter coupling than that, but a compiler and many other large programs wouldn't because the timings wouldn't need to be strict.
Yes I already have my defined mailbox protocol shared by a SPIN2 wrapper layer and this allows me to map different memory bus types into a global address space and swap them around at will. Currently the low level drivers I've put together already support accessing HyperRAM/HyperFlash, PSRAM, SRAM and HUBRAM (mainly for debug) and I've started on a flash one that should be compatible with the SPI based flash device used on the P2 boards. My video driver works with the exact same mailbox protocol, so the video memory can be shared by multiple COGs and it already has enough QoS built in so that any video COG using the memory can always take priority and not be impacted by other COGs accesses done in parallel. It's all working pretty well so far.
It can do arbitrary block copies between hub and external memory, or external to external, and also read and write individual bytes/words/longs etc. It also supports byte/word/long pattern fill operations, as well as graphics oriented copies and fills where the scan line pitch is needed.
Toolchains could readily be developed to utilize external memory. A filesystem layer that sits on top of my memory driver would also help here and could also be setup so you could have compiler work being done using file oriented read/write operations and underneath it could be translated into memory operations using a memory mapped filesystem. I think that would be useful for tools and help abstract them somewhat from the memory implementation as well. Some work may have already started in that area...