Shop OBEX P1 Docs P2 Docs Learn Events
The problem, problem — Parallax Forums

The problem, problem

Graham StablerGraham Stabler Posts: 2,510
edited 2007-03-04 05:56 in Propeller 1
It strikes me that many of us have the same problem. We have a problem we want to solve and it requires that we learn something about a topic in order to solve it. However because we only want to solve that problem we don't really want to give the topic the time it deserves and would get if it were the thing we were really interested in.

For me this applies for CPLDs, I have a problem, how to get lots of data from a camera chip into a ram chip at high speed. The CPLD can do the job; the manufacturer is selected, the demo-board purchased and introductory texts read but I'm a long way from programming the thing to do this fairly complex task.

Do I go off on a tangent and learn about CPLDs in their own right or just try and do the big project straight away as my first CPLD venture?

Back to the point, I think that the same thing is also true of propeller assembly for many people on the board, they just want to get there robot doing its thing or there CNC machine moving, assembly seems like a side line and a distraction.

So my question is: does anyone have any advice for people working on projects with many disciplines rolled into one, how do you know how much time to spend on the side topics to ensure you know enough that you can do them properly while keeping momentum up on the main project??

Graham

p.s. My advice to would-be assembly programmers is break your program into tiny parts and do them one at a time, make sure you can check each bit. Things like getting the data in and out of the routine come first, then reading the inputs then writing the outputs. Then fill in the middle and you're done, and your fast as heck too!

