• Category Archives Blog
  • The First Single-PCB Prototype, and Trace Cog Fix

    I’ve built probably about a dozen prototypes of the various versions of Propeddle over the last three years, but this is the first time that Propeddle has come alive by itself, on its own circuit board, without any assisting hardware (other than the power supply and the Propeller Plug). And I found and fixed the bug that I was talking about in the previous post, in the trace cog.

    It's a little bit of a botch with the added LEDs, rewired LDO's and other changes, but this is a Rev.11 Propeddle on a Rev.10 board.
    It’s a little bit of a botch with the added LEDs, rewired LDO’s and other changes, but this is a Rev.11 Propeddle on a Rev.10 board.

    Continue reading  Post ID 286

  • Wire Wrap Update

    A while ago, I announced here that I was considering making a wire-wrap version of Propeddle. The article is gone now: I kinda gave up on it because I was busy with lots of other things. But in the last few weeks, I started thinking about the idea again while I was working on the Kicad schematics, and decided to go ahead and make a wire-wrap version of Propeddle, based on the Parallax Propeller USB Proto Board, and the Human Interface Board.

    Don't you just love the wire pr0n? :-)
    Don’t you just love the wire pr0n? 🙂

    Continue reading  Post ID 286

  • The New Propeddle Kit Almost Ready!

    This is OSHPark's rendition of the Propeddle Rev. 10 PCB.
    This is OSHPark’s rendition of the Propeddle Rev. 10 PCB.

    As I mentioned before, I’ve been working on a version of the Propeddle kit that has everything included: Not just the 65*02, memory and glue logic, but also the Propeller (and it surrounding hardware), and the connectors. Once I learned how KiCad works, this wasn’t very difficult, though I think KiCad could use some improvements when it comes to moving parts and traces at the same time. The result is a PCB that’s slightly smaller than a 160x100mm EuroCard, so it should fit in many standard enclosures. Continue reading  Post ID 286

  • Find the Differences ;-)

    Propeddle PCB design in Eagle vs. KicadWhen I started working on Propeddle, I hadn’t worked with any electronic/PCB design software for a long time. To be precise, I think the last time I used Orcad was probably during my failed attempt to get an EE degree in 1986/1987. I learned how to use Eagle because it was used by many engineers, had a decent library and there were plenty of good tutorials around. Meanwhile, I’ve also learned Designspark PCB, and Kicad, and as I mentioned before, I decided that Kicad would be the program that I would use for Propeddle, now that I can no longer use Eagle.

    Continue reading  Post ID 286

  • Kicad Pro Tip for Importing Designs from Eagle

    After you use a script like Eagle2Kicad.ulp to export an Eagle design to Kicad, use the Kicad Library Editor to remove any symbols from the library that you created as power supply symbols. If you don’t, Kicad will be seriously confused.

    I had a few symbols for VCC and GND in my Eagle design for Propeddle because I didn’t like the symbols that Eagle uses. This got me in trouble with Kicad, without it letting me know about it.

    Continue reading  Post ID 286

  • Achievement Unlocked: Schematics Converted to Kicad and Posted on Github

    Propeddle kicad schematic
    Propeddle schematic, just after converting it to Kicad.

    I’ve been working on my Propeddle project for about three years now (on and off — mostly off), and one of the things that’s been on the to-do list for a while is to move the schematic from the free “Light” hobby version of Eagle to Kicad or some other electronic design program that will let me make the PCB bigger, and won’t take me to court for selling my design as a kit, and won’t cost me so much that I have to double the price for the kit to make up for the expense.

    I’ve tried the conversion before and it failed every time, and I couldn’t figure out why. I even tried other software besides Kicad (such as DesignSpark, which I really liked by the way) to see how much trouble it would be to just start over.
    Continue reading  Post ID 286

  • Of Baby Steps and Binutils

    Hello everyone!

    It’s been quiet for a while again in the land of Propeddle, so here’s a short update.

    A while ago, I wrote an in-depth article about Propeller programming in C, and because of this, I was invited by Parallax to write some documentation for the PropGCC official website. I agreed that I would contribute some articles, but first I want to get Propeddle in a more finalized state, so I can sell it as a kit, and hopefully give a presentation at the Propeller Expo next May.

    I’ve been rewriting the software in C and inline assembler for a while, and currently the code for the control cog is code-complete, and I’m ready to start debugging it with my Logic Analyzer.

    Unfortunately, however, I’m hitting a major snag. Although it compiles without warnings or errors, the machine language that gets generated by the assembler is wrong: the Gnu Assembler (GAS) for the Propeller apparently still has some major issues that apparently don’t affect the C compiler, but generates fixups that are miscalculated for all instructions with immediate source arguments except JMP/JMPRET.

    I had a long look at the Gnu Assembler code today and learned a lot about the architecture of binutils (of which GAS is a part). But the longer I look at it, the more I wonder why it works at all.

    The Propeller uses hub memory and cog memory. All data and program code is initially stored in the hub, and gets downloaded to the cogs to get executed. In the hub, every byte is addressable, but the cogs use 32-bit addressing (every address represents a 32-bit word). When an instruction in the code refers to another item, the reference might refer to the location where that item is stored in the hub, or the location in the cog where the item was copied when execution started.

    When using the Spin language, a reference or pointer to an item always refers to the hub. In assembler, all references and pointers refer to cog memory, except hub instructions. So it makes sense for GAS to store cog addresses into those instructions, and that’s what it does in most cases, but it gets it wrong:

    • Whenever an instruction refers to one or two locations in cog memory and isn’t used in immediate mode, everything appears okay
    • When using immediate arguments with JMP/JMPRET, the assembler stores an immedate value that (apparently) corresponds to the location of the referred label within the module, which is not correct in certain situations because it doesn’t take into account that the actual code may not start at location 0
    • When using immediate arguments with other instructions such as MOV or MOVS or MOVD, the value of the source argument is stored as an immediate value but it’s converted to a cog address only if the label was preceded by .cog_ram.

    I’m going to try a workaround for this (basically by putting the assembly code in a separate module) but I’m probably going to be working on fixing this problem in the Binutils too.


    [Update: The problems in GAS are now fixed, thanks Eric Smith (maintainer of Propeller-GAS)]