Author Topic: Moving into 32-bit MCU  (Read 26650 times)

0 Members and 1 Guest are viewing this topic.

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Moving into 32-bit MCU
« Reply #50 on: June 15, 2017, 05:27:10 pm »
This is a fully programmable digital logic block akin to a CPLD.

Yes, but it is very small. One UDB has two PLDs. Two PLDs have roughly the same logic resources as 1/2 Xilinx 7-series CLB (setting apart the fact that Xilinx's CLBs are much more powerful and way faster). So, entry level PSoC devices with 2 UDBs have equivalent of 1 CLB. High end PSoC devices with 24 UDBs have equivalent of 12 CLBs. For comparison, the smallest Spartan-7 (XC7S6) has 469 CLBs.

The Datapath part of the UDB is much more massive, and this is what you would use to create your custom peripherals, with PLDs used to aid the process.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Moving into 32-bit MCU
« Reply #51 on: June 15, 2017, 05:45:59 pm »
I am looking at a design that will take both a PSOC and an FPGA, because FPGA can give me very high speed
wide counters in the 100 Mhz area. But all the other stuff I need to do much more easily realized on the PSOC.

If you have enough logic resources in your FPGA then you can run soft-core processer (or several of them). You can design your own soft-core processor to meet your needs exactly. If you already have FPGA, adding external ADCs and/or DACs (or perhaps some MCU which specializes on Analog stuff) might be a better solution.
 

Offline danadak

  • Super Contributor
  • ***
  • Posts: 1875
  • Country: us
  • Reactor Operator SSN-583, Retired EE
Re: Moving into 32-bit MCU
« Reply #52 on: June 15, 2017, 07:50:41 pm »
The solution with PSOC gave me this part of design -

1) 2 ADC, one SAR, one DelSig, both which I needed.
2) Precision reference.
3) 1 VDAC
4) 1 IDAC
5) 1 Wavedac
6) 2 OpAmps
7) 1 Comparator

The rest of the stuff DMA, DSP, COM I could have gotten from FPGA,
but choose PSOC because a significant portion of the routing on PCB
could be eliminated by keeping this stuff in PSOC. And its there with the
analog, makes sense to use it.


Regards, Dana.



Love Cypress PSOC, ATTiny, Bit Slice, OpAmps, Oscilloscopes, and Analog Gurus like Pease, Miller, Widlar, Dobkin, obsessed with being an engineer
 

Offline donotdespisethesnake

  • Super Contributor
  • ***
  • Posts: 1093
  • Country: gb
  • Embedded stuff
Re: Moving into 32-bit MCU
« Reply #53 on: June 17, 2017, 11:42:34 am »
It's weird how certain products pick up such ardent fanboys.. Cypress PSOC has some interesting features, but I wouldn't recommend it for newcomers.

In reality, there are many good 32-bit options, but there is no perfect choice. NXP, ST are easy to get into. Microchip SAM D21 and similar are gaining traction due to Arduino support.

Personally, I would look at the software, not the hardware. Find an IDE you are comfortable with, then see if there are some cheap boards supported well by the IDE. The actual manufacturer is almost irrelevant. 90% of your code is application level which is portable to any 32 bit MCU. The hardware specific stuff is usually a small portion of the code, and unless you like re-inventing the wheel, you will use a HAL library, or at least use it's functions as a base for your own libraries..
Bob
"All you said is just a bunch of opinions."
 

Offline donotdespisethesnake

  • Super Contributor
  • ***
  • Posts: 1093
  • Country: gb
  • Embedded stuff
Re: Moving into 32-bit MCU
« Reply #54 on: June 17, 2017, 12:15:43 pm »
It's weird how certain products pick up such ardent fanboys.. Cypress PSOC has some interesting features, but I wouldn't recommend it for newcomers.

PSoC software is REALLY easy to use. It's pretty much Arduino, you have good quality, MISRA certified libraries for many all hardware blocks, and for hardware block designing, it's like LEGO.

Yeah, so is nearly every other 32 bit MCU... frankly I am beginning to think all the boosting for PSOC smells of BS.

Bob
"All you said is just a bunch of opinions."
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Moving into 32-bit MCU
« Reply #55 on: June 17, 2017, 01:30:51 pm »
It's weird how certain products pick up such ardent fanboys.. Cypress PSOC has some interesting features, but I wouldn't recommend it for newcomers.

