FreeSOC adventures – part 1

I recently received a FreeSOC board, ordered in an apparently dull point in my free time activities. The FreeSOC board, in simple terms, leverages the power of Cypress Semiconductor;s PSOC 5LP platform, which combines an intuitive IDE with FPGA-style capabilities, and an ARM M-3 processor core. The IDE was especially interesting to me, as it allowed a newcomer to easily explore the power of FPGA/CPLD-like devices without the hassle of learning a new language like VHDL or Verilog.

Upon receiving my board, the first thing I proceeded to do was add components, connected to dummy pins (and thus not be optimized out by the compiler), in order to see how many of the different discrete logic and protocol devices available in the IDE I could add without throwing errors. After a couple of tries, I realized I had far more hardware available to me than I knew what to do with.

As an initial project, I attempted to get the on-board USB port working as a generic USB CDC device – essentially a USB->Serial converter. After a few hiccups and learning experiences with the IDE, the CDC protocol, and PSOC-specific coding requirements, I successfully implemented a USB->Serial device that accomplished absolutely nothing.

My initial goal was to get the hardware to talk back to me. I implemented a USB CDC interface, which is essentially a USB->Serial Port device. The project’s goal was to simply echo back what I typed in over the CDC serial port that was presented to Windows when connected to the FreeSOC. With an extremely minimal amount of code, I was able to accomplish in a few minutes (not facotring in the learning curve), what would have taken much longer when using something like a PIC or AVR and hand-coding the interface. This, to me, demonstrated both the power of the IDE in adding common interfaces, and the abstraction of a lot of the minutiae when adding these interfaces.

In part 2, I will explain my first foray in trying to test the hardware even further – duplicating a GLCD interface through reverse-engineering, and much trial and error. Long story short – don’t try to do in software what can be quickly (albeit not always easily) in hardware.