Unfortunately the "debugging end" is not. It is simply a bare board version of a USB to RS-232 adaptor sans EIA level shifting. It has a number of options, GPIOs, I2C, SPI, but Cypress didn't choose to implement them intelligently in the system. It simply is a serial port replacement that can connect with pre-programmed code in the board to allow the code to be replaced.
However, if the replacement code doesn't also include the bootloader used to replace code, you have reached the end of the road for the $4 board. If what you put into it is buggy, you basically have bricked it.
Unless you buy the $90 MiniProg3, which can load a bare CPU. It can also do the normal debug stuff like single stepping, which that USB-UART that comes with it can't do.
This seems like a stupid decision on Cypress's part. The MiniProg3 has a lot of capabilities beyond what is needed to debug this board. I suspect that the CY7C605211 on the USB-UART part of the kit, which contaisn a processor, could have been made to emulate the necessary part of the MiniProg3 and would have allowed bare chip programming as well as debugging. I'd have been glad to pay an extra dollar or two if needed to get that capabiliy. But I'm not eager to part with $90 to allow development on my $4 board, particularly when there are 100 different ISP/debug setups that are incompatible with each other and I design using several different CPUs.
I bought six of these board (before I realized how crippled they were). The development environment is rich and powerful, and the boards are a great value for the money for simple embedded products. Four of them I plan to use in a litle controller system I've been promising for a couple of years now and the other two I bought simply because they were only $4 (and the shipping on the package was more than that). I just hope I can manage to not brick them long enough to get working code into them.
It is an industrial signal conditioner converting +/-10V input to a +/-n mA at the output (when n is a progammable current of up to 100mA). The output is intended to drive an electrically ajustable valve. However I don't really go too much into the nitty gritty of the design, only the design approach and some of the options available.
bodger wrote: Little known fact: you can get free shipping from Digikey if you pay at the time you submit your order.
I didn't know that. When I first started ordering from Digi-Key over the Internet I was pleased to discover that there was no minimum Internet order, whereas at the time by-mail orders had a handling charge below $25 IIRC. So I was surprised to find that they've dropped the minimum for all orders.
I've always liked Digi-Key. I was ordering from them by mail when their catalog was 4 pages long (single B-size sheet, folded once). It was also the order form -- you just wrote how many of each IC or resistor wanted and sent in the whole sheet. I regret that I don't have one of those "catalogs". Max would be highly amused.
vasanth wrote: No onboard debugger or anything of that kind.
That's a good point. When I first saw the board I naturally assumed the USB chip and the PSoC 4 communicated using SWD (Single-Wire Debug, which uses two wires [*]), but you're right that they communicate using UART signals. Reconfiguring the PSoC 4 uses a software boot-loader that runs in the PSoC 4.
Now, you could use that UART to communicate to a debug monitor that's part of your PSoC 4 program, so there is some onboard debugging capability (just add software).
You can also attach an external debugger to the SWD pins. Cypress' MiniProg3 is pricy at US$89 and probably limits you to Cypress software. If you like writing or adapting your own debug software, you could use anything that speaks SWD to connect to those pins. Personally I like the FTDI FT2232H, though SWD is a little clunky and slow. You could in principle use an ST Link from an ST Discovery board if you've picked up any of those for free at conferences.
In principle, you should be able to use the USB chip on the $4 PSoC 4 board since it brings out GPIOs: just jumper them to the PSoC 4 SWD pins. Now that's going to be really slow and clunky. SWD has a bidirectional SWDIO pin so your debugger has to be able to switch that pin between input and output reasonably efficiently.
[*] "Single Wire Debug" has two signals, a clock line SWCLK from debugger to target device and bidirectional data line SWDIO. It's possible to implement asynchronous SWD using just SWDIO and get true SWD, but I've always seen SWD implemented synchronously on two wires.
Drones are, in essence, flying autonomous vehicles. Pros and cons surrounding drones today might well foreshadow the debate over the development of self-driving cars. In the context of a strongly regulated aviation industry, "self-flying" drones pose a fresh challenge. How safe is it to fly drones in different environments? Should drones be required for visual line of sight – as are piloted airplanes? Join EE Times' Junko Yoshida as she moderates a panel of drone experts.