PSoC software is REALLY easy to use. It's pretty much Arduino, you have good quality, MISRA certified libraries for many all hardware blocks, and for hardware block designing, it's like LEGO.

Yeah, so is nearly every other 32 bit MCU... frankly I am beginning to think all the boosting for PSOC smells of BS.
I have long thinking about that. Every 32-bit MCU works as well as the next (maybe except a few corner cases) and there is no single specific reason one line of products is better than the next. Maybe you have more experiences in something but that does not automatically makes it better for the next person.

Personally I am more comfortable with AVR and STM32, but you may want to look to my posts and see parts I am talking about - for some scenarios I was talking about PIC, I have a blog series about 8051 and some posts about the 8051-based STC15 line, and my four queued projects are based on NXP LPC2368 (ARM7TDMI,) Allwinner V3s (Cortex-A7 MP1,) Microchip AT91SAM9260 (ARM926EJ-S,) and Mediatek MT7688 (MIPS24KEc,) none of which is either AVR or STM32.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: Moving into 32-bit MCU
« Reply #56 on: June 17, 2017, 01:59:01 pm »
Yeah, so is nearly every other 32 bit MCU... frankly I am beginning to think all the boosting for PSOC smells of BS.
I have long thinking about that. Every 32-bit MCU works as well as the next (maybe except a few corner cases) and there is no single specific reason one line of products is better than the next. Maybe you have more experiences in something but that does not automatically makes it better for the next person.
IMHO what sets microcontrollers apart are bugs, ease of use (both software and hardware) and electrical quality of the design. The latter is about things like crystal startup, logic input levels, output drive capability, susceptibility to latch-up and ESD, adequate margins in supply voltage, etc.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: Moving into 32-bit MCU
« Reply #57 on: June 17, 2017, 10:07:41 pm »
Quote
what sets microcontrollers apart are bugs, ease of use (both software and hardware) and electrical quality of the design.
Ah.  And Documentation.  Some vendors have notably worse documentation than others.  FTDI doesn't much document the architecture of their Vinculum2 chip at all.   Intel's documentation for their chips (even the supposedly embedded-friendly Quark chips and Curie modules) has been late, hidden behind NDA agreements, or sucky.
For ARM chips, there's a great deal of variation in how many different datasheets you'll need.  It's pretty common to have a chip data sheet describing pinouts, a family datasheet documenting how the vendor peripherals work, and a pointer to ARM documentation if you want to know about the ARM peripherals (SysTick, NVIC), instruction set(s), or architecture (that's at least 2 and perhaps 3 ARM manuals to go with your 2 vendor manuals.  Fun, eh?)
A couple of vendors/devices I've looked at stand out as having unusually complete single datasheets - the TI Tiva series is one, and the Atmel SAM3X is another (interestingly (?), the Atmel SAMD chips go back to omitting the ARM-side documentation that the SAM3X datasheet includes.)

A lot of this is more relevant to the "moving" part; once you gain some familiarity with an ARM chip or two, you'll have figured it out and it probably won't bother you too much to have a separate ARM TRM document.  But when I was first looking at ARM, it was driving me crazy.  (and I think the ARM documentation has improved.  I could swear that when I was first looking, they has Cortex M documentation that said essentially "This supports the standard ARM v7 instruction set except for all the non-thumb instructions."  Now there are distinct manuals !)

This applies to any vendor libraries, too.  In general, I think the libraries suck and avoid them, but they CAN be useful examples for understanding how the chip actually works.   IFF they're reasonably documented and the source code is browseable.  My current peeve is that I can't figure out how to browse Atmel ASF source unless I add it to a "project" first (possible, but annoying.)  ST, IIRC, had a nice library doc/source browser, but it was based on windows .CHM files and therefore not as nice on non-windows systems.  A lot of libraries have DOXYGEN-generated documentation that has a description of every individual function, but seem to lack any overall explanation of philosophy, high-level operation, or interdependencies.   ("Yes, the uart_init() function has an argument of uart_init_params with type uart_init_parms_t.  That's just ... swell.  Thanks.")  The vendors that have changed their library philosophy a couple of times in the last decade (samlib->ASF->Start, or stmlib->cube->whatever) don't make it any easier (but at least they're DOING something...)