Comments

  • al-spideral-spider Posts: 42
    edited 2007-02-28 13:49
    I dito that Graham .

    well stated

    this guy mike thinks everyone is a pro at this like himself!!!!!
    always putting some extra comments on his reply to many post ,this makes people not want to ask for help that need alittle..
    It's all good were just trying to learn this thing and be caeful at the same time , there is a small chance or getting hurt or destroying some thing ie. your computer ,prop,stamp,poping a cap and putting out and eye.
    So we ask for help for safty reason also.
    so PLEASE try to understand we need alittle help not angry,mad replays .

    THANK TO ALL OUT FOR TRYING (WERE SUPOSED TO BE HAVEING FUN FUN FUN. THIS SPIN CODE IS NEW TO MOST OF US.
  • Mike GreenMike Green Posts: 23,101
    edited 2007-02-28 15:13
    Graham,
    That's well stated and I don't have a good answer for your question. You just have to keep honestly asking yourself whether you're spinning your wheels on side topics vs. learning something that will be really important later on and save you time and effort in the end. I think that, over time, the effective people learn about themselves and how they work best and pay attention to that.
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2007-02-28 15:34
    Some things are easier than they look. CLPDs would be heavy going for me.

    Regarding your desire to download a camera to ram, the Vinculum chip can do exactly that. Parallax sells the chip. But in this case, you can buy a premade board powered by AA cells directly from www.vinculum.com with firmware developed and you can use an ramchip with a USB interface or a USB to SDcard holder. That should give you downloads of gigabytes.

    We all get bogged down with the desire to DIY everything ourselves. Have some fun along the way and enjoy the learning.· Seems I have had to abandon or postpone 9 out of 10 projects as too ambitious, but the knowledge is cumalative.· That I deeply enjoy and feel is the true value.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    "If you want more fiber, eat the package.· Not enough?· Eat the manual."········
    ···················· Tropical regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2007-02-28 15:48
    I'll second Graham's advice to assembly prorammers — well, any programmers and not just programmers, for that matter. In any job you're faced with, break it into tiny pieces and get each one working before going to the next.

    When i studied computer science in college, "top-down programming" was all the rage. In this methodology, you factor a problem from the general to the specific. In other words, to do A you need to do B and C, so write a program that calls subroutines B and C, leaving the details until later. Now to do B, you have to do D, E, and F, so more non-specific subroutine calls from B get included, and so forth until the whole program is written. All very academic and not a bit of fun, because you don't actually get to see anything work until you're finished. And then, if it's not right, the debugging task can be enormous.

    It took years to get the taint of top-down programming out of my system.

    Now it's bottom-up all the way. If I want to, say, write a program for a robot that uses a bunch of sensors, I'll write routines to read each one and test each routine individually until it works. Then I'll do the same with controlling the motors. And finally, only after all the pieces are working, I'll integrate the individual routines into a complete system. The advantage is that you get to see stuff work (or not) from the get-go and don't get overwhelmed by the enormity of the task at hand. Plus, by building upwards with pieces that work, there's little, if any, debugging to do at the end. But, most importantly, it's just more fun to work that way!

    In a lot of projects I've finished, if I had known ahead of time how big they were going to be, I might never have started them. I credit bottom-up design and its enforced myopia for keeping me on task in cases like these, and I recommend the technique wholeheartedly.

    -Phil
  • Beau SchwabeBeau Schwabe Posts: 6,560
    edited 2007-02-28 16:05
    Phil,

    The same analogy of bottom-up design can be applied to IC layout, however you must also consider the top-down approach at the same time. The FUNdamentals of a design from the bottom-up
    are definitely the most important, but depending on circumstances that might dictate where your overall design will be implemented, it's also a good practice to at least outline the top-down design
    restrictions so you can meet somewhere in the middle.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Beau Schwabe

    IC Layout Engineer
    Parallax, Inc.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2007-02-28 16:40
    Beau,

    True enough. You always need to keep your eye on the overall objective. And with chip layout, I imagine it's a lot harder to test the little bits as you go along! An analogy that more of us can relate to, perhaps, would be circuit design and PCB layout. The bottom-up part is selecting the components. The top-down part determines where the components are placed on the board to minimize trace lengths, vias, and noise. Meeting in the middle is where the actual routing takes place.

    -Phil
  • mike101videomike101video Posts: 43
    edited 2007-02-28 16:44
    Top down design - so you know what you need.
    Bottom up implementation - so you know you are building on well tested code.

    (It's what I always liked about FORTH - you build and test WORDs interactively and then use them.

    Helps with a Prop when you can put that unit of tested code in its own cog and reduce interaction issues.
  • Graham StablerGraham Stabler Posts: 2,510
    edited 2007-02-28 16:59
    Mike, I think you are quite right, you have to be honest with yourself, is the sideline just to avoid doing the real task or are you just resisting learning something new in case it never comes in handy again. Its all experience.

    Kramer, not just a single image but many from a 188X120 array running at 250fps. A Xilinx app note explains about interfacing with micron DDR SRAM, I can get a single chip 1Gb unit that will store 23 seconds of video if I cut the 10-bit camera output down to 8-bit (ignore two lsbs). Then it will be downloaded to the vinculum (which I have two of already). I have the camera chip so first step is some comms and then a slow image download to test.

    Phil, so very true and worth adding to my list of rules for life, the first is "what would Sam Beckett do?".

    Beau, I guess you need to know where your top is before you can work up to it [noparse]:)[/noparse] There is a lot to be said for explorative work finding out where the solution lies before stepping slowly towards it.

    Graham
  • Paul BakerPaul Baker Posts: 6,351
    edited 2007-02-28 17:56
    Some people swear by top down design (project managers typically) and others swear by bottom up (the engineers typically), but you really do need to do both simulataneously; and the part you start with is the one you understand the least about. So if your good at the nitty gritty, start with an organizational diagram. If your great at defining top-down, start by implementing the trickest individual feature. By doing this you will attack the pitfalls of the design head on and understand what obstacles you need to overcome in order to accomplish your project before you get to the point where you have a monolithic system and find it doesn't work.

    Top down is critical in team design, but it still has a role in individual design. You need to understand how the pieces of the jigsaw will fit together, but once you have a general understanding of how they will fit you can start painting the individual pieces.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Paul Baker
    Propeller Applications Engineer

    Parallax, Inc.
  • cgraceycgracey Posts: 14,133
    edited 2007-02-28 18:08
    I've found that after some initial skeletal conceptualization of a project, it's·99% bottom-up efforts. Bottom-up developments often influence the high-level picture as realizations are made about what's possible.·This is how I've done everything and trying to avoid details has NEVER worked.

    I always wind up having to learn a lot more than I initially thought I would, usually to the point of·knowing every aspect of whatever sub-discipline was in question. It's time-consuming, but I don't think it's possible to·do the best job,·otherwise. Besides, it's rewarding and teaches you a lot. I love the feeling of knowing that a 'part' of some design I'm working on is now completed to the point of·perfection, and there is no small voice in the back of my head suggesting otherwise. I really listen to my guts. Until they're settled, I KNOW that something is wrong, even if I'm not sure WHAT. If there are·any unsettled feelings, they indicate that more attention will be·required later, if not now, and 'now' is always better because only·then will I be able to move·forward confidently to whatever the next 'part' is. I also avoid using any tools that make decisions FOR me. The only exception has been the Altera FPGA compiler. For the purpose of proving logic which will later be redesigned by hand, it's useful. But, if I don't have a complete understanding of something, I won't use it in a final design.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


    Chip Gracey
    Parallax, Inc.

    Post Edited (Chip Gracey (Parallax)) : 2/28/2007 8:38:31 PM GMT
  • rokickirokicki Posts: 1,000
    edited 2007-02-28 18:09
    Another issue to consider is *why* you're doing something. For me everything I do on the propeller is motivated strictly by
    enjoyment, and not at all by shipping a product. This means I will do the parts I most *enjoy* first, and then if sufficiently
    motivated (by, perhaps, other people saying, that's cool, I want that, can you make it do this too?) perhaps I do the less
    fun parts.

    Graham, a bunch of us may be working with CPLDs. What board have you purchased? This has little to do with Parallax,
    perhaps, so perhaps this isn't a good forum for discussion, but I'm sure we'd all be interested in how things go. I'm currently
    using the Spartan 3E kit (which has both a CPLD and a rather large FPGA on it).
  • Tom WalkerTom Walker Posts: 509
    edited 2007-02-28 21:35
    Time to jump in since this thread's already rockin'...

    I agree with most of what has been said thus far, but my concern is that there seems to be an assumption that "thinking" about a problem is a natural thing. Quite a few of the questions on these fora seem to me to not have been given enough consideration before they were posted...which leads me to wonder if perhaps there needs to be more education in how to effectively dissect a problem. Per Phil, this seems to parallel the "experience curve".

    For example, if you have a defined goal (i.e. "top-down"...ignoring "homework" questions <grin>)...
    Too many times, the question is "How do I get my 'bot to roam around a room without bumping into things?". Anyone who has solved a similar problem will tell you that there are many parts to that question, each spawning its own set of questions. Can you move at all (and how do you)? What sense(s) do you have (and what do they really "tell" you and which way do they "look")? ...and the list goes on until, eventually, you are looking at a small problem that can be defined ("a properly defined problem almost always presents its own solution"), researched and solved. This applies as much to code as to hardware. Even something as simple as asking "how would I, as a human being, go about doing the same thing?" can help, if you can break down a problem into its smaller problems.

    As you learn the individual parts (be they hardware, code, or their interaction), you start looking at putting them (and their synergies) together and gain an understandig of how their assemblies can be used to solve small problems...and eventually you start to think of the smaller bits first and then how to put them together to reach some goal.

    I understand being "new" to some particular technology, but there still seems to be a lot of repeated "ground covering" due to little thought being given to what is (or is supposed to be) happening on basic levels...which does NOT require technical knowledge.

    <rambling_flag=OFF>

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Truly Understand the Fundamentals and the Path will be so much easier...
  • Graham StablerGraham Stabler Posts: 2,510
    edited 2007-02-28 22:06
    One thing it is sometimes hard for the oldtimers to remember is that it takes a certain amount of confidence to even try. I bet Chip will pick up any datasheet or manual and say "here we go again", for young whipper snappers or those people working in a different disipline to usual or those who have taken some knocks in confidence it can be hard to even try. Trying however lets you ask a good question.

    rokicki,

    I have ordered the new coolrunner II starter kit, its only $50 and there are lots of app notes for the coolrunner series. Its just a CPLD which is all I want right now, I'm still amazed by what they can do. Equally off topic, I have been reading the micro DDR SDRAM datasheet and well, it could be a lot worse. Things that I know BTX was worried about such as keeping the memory refreshed are done on chip with a command. I'm sure Chip, Paul, Beau, Mike, Phil etc could whip it into shape in no time. Me, I'll take a bit longer but I might just get there.

    Graham
  • cgraceycgracey Posts: 14,133
    edited 2007-02-28 22:26
    Tom Walker said...


    "a properly defined problem almost always presents its own solution"

    Right on.
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


    Chip Gracey
    Parallax, Inc.
  • Graham StablerGraham Stabler Posts: 2,510
    edited 2007-03-01 01:08
    And I suppose that is because there is a fundemental limit to how hard an element of any problem can actually be, break it down far enough and rocket science is just adding up. Defining the problem is putting your brain in the "problem's space". In computer games the problems are in your face and they all have solutions, in the real world it is normally a lot of work getting on the shoulders of the relevant giants to even see the problem.

    Graham
  • Dennis FerronDennis Ferron Posts: 480
    edited 2007-03-01 19:54
    Graham Stabler said...
    And I suppose that is because there is a fundemental limit to how hard an element of any problem can actually be, break it down far enough and rocket science is just adding up. Defining the problem is putting your brain in the "problem's space". In computer games the problems are in your face and they all have solutions, in the real world it is normally a lot of work getting on the shoulders of the relevant giants to even see the problem.

    Graham

    Case in point - I spent the first month of my NASA internship not building my project, but just figuring out WHAT to build. In fact the rest of the team I am on is actually still hashing out the details what it is that we need to build as a group; in that month I simply identified a smaller part of the problem which everyone agreed would be needed in the final solution, and I got started.
  • rjo_rjo_ Posts: 1,825
    edited 2007-03-02 23:46
    Graham,

    I think I understand your question well to offer something. In my experience, there are no CPLD's. But, from the standpoint of system integration and being an individual trying to deal with the products of large corporations, which corporations would not ordinarily consider me as part of their target audience, I have about 25 years+. The problem with all products is that they are intended to serve a market... the sharing of info and technical help from company to you greatly depends upon whether you are part of a target audience. With a CPLD all you have to do is run into one problem that you can't solve and the supplier doesn't care if you solve and your project is toast.

    I personally like the FPGA approach because FPGA's come with lots of examples and there is probably an application example that would serve your needs... FPGA's are going to be around forever and even if you fail in a specific application... chances are that your work won't be wasted. Whatever you learn, can be applied generally to other projects.

    I have a number of advanced imaging application, all choked up in my brain, and I wanted to nibble away at them. My choice was to dig into the FPGA world or into something like Prop hardware.

    Personally, I think that anyone who uses a prop should at least attempt to translate everything into assembly...learn that chip inside and out. I don't think of the Propeller so much as an evolutionary step in chip design ... but the beginning of a paradigm shift in the way we think about dedicated computing.

    For real projects the question is time... how much time do you have for the project... how much time do you have to absorb information. And the issue is certainty... can you be certain that a given approach will actually yield what you want in your hands within the time constraints that you live with.

    Rich
  • Graham StablerGraham Stabler Posts: 2,510
    edited 2007-03-03 00:17
    A CPLD is just like a small FPGA, both (can be) programmed in VHDL and both operate very similarly. The software used for both is the same with Xilinx products. I really don't get your point about problems I can't solve, there is also lots of example code for the CPLDs as well.

    Perhaps you are confusing a CPLD with something else.

    The propeller can do most of what I want but not all, the CPLD will do what it does best while the prop oversees things and adds an interface.

    Graham
  • rjo_rjo_ Posts: 1,825
    edited 2007-03-03 00:35
    Graham,

    I did say that "I thought" I understood the question. So, if CPLD's can be programmed and FPGA's can be programmed... and they are both programmed in the same language... what's the difference?

    Rich
  • rjo_rjo_ Posts: 1,825
    edited 2007-03-03 00:39
    Oh... Graham,

    The other thing... I have been looking for something that I thought the Propeller couldn't do... and I can't find it. Although some things would obviously have to wait for the new chip. Possibly you are trying to do something and you don't think it could be done with a Propeller but it actually can or possibly you are looking at more complicated problems than I am... any hints?

    Rich
  • Graham StablerGraham Stabler Posts: 2,510
    edited 2007-03-03 00:51
    http://en.wikipedia.org/wiki/CPLD

    Smaller, has non volatile internal memory and are very economic, great for just cleaning up glue logic into a monolith or really fast stuff. You can even get free code for an embedded processor if required.

    I explained the application in the first post. Perhaps one day a propeller will be able to do that but not today and not for the next chip I may be using.

    Graham
  • rokickirokicki Posts: 1,000
    edited 2007-03-03 00:56
    Can you point me to a reference for embedded microprocessor cores inside a CPLD? I wasn't aware that was possible in these devices.
    Certainly FPGAs (which are architected for this), but CPLDs seem to have restrictions that would make this not possible.
  • rjo_rjo_ Posts: 1,825
    edited 2007-03-03 00:58
    Graham,

    Hmmmmm..... we might have our first serious disagreement.

    Specify a bandwidth... and I'll bet it can be done.

    offline?

    Thanks for the info... about 15+ years ago I implemented an algorithm in Pascal... pretty memory intensive. And we were planning to move it over to an FPGA...when one of our finer branches of the military hired my programmer. I guess the development sequence would be to move it to an FPGA and when was optimized in a variety of contexts move the solutions over to a series of CPLDs. Except that I'm pretty much convinced that I can squeeze it all into a Prop array... and I'm thinking that I might be the only one who could do it.

    Rich
  • rjo_rjo_ Posts: 1,825
    edited 2007-03-03 02:05
    Graham,

    Let's define bandwidth in pixels/sec * the epsilon of (machine instructions per pixel *cycles per instruction)

    Rich
  • rjo_rjo_ Posts: 1,825
    edited 2007-03-03 02:09
    which would define the topology... from which one can generate the hardware expense, which could be compared between revisions...and allow you to calculate a timeline.
  • rjo_rjo_ Posts: 1,825
    edited 2007-03-03 02:12
    which would allow you to compare hardware expenses, impact of revision and estimate your timeline.
  • Graham StablerGraham Stabler Posts: 2,510
    edited 2007-03-04 01:32
    Rich,
    You should edit your first post if you want to add further details rather than post multiple one liners, it ruins threads. The pixel clock is 26Mhz, the prop won't be able to do all the stuff required to control the memory in the time available simple as that, the other camera I want to use has a >>100Mhz clock. Andre' is using a CPLD in his RAM module btw. You would also not move a design from an FPGA to a series of CPLD, I can't see why. This is now off topic so can we drop it.

    rokicki,

    http://www.xilinx.com/bvdocs/ipcenter/data_sheet/picoblaze_productbrief.pdf

    I know nothing of the detail I just ape what I read.

    Graham
  • rokickirokicki Posts: 1,000
    edited 2007-03-04 05:56
    Wow, I had no idea the CPLDs were large enough now to do processors; I thought that was limited to FPGAs! Excellent; thanks for the reference!
Sign In or Register to comment.