HDMI 4-Channel Oscilloscope Demo

1235

Comments


  • It'll be revision C.

  • Hi Chip!

    I have a question about the HDMI specifically. Is the image buffered? I can see that it's 640x480@60Hz - how many bits/pixel? Can the p2 do a full image buffer where a user could set/address individual pixels? If so, it wouldn't be that difficult to apply a graphics engine like we used with the OLED display and allow users to draw shapes/text/etc.
  • RaymanRayman Posts: 11,504
    edited 2019-12-10 - 17:57:00
    I'm not Chip but...

    Yes, images is buffered in HUB RAM. At 8bpp or less, the full image fits in HUB RAM.
    Yes, graphics engines can be done.

    I've actually done some already for the FPGA version... Have to dust those off soon...

    BTW, HDMI works the same as VGA under the hood, so it's easy to make a driver that works for both.

    BTW2, HyperRam should enable 24-bit color (and higher resolutions for VGA).
  • When questions can be answered by people other than Chip (like Rayman just did) we will all benefit. We have to externally manage his time, where possible.

    We need him focused on Spin2 right now.

    Thanks,

    Ken Gracey
  • It'd be interesting to see XY mode scope mode with the various DAC output modes...
  • AJLAJL Posts: 348
    edited 2019-12-12 - 23:47:46
    Rayman wrote: »
    It'd be interesting to see XY mode scope mode with the various DAC output modes...


    Why stop at XY? Why not have XYZ mode with the Z axis represented by colour?

    Addit: I'm open to ideas for representing the fourth channel too. I guess two sets of XY with different colours to differentiate the sets would work.
  • Neat idea, XYZ mode, I like it

    You could have the Z axis fade as it recedes like they do in some games ("fog"). Intensity cue the signal as it comes forward towards the viewer.

    Alternatively you could do like they do in Rhino cad, where there are typically 4 views on the screen at once - one from arbitrary angle (eg iso), then plan and a couple of elevations (XY, XZ, YZ).

    P2 is going to be great for such visualisation

  • You could do Hue and Saturation (or brightness) as well as X,Y, making four channels.
  • Peter JakackiPeter Jakacki Posts: 9,831
    edited 2019-12-13 - 04:44:43
    MattMatz wrote: »
    Hi Chip!

    I have a question about the HDMI specifically. Is the image buffered? I can see that it's 640x480@60Hz - how many bits/pixel? Can the p2 do a full image buffer where a user could set/address individual pixels? If so, it wouldn't be that difficult to apply a graphics engine like we used with the OLED display and allow users to draw shapes/text/etc.

    I did this last year with the VGA 640x480x8 in TAQOZ with ploting, rendering fonts, drawing lines and boxes etc as well as displaying bmp graphics and 320x240 movies scaled to 640x480.
    To draw a red panel at 40 x 40 y by 200 wide and 100 high, this is the syntax I use:
    40 x 40 y 200 w 100 h red panel
    

    But no, it's not buffered as the VGA 80bit color requires 300kB, however if you drop the bpp or introduce color tiles then you can certainly have it buffered.
  • @MattMatz If you have access to external HyperRAM and a P2 you should very soon have a full screen full bit depth frame buffer with VGA/DVI outputs that other COGs can access for doing interactive frame buffer based graphics. That is being developed right now.

    Also even though you can still get or set individual pixels in external memory the latency is far higher than HUB RAM so wherever possible in your application the accesses to external memory can also be done in bursts for higher performance. For example a circle fill graphics routine could transfer blocks of suitable size/colours to each affected scan line in the frame buffer at the appropriate start and end x co-ordinates of the circle on that scan line. Once it gets going the burst fill to HyperRAM can be very fast, though not quite as fast as to HUB if setq is used with longs. That's as fast as things get.

    I think adding a fill routine (i.e. write with a single value) as part of the HyperRAM driver makes sense too. That way the calling COG doesn't need to setup its own line of that size and pre-fill it to do a simple block fill in external RAM. Same goes for block copy between HyperRAM regions, though that may need a dedicated scratch area of say 128 or 256 bytes.
  • MattMatz wrote: »
    Hi Chip!

    I have a question about the HDMI specifically. Is the image buffered? I can see that it's 640x480@60Hz - how many bits/pixel? Can the p2 do a full image buffer where a user could set/address individual pixels? If so, it wouldn't be that difficult to apply a graphics engine like we used with the OLED display and allow users to draw shapes/text/etc.

    It's 8 bits per pixel. There are a few streamer modes, luma8 and rgbi8, where no pallet is necessary in the LUT, in order to produce 256 or 32 shades of 8 different colors.

    Yes, you could make shape and line-drawing routines to display whatever you want in the 640x480 pixel array.

  • I finally got around to trying this demo. Looks great. :)

  • I got lost early in this example program because I don't understand these how the computation operates in the following instructions:

    COM scp_base = 52
    ...
    wrpin .scpmode, #3<<6+scp_base
    wxpin .scp_x, #3<<6+scp_base
    dirh #3<<6+scp_base

    I understand .scpmode and .scp_x. They get defined elsewhere. But, to me, #3<<6 + scp_base comes to:
    #3<<6 = shift %11 six bit positions left to yield %11000000, or 192
    now add scp_base (52) to get 192 + 52 = 244. Obviously that's not a valid pin number for the Prop-2. Where did I go wrong?

    I'm interested in how to set up the inputs for a 4-channel "scope" and use them to get 8-bit values from 3 or 4 inputs. No HDMI, no display, just data.

    BTW:
    1. This calculation should occur once in the program.
    2. This type of "complex" notation, with shifts, ANDs, ADDs, and so on confuses newcomers (like me) to Prop-2 assembly language. Please consider straightforward, non-computed, unshifted values for information such as pin numbers, bit masks, bit positioning, and so on. Strive for clarity. Experts on this Forum understand these things, but to someone getting started, they can be a time sink or a dead end. --Jon
  • AJLAJL Posts: 348
    edited 2020-06-03 - 21:44:54
    JonTitus wrote: »
    I got lost early in this example program because I don't understand these how the computation operates in the following instructions:

    COM scp_base = 52
    ...
    wrpin .scpmode, #3<<6+scp_base
    wxpin .scp_x, #3<<6+scp_base
    dirh #3<<6+scp_base

    I understand .scpmode and .scp_x. They get defined elsewhere. But, to me, #3<<6 + scp_base comes to:
    #3<<6 = shift %11 six bit positions left to yield %11000000, or 192
    now add scp_base (52) to get 192 + 52 = 244. Obviously that's not a valid pin number for the Prop-2. Where did I go wrong?

    This needs to be read as pins 52 (scp_base), 53, 54 & 55 (3 more pins). This allows all 4 smart pins to be configured and made active simultaneously.

    Building the shift and add into the value would require just as much explanation. What is really missing here is proper commentary to explain why the shift and add is there.
    The demo was written for a more experienced audience, but not revisited until now.
  • AJL wrote: »
    JonTitus wrote: »
    I got lost early in this example program because I don't understand these how the computation operates in the following instructions:

    COM scp_base = 52
    ...
    wrpin .scpmode, #3<<6+scp_base
    wxpin .scp_x, #3<<6+scp_base
    dirh #3<<6+scp_base

    I understand .scpmode and .scp_x. They get defined elsewhere. But, to me, #3<<6 + scp_base comes to:
    #3<<6 = shift %11 six bit positions left to yield %11000000, or 192
    now add scp_base (52) to get 192 + 52 = 244. Obviously that's not a valid pin number for the Prop-2. Where did I go wrong?

    This needs to be read as pins 52 (scp_base), 53, 54 & 55 (3 more pins). This allows all 4 smart pins to be configured and made active simultaneously.

    Building the shift and add into the value would require just as much explanation. What is really missing here is proper commentary to explain why the shift and add is there.
    The demo was written for a more experienced audience, but not revisited until now.

    There is a nice semantic ADDPINS operator now, but I think that didn't exist when the demo was written.
  • I have reviewed the example program Chip posted. But I've run into a problem interpreting the following portion of the code:
    COM     scp_base  = 52
    ...
    
    DAT		org
    
    pgm_scp		wrpin	.scpmode,#3<<6+scp_base	'init ADC/scope pins
    		wxpin	.scp_x,#3<<6+scp_base
    		dirh	#3<<6+scp_base
    
    		setscp	#1<<6 + scp_base	'enable scope channels
    

    The values for .scpmode and .scp_x get defined elsewhere and seem OK. But I must have missed something about the operation #3<<6+scp_base. Shifting 3 (%11) six positions left equals 192. Then add 52 for scp_base and the pin number comes to 244. That can't be right. What have I missed?

    I want to understand how to set up the four pins for analog measurements; no HDMI, no LCD, no LEDs, just the 8-bit ADC data and how to get the scope mode to work.

    For what it's worth:
    1. Usually in a program you aim to calculate the value of #3<<6+scp_base once. That makes code easier to read, understand, and revise.
    2. To help newbies such as me understand code such as #3<<6_scp_base would it be better to show the actual value and how the a comment to explain where the values come from than to put a roadblock in our progress? For me, simplicity and clarity are the keys to good examples. Thanks for your help. --Jon

  • @JonTitus
    Thank you for your post. This is where I have asked for some slow instruction and comments as to what is actually happening in the code. Too many assume that we ALL understand. There are many who try to help and help well but we are all learning. That is what I am doing. So if folks can comment clearly we can all understand.
    Thanks again.



  • @evanh
    Finally got some time to code. I am back on what you taught me.
    Moving forward.
    Thanks
  • msrobotsmsrobots Posts: 3,275
    edited 2020-06-04 - 01:49:04
    it is using #3 pins from scp_base upwards, so 52,53,54,55 and executing the commands on all smartpins simultaneously.

    wrpin, wxpin, dirh and setscp are executed on all of those 4 smartpins at the same time.

    one of the wonderful things the P2 can do. Pin Groups accessed with one PASM statement.

    And YES you could precalculate the value and store as constant or so. But better use ADDPINS in the future, it makes more readable code in Spin2.

    Enjoy!

    Mike
  • Chip usually writes quick routines for the more experienced to see what can be done. He leaves the rest for us to expand upon. It's probably the easiest way to get some of the quirky features that can do amazing things out there for us to experiment with.

    There's no way Chip would have time to write a full set of documented routines! We're great-full for the tidbits of info we get from him.

    BTW This scope mode was "sneaked" into one of the chip revisions. IIRC the first we knew of it was the code snippet :smiley:
  • evanhevanh Posts: 10,091
    edited 2020-06-04 - 08:35:09
    JonTitus wrote: »
    ... But, to me, #3<<6 + scp_base comes to:
    #3<<6 = shift %11 six bit positions left to yield %11000000, or 192
    now add scp_base (52) to get 192 + 52 = 244. Obviously that's not a valid pin number for the Prop-2. Where did I go wrong?
    That's one of the changes from revA to revB silicon. A lot of the documentation was written for revA. And in this case wasn't rewritten to give the new details, although there is short description in the instruction spreadsheet that Chip maintains alongside the main doc.

    In revB, pin instructions gained a second field that allowed setting of 1 to 32 pins at a time. The "S" operand nearly doubled in size from six bits to eleven bits.
    AKPIN S/#
    WRPIN D/#, S/#
    WXPIN D/#, S/#
    WYPIN D/#, S/#
    
    	S/#	%xxxxxxxx_xxxxxxxx_xxxxx_CCCCC_BBBBBB
    
    	C:	Contiguous span of pins - 1, eg: #0 is the single pin specified by base pin.
    
    	B:	Base pin number.
    
    The span wraps from P31 to P0, and from P63 to P32.
    
  • evanhevanh Posts: 10,091
    edited 2020-06-04 - 08:32:29
    Same effect applies to a large number of bit-bashing instructions like OUTH, DIRL, DRVC, FLTL ...

  • Folks: I still would like to know how this instruction works, how the bits shift, what gets added, and so on, step by step. I don't understand it.

    wxpin .scp_x, #3<<6+scp_base

    I understand comments about what the result does. --Jon
  • MJBMJB Posts: 1,198
    edited 2020-06-06 - 21:37:40
    JonTitus wrote: »
    Folks: I still would like to know how this instruction works, how the bits shift, what gets added, and so on, step by step. I don't understand it.

    wxpin .scp_x, #3<<6+scp_base

    I understand comments about what the result does. --Jon

    from above:
    WYPIN D/#, S/#
    
    	S/#	%xxxxxxxx_xxxxxxxx_xxxxx_CCCCC_BBBBBB
    
    	C:	Contiguous span of pins - 1, eg: #0 is the single pin specified by base pin.
    
    	B:	Base pin number.
    
    

    so CCCCCC == #3
    and
    BBBBBB == scp_base

    to get the #3 in the right place you have to <<6 shift it left 6 bit positions and add scp_base to it

    so this works here on 4 pins (n-1 = 3) at one go starting with scp_base pin number
  • Thank you MJB. Precedence follows different rules in Propeller assembly language than in C. Makes sense now. --Jon
  • MJBMJB Posts: 1,198
    JonTitus wrote: »
    Thank you MJB. Precedence follows different rules in Propeller assembly language than in C. Makes sense now. --Jon

    I am not using C. I rather work with Tachyon/Taqoz in the future and understanding PASM helps ;-)
  • @cgracey
    cgracey wrote: »
    How much crosstalk is there between non-paired pins? There is likely still some from the pcb and package. Digital outputs have a low impedance and probably aren't a good representation of an analog source. Maybe 50 ohms from digital output to ADC, or use a reduced drive mode.

    Very little between non-paired pins, but between paired pins, the crosstalk is at about -24dB, which is really high, about 4 bits down.

    I get this error. what am I missing? please
    Thanks
    1389 x 867 - 153K
  • It'll need an END to designate the end of the assembly code.
  • evanh wrote: »
    It'll need an END to designate the end of the assembly code.

    I have been out of the loop because of work. What do you suggest as the end and where?
    Thanks
  • evanhevanh Posts: 10,091
    edited 2020-09-16 - 04:33:17
    Tack on the END keyword at the end of the assembly code.

    EDIT: Have a read of JonnyMac's new topic - https://forums.parallax.com/discussion/172172/using-inline-pasm2-to-learn-pasm2

Sign In or Register to comment.