A lot of it seems to be "Everything sucks; I'm just going to bang my head against this arbitrary choice until I understand it, and I hope the second one will be easier."
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Moving into 32-bit MCU
« Reply #58 on: June 17, 2017, 10:42:51 pm »
I have long thinking about that. Every 32-bit MCU works as well as the next (maybe except a few corner cases) and there is no single specific reason one line of products is better than the next. Maybe you have more experiences in something but that does not automatically makes it better for the next person.

What sets MCUs apart is the purpose. One MCU may be more suitable for one purpose, the other for some other purpose. IMHO, the biggest mistake people make is choosing "good" MCUs instead of choosing MCUs which are the most suitable for the task. Of course, to be able to choose, you must know what is available and monitor how the available choices change with time.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: Moving into 32-bit MCU
« Reply #59 on: June 17, 2017, 11:19:06 pm »
I have long thinking about that. Every 32-bit MCU works as well as the next (maybe except a few corner cases) and there is no single specific reason one line of products is better than the next. Maybe you have more experiences in something but that does not automatically makes it better for the next person.

What sets MCUs apart is the purpose. One MCU may be more suitable for one purpose, the other for some other purpose. IMHO, the biggest mistake people make is choosing "good" MCUs instead of choosing MCUs which are the most suitable for the task. Of course, to be able to choose, you must know what is available and monitor how the available choices change with time.
If you choose a good MCU family then it will have a family member which is suitable for a specific task without needing to rewrite most of your existing software or make changes in your eco system (programmer). NXP has been such a vendor for me. Almost every microcontroller based project I have made during the past decade has a different NXP ARM microcontroller in it due to project specific requirements. If I had choosen to use ST this would have been much harder to do.
« Last Edit: June 17, 2017, 11:21:52 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline danadak

  • Super Contributor
  • ***
  • Posts: 1875
  • Country: us
  • Reactor Operator SSN-583, Retired EE
Re: Moving into 32-bit MCU
« Reply #60 on: June 18, 2017, 12:00:12 pm »
Should we revive the vacuum tube vs transistor debate ?

For folks that have a difficult time making decsions/evaluations, use a
weighted decision matrix, Excel, works like a charm when too many
variables are involved for our gerbil sized brain pans. Actually i should
not assume others have my limitations.

The real "smell" test of PSOC is try it before you buy it. If you cant figure
out in 30 minutes, watching a couple of their videos, move on, you are not
meant for PSOC. If you are a PCB manufacturer who makes money off area
of PCB, don't use a PSOC. If you like large boxes, lots of heat, don't use a
PSOC. If you have applications that have no analog, no need for digital filter
in signal chain, don't care about what pin carries what signal, don't need a
precision reference, don't like ARM cores, don't need a 20 bit A/D or a fast
SAR 12 bit, or both, don't like DMA, especially do not want to design your
own specialized on chip component, don't use a PSOC.

Lots and lots of reasons to NOT use a PSOC.

Regards, Dana.





Love Cypress PSOC, ATTiny, Bit Slice, OpAmps, Oscilloscopes, and Analog Gurus like Pease, Miller, Widlar, Dobkin, obsessed with being an engineer
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: Moving into 32-bit MCU
« Reply #61 on: June 18, 2017, 02:51:11 pm »
I like that you are positive about the PSOC but the last time I looked it seemed to me that you can't have all the peripherals but have to make a choice. From there it is hard for me to determine whether a PSOC device would fit or not without making a design first and the latter takes more time than I would want to spend on selecting a device. But maybe I'm completely wrong here...
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Moving into 32-bit MCU
« Reply #62 on: June 18, 2017, 04:23:48 pm »
Should we revive the vacuum tube vs transistor debate ?

For folks that have a difficult time making decsions/evaluations, use a
weighted decision matrix, Excel, works like a charm when too many
variables are involved for our gerbil sized brain pans. Actually i should
not assume others have my limitations.

The real "smell" test of PSOC is try it before you buy it. If you cant figure
out in 30 minutes, watching a couple of their videos, move on, you are not
meant for PSOC. If you are a PCB manufacturer who makes money off area
of PCB, don't use a PSOC. If you like large boxes, lots of heat, don't use a
PSOC. If you have applications that have no analog, no need for digital filter
in signal chain, don't care about what pin carries what signal, don't need a
precision reference, don't like ARM cores, don't need a 20 bit A/D or a fast
SAR 12 bit, or both, don't like DMA, especially do not want to design your
own specialized on chip component, don't use a PSOC.

