Shop Learn
Getting more out of the P2... — Parallax Forums

Getting more out of the P2...

cgracey wrote: »
Given the complexity of the P2, and the lack of inbuilt peripherals, what it really need is something like PSoC Creator.

Hopefully, P2 isn't so complex that people suppose everything must be configured ahead of time, before their main program runs.

Programs that dynamically reconfigure the hardware will get a lot more out of the chip.

Is that true? In most cases, I'd think the peripheral configuration is going to be static. Yes, there will be some neat designs that dynamically use the same I/O for different purposes, but I suspect that will be in the minority. Or are you talking about something else?
cgracey wrote: »
I think our core manual doesn't need to be that big. Examples can take lots of room, but descriptions shouldn't. Everything in the Prop2 is intended to be thoroughly understood and exploited. There are no black boxes inside.

Personally, I prefer having a simple code example accompany each instruction. Now, this might not be a big an issue with assembly language instructions, but I think it's indispensable for higher-level languages. Given the old adage of "a picture being worth a thousand words", a code example is the picture.
«13

Comments

  • In 99.9% of cases the configuration will be fixed at the point the PCB is laid out.

    Those customers that need targeting if the P2 is to see any volume sales, and hence survive, will not be interested in any sort of dynamic configuration.

    The ability of make a chip with your own mix of USARTs/SPIs/I2Cs/DACs/ADCs/PWMs/COUNTERs/... is the selling point. Today you have a chip that's a communications hub, tomorrow, using the same inventory, it's doing SMPSU duties. But these are different PCBs.
  • jmgjmg Posts: 14,820
    Seairth wrote: »
    cgracey wrote: »
    I think our core manual doesn't need to be that big. Examples can take lots of room, but descriptions shouldn't. Everything in the Prop2 is intended to be thoroughly understood and exploited. There are no black boxes inside.

    Personally, I prefer having a simple code example accompany each instruction. Now, this might not be a big an issue with assembly language instructions, but I think it's indispensable for higher-level languages. Given the old adage of "a picture being worth a thousand words", a code example is the picture.

    I fully agree.
    Wordy descriptions are prone to readers guessing the meaning.

    To me, good documents for areas like Smart Pins will have:
    * Descriptions with equations, that show the limit cases and dynamic range.
    The best equations are paste-able into a calculator
    * Tested Examples that can be cut/pasted into IDEs, & run.
    Those examples should be multiple, and cover both minimal possible, and full featured choices.

    For things like the smart pins, the examples can start in ASM, and expand to include Spin / C etc.
    ( I see ersmith already has a SpinP2 in very early form )
  • cgraceycgracey Posts: 13,627
    edited 2016-04-29 21:02
    People may know that they want P4 to be a PWM output, but only at a certain point in their program's execution. Before and after that, maybe they want P4 low or floating. Also, a lot of objects will need to configure pins for special purposes and then tightly control them from a cog. These are all run-time matters that wouldn't lend themselves to pre-configuration.

    The big problem with a nice pre-configuration app is that it could give people the wrong idea that such a thing is necessary. I remember back in the late 80's, I bought Borland Turbo Pascal and was reading all about how some insects have wings and others don't, but they all have legs. This was about inheritance and polymorphism. I just wracked my brain trying to figure out how I was going to write a parser and assembler using inheritance and polymorphism. It was a venture into insanity. I was building a taxonomy of op-codes and mnemonics, hoping that when I finally "got it", I would have some legwork already done. I thought that was just how everything needed to be done, going forward. Nothing I read indicated that it was just a scheme to provide some possibly useful feature, but, otherwise, standard programming practices were still the norm. That was a horrible experience and I think it's made me very apprehensive of trendy new tech.

    Mainly, though, objects are going to take control of hardware resources, and they will manage them. There will certainly be 'start' and 'stop' methods available for getting things going. If there was a configuration app, it would maybe be better at dealing with objects, as opposed to hardware resources; but, then, the hardware is simple to set up, really, and a call to a method is simpler than a preconfig screen.

    Okay, I could see such an app helping people get acclimated to the idea that multiple things can be going on at once. That would have some value for shifting mindsets in the P2 direction. It doesn't seem like something an advanced programmer would use, though. I could be very wrong, however.
  • jmgjmg Posts: 14,820
    cgracey wrote: »
    Mainly, though, objects are going to take control of hardware resources, and they will manage them. There will be 'start' and 'stop' methods available for the getting things going. If there was a configuration app, it would maybe be better at dealing with objects, as opposed to hardware resources. The hardware is simple to set up, really.
    There are many different levels of 'configuration wrapper'.
    The ARM approach I do not much like, uses an API to call lower routines.

    Other vendors have a side-tool more akin to a Graphical Calculator, or Configurator.

    Taking your PWM on P4 example, users run the Configurator, enter P4 and PWM Frequency and other desired features,
    and the tool pops up a few lines of commented assembler/C/Spin etc.
    (Better tools will also accept a paste of Assembler, and report back what that results in.)

    They then paste that into their project, which manages any "Before and after that," you mentioned.
    No API overhead, but it saves a lot of user time 'aligning bits in registers'.

    The closest thing in Prop-land to this, is probably ersmith's nifty interactive 'snippet level' Spin2cpp
  • cgraceycgracey Posts: 13,627
    jmg wrote: »
    cgracey wrote: »
    Mainly, though, objects are going to take control of hardware resources, and they will manage them. There will be 'start' and 'stop' methods available for the getting things going. If there was a configuration app, it would maybe be better at dealing with objects, as opposed to hardware resources. The hardware is simple to set up, really.
    There are many different levels of 'configuration wrapper'.
    The ARM approach I do not much like, uses an API to call lower routines.

    Other vendors have a side-tool more akin to a Graphical Calculator, or Configurator.

    Taking your PWM on P4 example, users run the Configurator, enter P4 and PWM Frequency and other desired features,
    and the tool pops up a few lines of commented assembler/C/Spin etc.
    (Better tools will also accept a paste of Assembler, and report back what that results in.)

    They then paste that into their project, which manages any "Before and after that," you mentioned.
    No API overhead, but it saves a lot of user time 'aligning bits in registers'.

    The closest thing in Prop-land to this, is probably ersmith's nifty interactive 'snippet level' Spin2cpp

    Okay. That makes a lot of sense to me. That would be very useful. I would use that, myself, because I can't always remember everything. What I really like about it is that it hands you the solution, not some black black connector.
  • cgracey wrote: »
    jmg wrote: »
    cgracey wrote: »
    Mainly, though, objects are going to take control of hardware resources, and they will manage them. There will be 'start' and 'stop' methods available for the getting things going. If there was a configuration app, it would maybe be better at dealing with objects, as opposed to hardware resources. The hardware is simple to set up, really.
    There are many different levels of 'configuration wrapper'.
    The ARM approach I do not much like, uses an API to call lower routines.

    Other vendors have a side-tool more akin to a Graphical Calculator, or Configurator.

    Taking your PWM on P4 example, users run the Configurator, enter P4 and PWM Frequency and other desired features,
    and the tool pops up a few lines of commented assembler/C/Spin etc.
    (Better tools will also accept a paste of Assembler, and report back what that results in.)

    They then paste that into their project, which manages any "Before and after that," you mentioned.
    No API overhead, but it saves a lot of user time 'aligning bits in registers'.

    The closest thing in Prop-land to this, is probably ersmith's nifty interactive 'snippet level' Spin2cpp

    Okay. That makes a lot of sense to me. That would be very useful. I would use that, myself, because I can't always remember everything. What I really like about it is that it hands you the solution, not some black black connector.

    That's also why I think it's important to get the intellisense functionality working in Code. For instance, it should be possible to type "pinsetm", then have intellisense lead you through each field in the mode expression. This, I think, will make direct programming of the P2 more accessible to people that might otherwise have just stuck with objects written by others.
  • evanhevanh Posts: 11,889
    Yeah! A config code generator. Great idea, good for everyone.

    It'll get so many more people over the complexity hurdle too. Prop2 now has a swath of far-off seemingly cryptic registers and many many new special instructions that the Prop1 never had. Thinking about the egg-beater is enough to get some sweating.

    There's no doubt, even if the symmetries and directness are still there, that the Prop1's simplicity is harder to see in the Prop2.
  • evanhevanh Posts: 11,889
    Seairth,
    I'd rather the time was spent on a config code generator, a separately compilable program, that the IDE would launch. With copy to clipboard and save to file being the means of transfer back to the editor.

    This allows it to be generically usable for more than just the Proptool.
  • evanhevanh Posts: 11,889
    It could even incorporate generous educational inline commenting to facilitate even quicker deployment and less error prone hardware usage.
  • evanh wrote: »
    Seairth,
    I'd rather the time was spent on a config code generator, a separately compilable program, that the IDE would launch. With copy to clipboard and save to file being the means of transfer back to the editor.

    This allows it to be generically usable for more than just the Proptool.

    Sure. But why not do both? Then we can provide everybody's "cup of tea"!
  • evanhevanh Posts: 11,889
    True, I want mine first though. :P
  • evanhevanh Posts: 11,889
    It almost feels like something the community could work on. Though, I'm probably only good for the data entry phase myself. I've never done any compiler work.
  • cgracey wrote: »
    People may know that they want P4 to be a PWM output, but only at a certain point in their program's execution. Before and after that, maybe they want P4 low or floating. Also, a lot of objects will need to configure pins for special purposes and then tightly control them from a cog. These are all run-time matters that wouldn't lend themselves to pre-configuration.

    I don't think I could disagree more.

    At the point you design your PCB you are going to connect P4 to some other hardware that needs a PWM signal, something like a bunch of MOSFETs to drive a motor. From that point on you are never going to want to turn that pin into a USART or DAC. That decision occurs before a single line of code is written and is set in stone (or rather copper and fibreglass).

    Setting P4 to be low (=0% duty cycle) or high (100% duty cycle) is still a PWM function.

    Even something as simple as an IO pin will never be exposed naked to the real world. It's always going to have protection and filtering on it which will forever make it an IO pin.
  • Let'd be blunt here...

    without a number of volume customers the whole P2 development process will end up as an entry in Wikepedia detailing a curious chip, with some interesting ideas, that never quite made it to the mainstream.


    Out of the box, the P2 occupies a strange middle ground between a traditional microcontroller and an FPGA. Look at the datasheet expecting to see a uC and you'll see a chip with few in-built peripherals, an average amount of memory and an unspecified performance. You want something to use as a communications hub? Sure it can do that BUT you'll have to write your own bit-banged USART code in assembler. Or pick something from a user contributed library and massage it to make it work in your design. So if you're going to have to write your own hardware why wouldn't you go the FPGA route? It's a path with a lot more history and resource. And multi-vendor support.
  • cgraceycgracey Posts: 13,627
    Let'd be blunt here...

    without a number of volume customers the whole P2 development process will end up as an entry in Wikepedia detailing a curious chip, with some interesting ideas, that never quite made it to the mainstream.


    Out of the box, the P2 occupies a strange middle ground between a traditional microcontroller and an FPGA. Look at the datasheet expecting to see a uC and you'll see a chip with few in-built peripherals, an average amount of memory and an unspecified performance. You want something to use as a communications hub? Sure it can do that BUT you'll have to write your own bit-banged USART code in assembler. Or pick something from a user contributed library and massage it to make it work in your design. So if you're going to have to write your own hardware why wouldn't you go the FPGA route? It's a path with a lot more history and resource. And multi-vendor support.

    I see your points. You may be right.

    FPGA's are really tedious to program. I'm only doing it because it will turn into a P2. It's rewarding, for that reason, but it's also very stressful. It's taken me all day to get back into the streamer block in order to add 4/2/1-bit modes. Software would be so much easier to deal with than this. Anyway, FPGA's are not something you can casually use, like a microcontroller. So, I hope we get to that niche you are talking about, between FPGA's and microcontrollers. We want to be close to an FPGA in flexibility and speed, but much easier than your average microcontroller to program. Maybe setup tools in the IDE are a big step to getting there.
  • Heater.Heater. Posts: 21,233
    What actually are you suggesting Brian?

    You are right, the Prop 2 will not be a common or garden traditional micro-controller. I'm very sure it was never intended to be. There certainly would be no point in Parallax trying to compete with all the existing MCU vendors with yet another "normal" MCU. Why would anyone buy it, from a little company that nobody has ever heard of when they can use their familiar PIC, AVR, MIPS whatever micro-controller. Parallax could never match them on price or performance anyway.

    No, the Propeller has to be different. It has to be able to do things that the others cannot, or do them more easily. Otherwise there is no point in the exercise at all.

    That "strange middle ground between a traditional micro-controller and an FPGA" seems like a good approach to me. As Chip says configuring an FPGA is a whole other world of complexity and time sucking tools.

    Yes functionality like UART, I2C, SPI, whatever will have to be written in software. I don't see that as a problem. Someone will roll their sleeves up and create whatever device(s) they need. Once it's done once everyone else gets to use them. I did not have to write a UART or SD card driver or external memory interface etc for my projects. I just use what is available.

    Will this plan be a success? Who knows?

    I am very glad there are people in the world crazy enough to try such things though.





  • evanhevanh Posts: 11,889
    edited 2016-04-30 11:37
    Reminds me of the old auto-detecting USB/PS2 and PS2/UART mouses. They had this dual personality on the same pins with trickery for handling the electrical differences.

    Both angles can be catered. The config code generator gives speed and certainty to regular setups and the hard-core hacker still gets to come up with obscure gems.
  • LeonLeon Posts: 7,620
    edited 2016-04-30 12:21
    Right from the start, XMOS has been touting their chips as FPGA replacements:

    http://www.xmos.com/news/3-aug-2010/xmos-customers-build-better-products-faster

    Parallax needs to do the same with the P2.
  • evanhevanh Posts: 11,889
    :) You're a hard case Leon. Maybe some of those accusations are deserved.
  • I think the PSoC marketplace would be better suited.

    More thoughts later; the other day job calls....
  • LeonLeon Posts: 7,620
    I'm just pointing out that XMOS has been successful with similar chips to the P2 and Parallax can learn from them. What is wrong with that?

    Prospective customers for the P2 will ask what advantages it has over the XMOS range, and Parallax had better be ready with some answers.
  • Heater.Heater. Posts: 21,233
    XMOS and PSoC are obvious comparisons.

    I might speculate that branding the P2 as an FPGA replacement might backfire. Those looking for an FPGA may skip over it because it's not an FPGA. Those looking for an MCU may skip over it because it's not an ARM.

  • Regarding P2 versus FPGA, does anyone have examples of products shipping with FPGAs where the P2 would be a suitable replacement? I'm just curious because my experience has mostly been for ASIC emulation in development and the parts we used were much higher end than the Altera parts that Parallax is using. I know that some cloud providers are looking at coupling similar FPGAs with their systems - I think that it's for machine learning applications.

    Here are some examples of interesting FPGA designs for DSP, but this doesn't appear to be a good fit for P2:

    http://www.andraka.com/gallery.php

    I've been involved with projects which use FPGAs for PCIe interfacing, but the P2 isn't going to due PCIe in software. I don't think that higher speed USB or gigabit Ethernet is going to happen in P2 software either?

    So I just don't have the experience. Do the lower end FPGAs ship in consumer products? Or is the interest more for industrial control? I thought it would be easier to think about P2 versus FPGA with some specific products in mind.

    BTW - for ASIC design a lot of companies are now using tools such as Simulink for DSP simulation and design. The tools spit out usable (but ugly) Verilog. They generate software versions as well - I've seen the latter used to generate C simulation models. This is just done to get chips out quickly - from concept to tapeout is less than a year. Once DSP designers learn how to use the tools, then they can generate a lot of verilog, and thoroughly test it. I know a guy that works on ~4-5 chip projects at once. The verilog code can be run in simulation, FPGA emulation, other emulation, and used for the actual ASIC design. It's all generated with block diagrams, and can be quickly simulated at that level to see that it meets the performance goals. The previously mentioned engineer is even able to use genetic algorithms for filter design. Just mentioning this because it doesn't match Chip's experience "FPGA's are really tedious to program." Not that I completely disagree with the sentiment, but for this type of DSP work I think the ASIC/FPGA design is easier than writing P2 code.

    (Reference http://www.mathworks.com/solutions/fpga-design/?requestedDomain=www.mathworks.com)
  • evanhevanh Posts: 11,889
    edited 2016-04-30 18:00
    Keith,
    No not a good fit for the Prop. As you said, block diagram style. Everything is pre-built for Lego style mix'n'match.

    Chip is making a lot of new features that aren't in any Lego set, and what little may exist as pre-built will come with a licensing arrangement and fixed interface that Chip has no control over (Something he's explicitly avoided) and potentially bloated too (C++ made a lot of software much much slower).

    So, Chip is grinding all the logic level possibilities as he comes to them. He's writing all the HDL by hand.
  • evanhevanh Posts: 11,889
    edited 2016-04-30 18:06
    Parallax will be in a position to reuse substantial chunks of this effort for any future Prop designs. Eg: A smaller, lower power version wouldn't be a revised Prop1 but a cut down Prop2.
  • kwinnkwinn Posts: 8,693
    Heater. wrote: »
    XMOS and PSoC are obvious comparisons.

    I might speculate that branding the P2 as an FPGA replacement might backfire. Those looking for an FPGA may skip over it because it's not an FPGA. Those looking for an MCU may skip over it because it's not an ARM.

    So tout it as having the simplicity of an MCU with the flexibility of an FPGA ?
  • evanh - I wasn't saying that Chip should use those tools for processor design. I'm just pointing out that they exist, and allow design to be done at a very high level. They are generally used to generate software or full-custom logic. The solutions are not at all cookie cutter designs - much is done at to optimize for power and cost. (e.g. analysis to determine the necessary bit widths at various stages, insertion of clock gating, trying out different architectures,...) I've seen someone design a prime factor FFT engine in Simulink, but that one was hand converted to RTL.
  • KeithE wrote: »
    ..., does anyone have examples of products shipping with FPGAs ...
    Not with fpga but cpld, and I used it many years ago, now discontinued I think also from many years, it was an 8032 based MCU from ST: http://www.promelec.ru/pdf/uPSD34.pdf
    I still have 20pcs more or less.
  • jmg wrote: »
    cgracey wrote: »
    Mainly, though, objects are going to take control of hardware resources, and they will manage them. There will be 'start' and 'stop' methods available for the getting things going. If there was a configuration app, it would maybe be better at dealing with objects, as opposed to hardware resources. The hardware is simple to set up, really.
    There are many different levels of 'configuration wrapper'.
    The ARM approach I do not much like, uses an API to call lower routines.

    Other vendors have a side-tool more akin to a Graphical Calculator, or Configurator.

    Taking your PWM on P4 example, users run the Configurator, enter P4 and PWM Frequency and other desired features,
    and the tool pops up a few lines of commented assembler/C/Spin etc.
    (Better tools will also accept a paste of Assembler, and report back what that results in.)

    They then paste that into their project, which manages any "Before and after that," you mentioned.
    No API overhead, but it saves a lot of user time 'aligning bits in registers'.

    The closest thing in Prop-land to this, is probably ersmith's nifty interactive 'snippet level' Spin2cpp

    The Configurator also needs a report facility for the various configurations selected.
  • TubularTubular Posts: 4,414
    edited 2016-05-01 05:18
    Is it just me that fails to get excited by the prospect of a configurator?

    I understand their necessity on other micros, where there might be crossbar limitations or rules that must be adhered to, but P2 won't be similarly confined.

    We'll certainly need examples of common configuration modes, which is no problem and doesn't need a tool

    I guess its not a big deal either way. Perhaps a visualisation/configuration tool that runs on the P2 itself could be interesting
Sign In or Register to comment.