Shop OBEX P1 Docs P2 Docs Learn Events
P2 Spin2 Object for Processing IDE - can somebody claim this project? — Parallax Forums

P2 Spin2 Object for Processing IDE - can somebody claim this project?

Hey there, at the recent P2 Live Forum where Chip presented analog inputs there was significant discussion about Processing IDE.

https://www.youtube.com/watch?v=XaROvYh7bho&list=PLt_MJJ1F_EXa25_TWa4Sdi77daQaxA_ZU&index=3

Much of the focus was that Chip duplicates an existing effort with his graphical debug displays, but the more interesting part is bringing the Processing IDE into the P2's world. Having either an object or some examples that use Processing's graphical displays could widen the P2 audience to Processing users who do not already use the P2. What advantage would the P2 bring to Processing?

- simple examples with common Parallax sensors, to show the serial setup required and provide a gentle entry
- graphing of many simultaneous analog inputs
- CORDIC or trigonometric functions in 3D space
- DAC or audio applications

JonnyMac can do this, but should he? He has already produced a serial object which would do most of the work. JonnyMac has already given us so many good examples to work from and we can't wear him down with yet another responsibility.

It seems that somebody in our P2 community would be interested in taking this effort on. Anybody interested?

Where would the work go to be shared with the community? We're working on a new section of the website for the P2 called either "Examples" or "Quick Bytes". We'd host it there, along with any associated examples.

I challenge the P2 community to take this effort on.

Ken Gracey

Comments

  • JonnyMacJonnyMac Posts: 9,104
    edited 2020-12-27 06:55
    I have an interest in Processing so I will chime in, too, but it would be nice if we could get a bunch of folks producing interesting visual demos with Processing taking serial data from the Propeller.

    I found Carol's Ping project that she mentioned on the stream. Her code doesn't have a lot of comments, but seems pretty straightforward.
    -- https://github.com/CarolHazlett/Interactive-Graphic-Sonar-Array/blob/master/GraphicSonarArray
    -- https://github.com/CarolHazlett/Interactive-Graphic-Sonar-Array/blob/master/SonarArrayStream
  • Here's some code to kick start experiments.
    This code simply duplicates (clones) the debug output to a seperate propplug so the data can be captured by the processing software.
    {
    Eval    Propplug
    gnd     vss
    P48     res
    P50     <TX
    P52     >RX
    }
    con
            _clkfreq = 180_000_000
    
    pub main()|x
    
            coginit(cogexec_new,@clone,0)
    
            x~
            repeat
                    debug(udec(x))
                    waitms(1000)
                    x++
    
    dat     org
    
    clone           wrpin ##p_plus1_a,#61
                    rep   #2,#0
                    testp #61 wc
                    drvc  #52
    
    
  • octettaoctetta Posts: 125
    edited 2020-12-27 15:56
    On 12/23, I posted a response in the General Discussion thread (since I thought the micro:bit was the source instead of P2) to your challenge but didn't totally understand the ask. I won't be offended if that message gets moved here to help this effort.

    Anyway, the Processing.py code I posted has a Python serial port class that parses the data the micro:bit sends into native Python data.

    My path forward if y'all think it's useful is to expand this class to handle the variety of plot types Chip's DEBUG thingy produces, such that:

    A. Anything that can output to a serial port can talk to this class to easily get flashy graphs.

    B. Bridge the worlds between Parallax and Processing.

    C. Actually start using the P2 (I now have 3 and have only messed with TAQOZ on one of them... for shame). JonnyMac's efforts are very inspiring from both a functional and stylistic stance.

    D. I need to understand the "on the wire" format for what Chip's DEBUG sends. Easy to do, just requires me to figure out how to run PNut on non-Windows hardware (Wine/???). A side-effect is the possibility that I could make a micro:bit library to talk to PNut for graphing?

    One thing to consider is the Processing IDE, while able to support Python, is largely a C-language-ish community. Daniel Shiffman's books and videos present code in this language. I can easily code for either or both of these platforms, but don't have instincts on what the community is best served by. Suggestions?

    Happy Holidays y'all!
    -joe
  • octettaoctetta Posts: 125
    edited 2020-12-27 21:26
    JonnyMac wrote: »
    I have an interest in Processing so I will chime in, too, but it would be nice if we could get a bunch of folks producing interesting visual demos with Processing taking serial data from the Propeller.

    The first part any of Processing code will start from is the serial library*.

    My example below uses the Processing.py Python version of this library to open the serial port ("Serial(...)"), see if data is available on the port (".available()"), and read to the end of line delimiter (".readBytesUntil(10)"). The details for the Java version are at:

    https://processing.org/reference/libraries/serial/index.html

    (* Unless we add TCP/IP to the P2 somehow... hence my musing on the P2 Zoom calls about SLIP or PPP that has been fruitless on my part.)
  • Merry Xmas everyone! I have been reading with interest and still buried, right now getting a P1 product to market. Ken will have photos soon. (Sorry Ken, I promise next week)

    I have a random thought or two about this:

    I use Repetier Server with various 3D printers and part of all that is associating an IP address with a serial connected, usually via USB FTDI style, stream of G-code driven printer.

    Rather than add networking directly to the P2, or maybe while we wait for that, a debug server might be super useful.

    Secondly, I can't help but think of the Tektronix serial graphics.

    http://sites.science.oregonstate.edu/~landaur/nacphy/coping-with-unix/node140.html

    These things used a storage tube CRT and had up to a 4k x 4k addressible point, vector display.

    Here is a demo someone posted on You Tube:



    There were also full computers, like the one I used in the 80's to do sheet metal CNC programming.

    This debug stream capability runs right along these lines and should prove very useful.



  • octettaoctetta Posts: 125
    edited 2020-12-27 23:47
    potatohead wrote: »
    Secondly, I can't help but think of the Tektronix serial graphics.

    Hey Potatohead... I made a post about Tek mode of xterm a while back (although not driven by a P2).





    http://forums.parallax.com/discussion/171901/ab-use-of-xterms-tek4010-for-animation
Sign In or Register to comment.