Lots and lots of reasons to NOT use a PSOC.

Regards, Dana.
* If you need high efficiency float point arithmetic, do not use a PSoC. Since your strong point is analog, where did the complimentary FPU go? Both ST and Microchip products can come with a FPU, be it Cortex-M4F, Cortex-M7F or MIPS FPU.
* If you need more than 80MHz clock speed, do not use a PSoC. ST, Microchip and NXP all have chips operating at more than 80MHz. ATSAM3X8E, as used on Arduino Due, sports a 84MHz clock. Heck even the Chinese-made less-than-well-known WCH CH563 can operate at 180MHz.
* If you need Ethernet, do not use a PSoC. ST, Microchip and NXP all have chips that comes with MII/RMII interfaces for your Ethernet PHY. You can argue PSoC can use things like W5500 or ENC28J60 but those always works less efficient with an internal MAC. Remember the WCH CH395? That chip even edges out the big players by having a built-in Ethernet PHY.
* If you need to build affordable products, do not use a PSoC. I will elaborate on this below.

The price is really, REALLY a sore point for PSoC. I am shooting for the highest end here with CY8C5888AXQ-LP096. It is a $15.52 chip, Cortex-M3 @80MHz, LQFP100 package, 256kB Flash, 64kB SRAM, and a bunch of analog peripherals. So what can I buy for $15.52 from other vendors? STMicroelectronics STM32F756BGT6, NXP MKV58F1M0VLL24, TI TM4C129EKCPDTI3, Microchip ATSAM4CMP8CC-AU. Try compare those. And the slightly more expensive Microchip PIC32MZ1025DAH176T-V2J (about $17.5) is the heatedly talked about PIC32MZ DA line with 32MB built-in DRAM - runs Linux if you slapped a $2 SPI NOR Flash on it. Here I still restricted myself to the big name brand territory.

If you start looking into the lesser-known world you start to see more competitors. I have been flirting with Allwinner V3s (being a MPU it lacked a lot on the I/O side of things, but for IoT it is cheap enough to be built into every single unit you are shipping while still powerful enough to handle things like TLS and reduced resolution OpenCV.) There is also the WCH CH395 I hinted about.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: Moving into 32-bit MCU
« Reply #63 on: June 18, 2017, 04:58:50 pm »
I wouldn't dismiss a solution with the Wiznet W5500 because it also takes care of the TCP/IP stack and you only transfer the actual data between your microcontroller and the W5500. You don't have to deal with broadcast messages which don't concern you.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Elf

  • Guest
Re: Moving into 32-bit MCU
« Reply #64 on: June 18, 2017, 07:00:12 pm »
[...]
Lots and lots of reasons to NOT use a PSOC.
Sheesh. Apparently "there are other good products out there" somehow didn't make the list.

Maybe I am weird, but I actually enjoy sampling all the different things out there rather than trying to use the same chips for everything, every time. Mind you I am not in a professional environment and have no pressure for time to market, but they all seem to have something to like and dislike. Documentation, IDE, libraries, price, availability, peripherals, programming/debugging tool quality and cost, performance, power usage, etc.
 

Offline danadak

  • Super Contributor
  • ***
  • Posts: 1875
  • Country: us
  • Reactor Operator SSN-583, Retired EE
Re: Moving into 32-bit MCU
« Reply #65 on: June 18, 2017, 07:52:38 pm »
From the 2016 annual report -

Quote
Excluding the impact of IoT revenues, MCD increased by $128.3 million for fiscal 2016, or 17.6%,
compared to the prior year, primarily due to increased revenue in the automotive segment.
Revenues from MCD in fiscal 2015 increased by $362.3 million or 98.2%, compared to fiscal 2014.
The increase in the 2015 MCD revenue was primarily attributable to the following factors:
• Contribution from products acquired as part of the Spansion acquisition
• Increase in sales of products related to automotive applications.
This increase was offset by decreases related to the following factors:
• Divestiture of TrueTouch business
• Weakness in demand in the mobile business and consumer end markets
The overall average selling price of our products for MCD for the year ended January 1, 2017 was
$1.02 which is unchanged from the prior-year. The overall average selling price of our products for
MCD for the year ended January 3, 2016 was $1.02 which increased by $0.24, compared to $0.78 in
fiscal 2014. The increase in ASP is due to Spansion acquisition.

