Shop OBEX P1 Docs P2 Docs Learn Events
What will you make with your P2? — Parallax Forums

What will you make with your P2?

KyeKye Posts: 2,200
edited 2015-01-31 00:14 in Propeller 2
When I get one of Parallax's FPGA boards I plan to take one of my CMUcam4 camera modules and see if the P2 is capable of capturing 640x480@30 FPS RGB565 video and displaying it using the VGA port.

What will you do?
«13

Comments

  • David BetzDavid Betz Posts: 14,516
    edited 2015-01-10 16:22
    Kye wrote: »
    When I get one of Parallax's FPGA boards I plan to take one of my CMUcam4 camera modules and see if the P2 is capable of capturing 640x480@30 FPS RGB565 video and displaying it using the VGA port.

    What will you do?
    I'm not sure if I will buy one of Parallax's new FPGA boards since I already have the DE0-Nano and the DE2-115 as well as some others. Hard to justify buying yet another FPGA board unless it is absolutely required to run the P2 Verilog code. In any case, my plan is to help with the porting of PropGCC to the P2. Beyond that, I'd like to port something like JavaScript or Python or some interactive language (anyone for Lisp?) to the P2.
  • Heater.Heater. Posts: 21,230
    edited 2015-01-11 07:17
    JavaScript. Yes. Espruino on the P2.
  • evanhevanh Posts: 15,852
    edited 2015-01-11 13:00
    I was going to build a special purpose power monitor that calculates and logs the energy used in individual ~100ms impulse events using the Prop1 with AD7400's attached. But it's not a battery application nor is it price sensitive and the Prop2 will be out before I know it ...
  • TubularTubular Posts: 4,693
    edited 2015-01-11 16:17
    Aside from work stuff,

    I'd like to try close range capacitive sensing, so the chip surface can be used somewhat like a 'touch pad'. A bit like the OFN on the Blackberry phones in the past. I had some success with the P1, but the cogs are all in a line resulting in more 1.5D than 2.5D sensing. If the prop2 cogs are in a pizza wedge formation, it could work well, or there could be too much metal on top.

    I'd like to try a generic breadboard where each column of pins is connected to the prop2. You can then use the p2's pin flexibility to deliver power, scope the current or signals. There's already a test board for this just waiting for a P2 silicon

    And finally I'd like to interface to a PC104 bus so it can work with embedded industrial systems. Since there should now be enough pins.
  • ElectrodudeElectrodude Posts: 1,652
    edited 2015-01-11 16:18
    Why JS? Lua is much simpler (especially the compiler) and can do everything JS can do just as easily (if not more easily, IMHO). JS's syntax is probably too complicated to comfortably fit a compiler in the P2's RAM.

    As much as I love Lua, I think Lisp would be a much better fit for the P2 than either JS or Lua for many of the same reasons Forth works so well on the P1, such as being trivial to compile and extend at runtime, except that Lisp is a high level language and arguably easier to use than Forth (if you don't mind the premature death of the parentheses keys on you keyboard). Also, unlike Forth, Lisp isn't a write-only language - in fact, it's the only language for which introspection really makes much sense, and it's the only high level language I know of that supports true self modifying code.

    I'd like to try writing a simple Infiniminer/Minecraft type game on the P2 using octrees and raycasting. My calculations indicate that it should get a get a good 20fps or 30fps with 12 render cogs at around 800x600 in narrow caves, but that number goes way down to probably less than 1fps in complex terrain like Minecraft's jungle biome (even without non-cubical blocks).

    I've found a good way to read an octree or a lisp cons with the hub streamer that will spend almost no time waiting for the hub, by telling the streamer to start reading at the beginning of the node or cons before calculating which part of the node or cons it actually needs. By the time it has figure out what part it needs, the whole node or cons will be in the streamer.
  • David BetzDavid Betz Posts: 14,516
    edited 2015-01-11 17:26
    Electrodude wrote: »
    Why JS? Lua is much simpler (especially the compiler) and can do everything JS can do just as easily (if not more easily, IMHO). JS's syntax is probably too complicated to comfortably fit a compiler in the P2's RAM.

    As much as I love Lua, I think Lisp would be a much better fit for the P2 than either JS or Lua for many of the same reasons Forth works so well on the P1, such as being trivial to compile and extend at runtime, except that Lisp is a high level language and arguably easier to use than Forth (if you don't mind the premature death of the parentheses keys on you keyboard). Also, unlike Forth, Lisp isn't a write-only language - in fact, it's the only language for which introspection really makes much sense, and it's the only high level language I know of that supports true self modifying code.

    I'd like to try writing a simple Infiniminer/Minecraft type game on the P2 using octrees and raycasting. My calculations indicate that it should get a get a good 20fps or 30fps with 12 render cogs at around 800x600 in narrow caves, but that number goes way down to probably less than 1fps in complex terrain like Minecraft's jungle biome (even without non-cubical blocks).

    I've found a good way to read an octree or a lisp cons with the hub streamer that will spend almost no time waiting for the hub, by telling the streamer to start reading at the beginning of the node or cons before calculating which part of the node or cons it actually needs. By the time it has figure out what part it needs, the whole node or cons will be in the streamer.
    I've always thought that a simple but fairly high performance Lisp might be possible even on the P1. It would be fun to experiment with a RT GC running on a separate COG. I'm afraid you've lost me though on your comments about octree and hub streaming. Would you care to explain in a little more detail? It sounds interesting.
  • ElectrodudeElectrodude Posts: 1,652
    edited 2015-01-11 18:31
    David Betz wrote: »
    I've always thought that a simple but fairly high performance Lisp might be possible even on the P1. It would be fun to experiment with a RT GC running on a separate COG. I'm afraid you've lost me though on your comments about octree and hub streaming. Would you care to explain in a little more detail? It sounds interesting.

    It's not necessarily for an octree - it would work for any small array that fits entirely in the hub streamer. I think Chip mentioned an instruction a while ago that would skip a given number of longs in the streamer. So, to do x := long[base][offset], using my own made-up instruction names because I forget the real ones (although I think they were specified somewhere): 
    setstream base ' makes streamer start reading at address base

' take your time calculating the offset

skipn offset   ' this is a real instruction, right?  Does it understand what to do when dest is 0?
rdlong x       ' stream version - takes first long in streamer



    A lisp machine probably would be possible on a P1 now that I think about it. A single cons fits in one long (two 15 bit pointers), and the other 2 bits could be flags, one for the garbage collector and one to indicate if this long is a cons or a 30 bit atom that can include pointers to other stuff and type information and such. I'm concerned though that it's going to be hard to fit any real lisp program inside the P1's RAM - in Tachyon, instructions only take up one or two bytes, but in PropLisp, each would take at least a long (a cons with a pointer to its function).
  • msrobotsmsrobots Posts: 3,709
    edited 2015-01-11 20:15
    Well - one thing (less realistic) I would like to do is to get GnuCobol running on the P2. Just fore the Hell of it.

    Its not so far away. By now GnuCobol transpiles Cobol to C or C++ using gcc. Unfortunately they need dynamic loadable modules in the current implementation, or I am to stupid to avoid that. Ncurses and BerkleyDB blow up stuff beyond P1.

    Another thing (more realistic) is a device you can install in or near your breaker box. Using them small clamp around wire amp-meters and the ADCs of the P2 a non electrician could install a kit like this without any danger. Some Pins for debug, sd and serial(xbee?) coms should leave 50+ pins for sensing current current behind the breakers.

    Automotive products. Some members here tried to use a P1 as ECU replacement and or monitor. I am quite sure the P2 will be nice to use here, faster, more ram, with analog/digital/smart pins and 16 cogs.

    CNC/3Dprinting/Industrial Control. Here the P2 can maybe get a foot in, since the P1 was just a little bit shy of being good enough. Any P2 will solve this problem and I see a lot of opportunity here.

    Solar arrays. Again having ADC on every pin is a bummer. I can see lot of stuff I will do with a P2 there.

    Using the P2 as 'programmable I/O controller' attachable to any other MC via various Protocols. The Ultimate extender. (well ...I better stop here)

    Enjoy!

    Mike
  • bartgranthambartgrantham Posts: 83
    edited 2015-01-14 13:25
    +1 to Javascript, Lua, and Lisp on the Prop2. I'm a fan of all three, and each has its strengths.

    I'd like to try decoding VideoCD level MPEG-1 (352x240, ~180KB/sec). Perhaps on one cog, if possible.

    Hacking up a software synth that mimics the old analog synths would be fun.

    Maybe play with building a Dash7 stack for low-power and low-bandwidth 433MHz mesh networking.

    Alas, I already have far too many projects/distractions to be able to 100% follow through on any of these, but it'll be fun to tinker.
  • ElectrodudeElectrodude Posts: 1,652
    edited 2015-01-14 15:03
    David Betz wrote: »
    I've always thought that a simple but fairly high performance Lisp might be possible even on the P1. It would be fun to experiment with a RT GC running on a separate COG.

    Challenge Accepted! I have a prototype of a concurrent (no pauses, no locks!) mark-sweep RT GC in its own cog in around 60 longs of PASM. It uses a byte (maybe could be nibble) metadata table that keeps immutable and GC data such as GC status (free/white/grey/black, type). VM cogs can only write to metadata if it's a free cell (the only type of cell the GC will always ignore). All allocations are exactly one long - two words (car, cdr) for a cons or one long for an atom. All mutable data (car, cdr, atom data, etc.) is kept in the normal part and all data immutable to VM cogs once allocated is in the metadata part. Right now, the top 1/2 of hubram is the heap and the 1/8th below that is metadata, but that can be changed easily. I still have 5 bits left (more will be used for types) in each metadata entry and 4 bits left in each normal cell entry. All free cells form a linked list pointing to each other - the VM cog (only one right now) takes cells off the tail and the GC cog sticks free cells on at the head. I have to add multiple allocation lists, one per VM cog, to avoid the need for locks when consing. I'll have to figure out how I'm going to have the GC cog deal with mainaining 7 separate allocation lists.

    It's completely untested at this point - I should probably do that. Something unexpected will probably come up in testing and make the GC twice as big and slow.
  • David BetzDavid Betz Posts: 14,516
    edited 2015-01-14 16:44
    Electrodude wrote: »
    Challenge Accepted! I have a prototype of a concurrent (no pauses, no locks!) mark-sweep RT GC in its own cog in around 60 longs of PASM. It uses a byte (maybe could be nibble) metadata table that keeps immutable and GC data such as GC status (free/white/grey/black, type). VM cogs can only write to metadata if it's a free cell (the only type of cell the GC will always ignore). All allocations are exactly one long - two words (car, cdr) for a cons or one long for an atom. All mutable data (car, cdr, atom data, etc.) is kept in the normal part and all data immutable to VM cogs once allocated is in the metadata part. Right now, the top 1/2 of hubram is the heap and the 1/8th below that is metadata, but that can be changed easily. I still have 5 bits left (more will be used for types) in each metadata entry and 4 bits left in each normal cell entry. All free cells form a linked list pointing to each other - the VM cog (only one right now) takes cells off the tail and the GC cog sticks free cells on at the head. I have to add multiple allocation lists, one per VM cog, to avoid the need for locks when consing. I'll have to figure out how I'm going to have the GC cog deal with mainaining 7 separate allocation lists.

    It's completely untested at this point - I should probably do that. Something unexpected will probably come up in testing and make the GC twice as big and slow.
    Wow! That's great work and you did it very quickly! I always have to mull these things over forever and even then come up with a fairly simple solution. Are you planning to write a VM as well? What about a Lisp compiler?
  • ElectrodudeElectrodude Posts: 1,652
    edited 2015-01-14 19:03
    David Betz wrote: »
    Wow! That's great work and you did it very quickly! I always have to mull these things over forever and even then come up with a fairly simple solution. Are you planning to write a VM as well? What about a Lisp compiler?

    Thanks! But it's still completely untested. Yes, I am planning to write a VM and a compiler; however, only 6000 or so cells isn't exactly a lot to do anything with, so I don't expect it to be much better than a toy (but also a proof-of-concept). I can theoretically address 32768 cells with the way I'm currently doing addresses - maybe I could implement some sort of virtual memory? (sounds really really slow). I think I'll write the first versions of the compiler in a subset of Common Lisp and make it print out textual DAT blocks, which I could then include in the spin file, and then use the same compiler on the propeller once it's done.

    Maybe it would be better to write two versions of the compiler - one in Spin and the other in PLisp. The Spin one would compile the PLisp one, and then the spin compiler object and the text version of the lisp compiler could be erased and the memory added to the Lisp heap (and this could be burnt into EEPROM). This bootstrap would be more complicated on the Propeller side but much simpler on the computer side - you wouldn't need a Lisp interpreter and a macro processor just to get a complete, valid Spin file that you could load into your propeller.

    I've sort of hijacked this thread at this point; I'll start my own thread when I make more progress (probably not for a few days). I still have a ton of reading to do about Lisp - I know a lot of theoretical stuff about it but must admit I've never actually written any real program with it. This is the perfect excuse for me to actually learn how to use Lisp.
  • Heater.Heater. Posts: 21,230
    edited 2015-01-15 00:25
    @Electrodude,
    Why JS?
    Because of Espruino. Espruino is JS interpreter written by Gordon Williams that runs on STM32 micro-controllers and some other devices. Espruino is very small and I'm hoping will fit in the P2 RAM space. https://github.com/espruino/Espruino. A bigger issue I think will be speed. JS essentially only has one number type 64 bit floating point. I'm not sure if Esruino optimizes to integer operations where possible like the V8 and other JS engines do. Seems unlikely.

    Because JS is my current fad. Has been for a while. Works in the browser, works as Chrome app, works in Qt, and on my servers and on my Raspberry Pi's. I don't want to ever have to use another language again.

    Which is not to say that Lua, Lisp, Python, Scheme and so on are not also cool. I look forward to seeing what people come up with.

    COBOL, hmmm...no so much.

    @Tubular,
    ...close range capacitive sensing, so the chip surface can be used somewhat like a 'touch pad'.... I had some success with the P1...
    Could you explain that a bit more? Sounds weird.


    Edit: Seems Espruino uses integers were possible:

    Espruino actually has separate types for integers and floats internally to cut down on calculation, however both are 64 bit.

    I'm sure I have read that it also switched to using only 32 bit int's where it can.

    The latest Espruino board (The Pico) only has 384kb flash, 96kb RAM so I think we will be fine on the P2.
  • Ym2413aYm2413a Posts: 630
    edited 2015-01-15 05:53
    I've been waiting a long time for the P2. I stopped counting a long time ago.

    I've been planing to to some DSP and audio stuff with the P2. Write a sound engine, emulate midi, simulate synths, do audio playback, decompress audio, etc.
    I'm also looking forward to playing around with the video objects people write.

    I'd like to see good GCC support too. I prefer GCC over SPIN.

    What I'm hoping for is a chip with some extra RAM (128k, 256k, 512k these are all nice numbers).
    8 or 16 cogs. (either works)
    and a simple instruction set. Nothing complicated and no need for extra instructions that waste silicon, only to have use in one or two applications.

    At this point, I'll just be happy to get any chip.

    --Andrew.
  • David BetzDavid Betz Posts: 14,516
    edited 2015-01-15 09:29
    Heater. wrote: »
    The latest Espruino board (The Pico) only has 384kb flash, 96kb RAM so I think we will be fine on the P2.
    Does it use ARM Thumb mode? If so, what fits in 384k of Thumb code might not fit in a 512k P2 since the P2 uses 32 bit instructions.
  • MJBMJB Posts: 1,235
    edited 2015-01-15 12:51
    LISP
    I am really curious, where this LISP (&LUA btw) will devellop.
    I started with LISP some 30 years ago on a CDC6000 mainframe ;-) - no punch cards!! - already with Terminal
    If I remember correctly max 20k cons cells :-)
    Then later did my Ph.D. on a Symbolics 3620 Lisp machine (8MB RAM, and huge 360MB disk) in 1987.
    Had it still until a few years ago, when the disk crashed ... :-((
  • TubularTubular Posts: 4,693
    edited 2015-01-15 13:06
    Heater. wrote: »
    Could you explain that a bit more? Sounds weird.

    Weird, yes. Attached are the results I got for sensing a light touch of the chip surface, then a 'heavy touch' (firm finger pressure), then backing off (light touch again), then removing. As you can see there's some drift and some filtering algorithm would be required. The cogs second from the end were the most suitable, from memory, so Cog 1 and 6 could be used to differentiate two ends of a 'scroll bar', for instance. My hope is prop2 could go much further than that if the cogs are in a wedge shape rather than linear array.
    pdf
    pdf
    cog_touch.pdf
    15K
  • David BetzDavid Betz Posts: 14,516
    edited 2015-01-15 13:20
    MJB wrote: »
    LISP
    I am really curious, where this LISP (&LUA btw) will devellop.
    I started with LISP some 30 years ago on a CDC6000 mainframe ;-) - no punch cards!! - already with Terminal
    If I remember correctly max 20k cons cells :-)
    Then later did my Ph.D. on a Symbolics 3620 Lisp machine (8MB RAM, and huge 360MB disk) in 1987.
    Had it still until a few years ago, when the disk crashed ... :-((
    I'm not sure I'm seriously suggesting Lisp as a viable development language for the Propeller. It's just an experiment I'd like to perform.
  • jmgjmg Posts: 15,171
    edited 2015-01-15 14:25
    Tubular wrote: »
    Weird, yes. ... My hope is prop2 could go much further than that if the cogs are in a wedge shape rather than linear array.
    P2 will likely have many more metal layers, so this type of curiosity will be harder to sense.

    ( I have seen a ring oscillator in programmable logic 'respond' to a touch of the package.)

    You could claim some sort of record for the highest number of transistors used to sense a finger, if using a P2 die as the sensor! :)

    However, there could be some practical use in 'Test mode' activation, if a 'thumb on the chip' was easily sensed.
    That could even be called "Thumb Mode" or "Thumb Code Activation" ? ;)
  • TubularTubular Posts: 4,693
    edited 2015-01-15 17:00
    Yes, but the metal might help by moving the sensitive spot right out to the pin pads and gold wires, which could give you nice x and y. It'll be fun to see which way it goes

    I did design up a strip of props at keyboard spacing, so you could make a keybaord using a few strips of them, Think 8 cores under every key... times 84 keys? 101 keys? Didn't get the pcb made unfortunately.
  • jmgjmg Posts: 15,171
    edited 2015-01-15 17:56
    That's a LOT of silicon :)

    Here is an example of state of the art in CapSense

    http://www.electropages.com/2014/07/mouser-energy-efficient-ultra-low-power-cap-sense-8-bit-mcus-touch-control/

    Claims "<1µA wake on touch average current and industry leading 100:1 capacitive sensing dynamic range" & Mouser have parts around $1.50.

    It may be better to use the P2 as a more conventional Cap Sense, on per-pin on a PCB rather than per-cog ?
  • william chanwilliam chan Posts: 1,326
    edited 2015-01-19 04:44
    Will P2 with it's 16 cogs be useful as a voice recognition chip?
  • Heater.Heater. Posts: 21,230
    edited 2015-01-19 07:16
    Tubular,

    But, I don't get it, what actually are you measuring when you do that weird thing?
  • TubularTubular Posts: 4,693
    edited 2015-01-19 14:24
    Squashed fingertips? Essentially its a capacitive prox sensor with a very short range
  • ozpropdevozpropdev Posts: 2,792
    edited 2015-01-19 17:49
    I plan to use P2's in engine management systems, test instruments and CNC control.
    Here's some pictures of a project that uses P1's for all of the above.
    Its a V12 model aircraft engine with electronic fuel injection. HUGE amounts of CNC work!
    So basically I use "propellers to spin propellers". :lol: Pardon the pun.

    attachment.php?attachmentid=112873&d=1421718369
    V12 108cc EFI model engine.jpg
    1000 x 751 - 250K
  • mindrobotsmindrobots Posts: 6,506
    edited 2015-01-19 17:53
    Ozpropdev,

    That is absolutely beautiful!!
  • Heater.Heater. Posts: 21,230
    edited 2015-01-20 04:13
    ozpropdev,

    That motor is stunning. Must be one of the most beautiful things I have seen on this forum.

    I can't imagine how many hours you have put into it.

    "Propeller's driving propellers", I love it.
  • ozpropdevozpropdev Posts: 2,792
    edited 2015-01-20 05:57
    Thanks Heater & mindrobots
    It's a team of 3 madmen and approx. 8 years of development.
    Currently working on a new water cooled upgrade. It looks even better!
    attachment.php?attachmentid=112878&d=1421761958
    My job is to test them,, collect and analyse data.
    Sadly this sometimes leads to catastrophic failures/blow-ups. :(
    Sigh, the roller coaster ride that is R&D.....
    v12 wc prototype.jpg
    1000 x 750 - 210K
  • potatoheadpotatohead Posts: 10,261
    edited 2015-01-20 06:50
    Awesome. Thanks for sharing.
  • potatoheadpotatohead Posts: 10,261
    edited 2015-01-20 06:53
    My plans include:

    Industrial automation. P1 chips may well be the start, depending on how it all times out.

    Some fun game computer thing with Baggers

    Bench top tool. Measure, collect data, etc..

    General purpose video display interface.
Sign In or Register to comment.