@Antedeluvian: By some strange quirk of fate -- the folks at Cypress just sent me two of those $4 PSoC 4 Prototyping kits along with a PSoC 4 Pioneer Kit as mentioned in your article ... I hadn't realized that the Pioneer Kit had the same board footprint & headers as am Arduino Mega -- I think the little scamps are tempting me to plug in some of my Arduino Shields -- now I'm quivering in anticipation at the thought of experimenting with these (as soon as I get a spare moment -- Ha!)
No fiddling with wirewrapping with the Cypress Psocs. Just draw lines on the screen to connect the analog and digital "parts" from the included library and draw lines to the desired output pins.
I wanted to reply to note that Cypress has a simple Verilog tutorial, that is a great quick read on how to program in verilog for the PSoc 4 using the Creator free software. Turns out not to be hard, at least this Verilog subset. And is a great inexpensive way to play with real Verilog without spending a lot of nickles.
You know this could be just the thing to use for you BADASS display. I've got one of the pioneer kits at home that I've been meaning to do something with for a year. Maybe next month...
I've been busy getting antennas built and batteries charged for Field Day (http://www.arrl.org/field-day). Not to mention finding all the miscellaneous equipment and lengths of coax... Only 10 more days!
@Elizabeth: You know this could be just the thing to use for you BADASS display.
I know, I know ... the great thing about how I'm implementing the BADASS display is that I can swap controllers in and out -- for the moment I'm going to continue with my current plan (Arduino Mega + chipKIT MAX32), but after everything is up-and-running I may well experiment with a PSoc 4 and a Teensy 3.1 and a ... the world is my lobster.
I'll see what I can come up with. I probably won't have any pictures of set-up and take down. I usually find myself thinking that "it would have been nice to get a picture of that" just AFTER we finish some tricky bit...
By an even stranger quirk of fate, when I went to tthe post office this morning to pick up the mail from my PO Box there was a large envelope with a return address from Arrow. When I opened it up, there was one of the $4 PSoC 4 Prototyping kits. The mystery is why they sent it to me and why it got sent to my PO Box instead of my work address. Not that I'm going to complain mind you.
So now that I've been given both the Prototyping kit and the Pioneer kit, I guess I really need to do something with them...
But not until after Field Day (only 3 more days)....
I've been waiting for a good reason to play with PSoC 4 (ARM Cortex-M0 core) and/or PSoC 5LP (Cortex-M3 core). I'm not interested in the 8-bit PSoCs. The PSoC 4 Pioneer board actually has both parts, because they use the PSoC 5LP as the download/debug device for the PSoC 4.
One thing I really like about the PSoC 5LP is that Cypress documents almost all the device registers, so you can program them directly instead of having to use PSoC Creator on a Windows PC. The thing I don't like is that "almost all" is not the same as "all". In particular, they don't document the routing resources so while you can program all those wonderful PLAs, data paths, interrupts, DMA, DAC/ADC, DSP, analog devices, etc., etc., you can't connect them together without using PSoC Creator. Now Creator is a fine tool and probably good for most users, but I find it's like using a video game and that's not the way I think about serious design. Also, I really dislike Windows (except for 2000) and pretty much only use it if somebody is paying me to do so.
So, I'm still waiting for Cypress to take that last little step to document the routing registers which is all that's needed to make PSoC the first programmable logic device (except for an obscure Atmel part that never caught on) that permits open source development. Since the PSoCs have all programming information inside the chip and you have the option to lock it all down, PSoC customers don't have to worry about reverse-engineering so IMO Cypress really doesn't have an excuse.
When is your next artical coming out and thanks for designing that reader controller at Debex all those years ago which was the foundation stone of my business that has lasted over 20 years.
It's often be said of me that when tasked to buy a half dozen eggs, I return with a box full of (live) chickens and enough hardware to build a chookshed, but I think I will need to abdicate in your favour.
Did you ever get to make a bipolar current output from the PSoC? There's more parts needed than might be expected to be able to do this, I'd probably opt for using an INA , if sufficient headroom were available.
I really want to play with some of their parts. I have a dev kit, just I have not yet found the right project yet. They really seem to have some interesting features. I really wish that they had one with a M4F core. I think that this would make for a very nice chip.
You know, I always wondered why people prefer a floating point core to a fixed point one. An older engineer I usually talk to once said, 'the only reason you need a floating point is if you're doing military applications/have cash to spare'. And in general for most of my applications I found that (with proper shifting) fixed point gives plenty of precision for most digital filters(admittedly not more that 10-taps or so).
Any chance you could elaborate on why the Floating vs Fixed? Or is it just a M4 MIPS thing?
M4/M4F have DSP instructions added to the chip. This facilitates a handful of things that make some of the current applications that I am trying to do. As for the FPU, yeah, I can take the time to convert everything to fixed point math, but I rather spend the few evenings I get to play doing other things rather than beating my head against a wall trying to convert all my math to fixed point. The kicker is that when you have done that, and then you need to change something.
If you are looking for bleading edge performance, floating point is probably not the right direction, but considering the FPU and the rest of the DSP that allow for float math to not be computationally expensive, I just use it. In the end, it usually ends up being a mix with most things being fixed point and a lesser quantity in floating point.
Ah gotcha. Yeah it can be a pain to change everything to fixed and there are moments when I suddenly realize something in the filters gone awfully wrong. Turning out that I forgot to shift enough bits for some coefficient!
As always cost vs time, or rather how much time vs the cost advantage :)
It is not always bit shifts though, for converting to fixed. It usually ends up rearranging equations in such a fashion that you do not get any overflows, or get something that you divide by a large number and then get left with something that becomes so small in the middle of the calculation that it induces large errors in the rest of the calculation.
I remember where I had a case where I was getting an overflow issue because of a situation where I had forgot to rearrange a multiply so that the equation during the solving process would not overflow. This was one of those errors that was hard to catch because I just was not even thinking about it, and forgot how large that number could get in calculation.
Would you be working in assembler then? Would this (RISC) matter much if you were working in C?
I have only worked in assembler with the PICs. I am sure a C compiler would hide the issues if you could get iot to compile for on of the really small PICs that I was looking at. The problem with a bias is that it is preconcieved and brealimnk the bias is much harder once it is established.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.