The ASP was ~ 78 cents (prior to Spansion acquisition), thats so non
competitive they will never ship anything. Wait, they shipped from the Microcontroller division $994 million,
clearly into non competitive products. What are those designers thinking ?

And they continue to invest heavily into PSOC, 6 family dual core end of this year. 2 arm cores. Too
much computing power is not good for the planet.


Quote
Since your strong point is analog, where did the complimentary FPU go?

No FPU, but does have fixed point 24 x 24 MAC for the digital filter block, or as a GP control engine.
That seems to handle efficiently signal path processing. And the M3 core has a single cycle MUL
instruction, 32 bit.

PSOC clock speed definitely 80 Mhz or less. Not sure at this time what the PSOC 6 will come in at.
The FM family of ARM cores is good for 200 Mhz, but thats non analog or route ability or....not a PSOC.

For sure no Ethernet, would be nice to have an Eth MAC on board a part. There are designs out there
where Eth has been done though, does not seemed to have inhibited activity. Not sure of impact on
thruput though.


Regards, Dana.


PS : Being a tad facetious on some points :)






« Last Edit: June 18, 2017, 08:47:36 pm by danadak »
Love Cypress PSOC, ATTiny, Bit Slice, OpAmps, Oscilloscopes, and Analog Gurus like Pease, Miller, Widlar, Dobkin, obsessed with being an engineer
 

Offline danadak

  • Super Contributor
  • ***
  • Posts: 1875
  • Country: us
  • Reactor Operator SSN-583, Retired EE
Re: Moving into 32-bit MCU
« Reply #66 on: June 18, 2017, 08:04:48 pm »
nctnico,

The PSOC does have limitations, not an infinite amount of logic. But, for example, another poster
needed a lot of PWMs, I was able to get 16 16 bit PWMs placed and routed along with a lot of other
stuff on a chip. In fact the resource result tab indicated I might have been able to get more PWMs.


https://www.eevblog.com/forum/microcontrollers/best-way-to-add-external-dacs/msg1207330/#msg1207330


For sure there is a learning curve. I found it fairly easy because of their video library and I
had been working with Freescale Codewarrior with Processor Expert so was used to leading
edge IDE (or I thought it was), so the transition to get something done was fairly quick.
In short order I was doing a design on both platforms, porting back and forth. But stopped
when I started to use the analog in PSOC.

Regards, Dana.

« Last Edit: June 18, 2017, 08:44:53 pm by danadak »
Love Cypress PSOC, ATTiny, Bit Slice, OpAmps, Oscilloscopes, and Analog Gurus like Pease, Miller, Widlar, Dobkin, obsessed with being an engineer
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Moving into 32-bit MCU
« Reply #67 on: June 18, 2017, 09:29:08 pm »
But, for example, another poster
needed a lot of PWMs, I was able to get 16 16 bit PWMs placed and routed along with a lot of other
stuff on a chip. In fact the resource result tab indicated I might have been able to get more PWMs.

For comparison, an entry level Spartan-6 can give you over 100 16-bit PWMs for substantially lower price than CY8C5868AXI.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: Moving into 32-bit MCU
« Reply #68 on: June 18, 2017, 09:52:27 pm »
But, for example, another poster
needed a lot of PWMs, I was able to get 16 16 bit PWMs placed and routed along with a lot of other
stuff on a chip. In fact the resource result tab indicated I might have been able to get more PWMs.

For comparison, an entry level Spartan-6 can give you over 100 16-bit PWMs for substantially lower price than CY8C5868AXI.
But now compare the NRE (development costs), extra supply voltages, external rom for the configuration and programming solution. It is not the price of the chip which counts but the cost of the solution (development costs + hardware). Many seem to completely overlook that.
« Last Edit: June 18, 2017, 09:54:53 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Moving into 32-bit MCU
« Reply #69 on: June 18, 2017, 10:12:49 pm »
But now compare the NRE (development costs), extra supply voltages, external rom for the configuration and programming solution. It is not the price of the chip which counts but the cost of the solution (development costs + hardware). Many seem to completely overlook that.

