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

Comments

• JonnyMac Posts: 8,923

  2020-12-27 06:55 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
• ozpropdev Posts: 2,791

  2020-12-27 09:41

  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
  
  
• octetta Posts: 123

  2020-12-27 15:47 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
• octetta Posts: 123

  2020-12-27 17:48 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.)
• potatohead Posts: 10,253

  2020-12-27 19:16

  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.
  
  
  
  
• octetta Posts: 123

  2020-12-27 21:01 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