All true. But we have no way to evaluate these components, as they depends on so many factors which we don't know. For example, if this is a hobby project NRE is zero.
 

Offline danadak

  • Super Contributor
  • ***
  • Posts: 1875
  • Country: us
  • Reactor Operator SSN-583, Retired EE
Re: Moving into 32-bit MCU
« Reply #70 on: June 18, 2017, 10:54:11 pm »
NorthGuy,

I am curious about price, I filtered the Digikey 1 off pricing for all Sparton 6
families and best I saw was $ 11.48.

I have a design that will use a FPGA and PSOC, and am new to FPGA side, so
curious about what "real" 1K pricing on low end looks like. All I need out of
part is 2 150 Mhz 32 bit counters, maybe a CPLD will be the solution. And
only 10 or so pins.

The example I gave on PWM was not about just PWM, it also included DSP, and
a bunch of other stuff. And took me about 20 minutes to do. And the example
left a lot of analog resources unused.



Regards, Dana.
« Last Edit: June 18, 2017, 10:57:39 pm by danadak »
Love Cypress PSOC, ATTiny, Bit Slice, OpAmps, Oscilloscopes, and Analog Gurus like Pease, Miller, Widlar, Dobkin, obsessed with being an engineer
 

Offline suicidaleggroll

  • Super Contributor
  • ***
  • Posts: 1453
  • Country: us
Re: Moving into 32-bit MCU
« Reply #71 on: June 18, 2017, 11:04:16 pm »
am new to FPGA side, so curious about what "real" 1K pricing on low end looks like. All I need out of part is 2 150 Mhz 32 bit counters, maybe a CPLD will be the solution. And only 10 or so pins.
It may be worth writing up the VHDL/Verilog, using the simulator to verify functionality, and then selecting different models to check usage.  You very well may be able to get away with a small Coolrunner II CPLD or similar, which has single-unit pricing down to $1.40 on Digikey.  CPLDs are much less capable then FPGAs, but they are also much less demanding when it comes to layout, decoupling, supporting electronics (IE: flash), etc.  For simple applications they make a lot of sense, but you need to write up the code to see if it'll fit first.  When you get up to the 256 macrocell range is when it starts to make more sense to switch to an FPGA.
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Moving into 32-bit MCU
« Reply #72 on: June 18, 2017, 11:44:35 pm »
I wouldn't dismiss a solution with the Wiznet W5500 because it also takes care of the TCP/IP stack and you only transfer the actual data between your microcontroller and the W5500. You don't have to deal with broadcast messages which don't concern you.
Try move a few MiB in a short burst. Or try IPv6.
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Moving into 32-bit MCU
« Reply #73 on: June 19, 2017, 12:06:03 am »
It's weird how certain products pick up such ardent fanboys.. Cypress PSOC has some interesting features, but I wouldn't recommend it for newcomers.

PSoC software is REALLY easy to use. It's pretty much Arduino, you have good quality, MISRA certified libraries for many all hardware blocks, and for hardware block designing, it's like LEGO.

Yeah, so is nearly every other 32 bit MCU... frankly I am beginning to think all the boosting for PSOC smells of BS.
I have been using Eclipse CDT for a while now. It is easy to use, works everywhere (including Linux and macOS,) and programming and debugging is straightforward. Oh Eclipse CDT is non discriminatory between vendors so it works on one vendor’s produce line as brilliantly as the next, as long as it is supported. Oh forgot to mention that yes I am a UNIX person.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Moving into 32-bit MCU
« Reply #74 on: June 19, 2017, 12:28:13 am »
I have a design that will use a FPGA and PSOC, and am new to FPGA side, so
curious about what "real" 1K pricing on low end looks like. All I need out of
part is 2 150 Mhz 32 bit counters, maybe a CPLD will be the solution. And
only 10 or so pins.

I don't know 1K pricing, I've never bought them in quantities. A 32-bit counter will only take 5-6 slices. They also have few DSP slices which can add and multiply very fast. You probably will still need a number of slices to interface the counters to the inputs/outputs. I think the smallest Spartan-6 has about 600 slices, so if only used for two counters it still be an overkill. But if you have complicated logic associated with the counters, the slice count may go up very quickly. The best way is to do the design and see.

 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf