Sorry for that question, but I'm going to be pretty much disappointed about this "Development Tool" - but $1.
Of course, it's my fault not to get more information $1 I bought two of these Evo Primers (one with STM32F103x and one with STM32F107x). But may be, I'm totally wrong with my first impressions:
For me, the EVO Primer seems to be a nice piece to write a little application, perfectly a game. You get a color LCD incl. Touchscreen, a Joystick and a big OS, doing all the nasty work for you. That all comes in a pretty nice housing and even with SD-Card support. One could take it and sell it (nearly) right away - but of course only in very little numbers.
But I have to develope products, which will be sold in the tens of thousands and saving money is crutial. I could not affort an OS like this; extra Flash is costly. I need to get a development platform, where I can implement and test routines, pretty similar, as I need them later in my product.
To use it as a developement kit, it should have some keys, a bunch of GPIOs, a LCD, a SD-Card - but all should be connected to the specific microcontroller, which I want to test.
But here, it seems, that there is $1 and all the work with the peripherals are going not only just through this OS, but also with the help of a secondary microcontroller. Am I right ? (Sorry to ask, but the schematics are not telling me that right away...)
I bought f.e. the EVO Primer with the STM32F107x. This model has Ethernet capabilities and that's the most noticable difference to the STM32F103x. But all I could find so far are two CAN-Bus connectors. No Ethernet in sight ! $1
Both STM32-models, which are available for the EVO-Primer, have ADC and DAC capabilities, so I thought, one could test recording and playback. But NO way(?), they put in an extra (costly) ADC/DAC and even this is probably connected to the secondary µC and not to my target processor, which I want to test. $1 To sell this costly ADC/DAC, because the inbuild ADC and DAC of my target processor are not realy working - or what ?
Both available µC target processors have 80 GPIOs. Okay, my next project needs ONLY 14 to 16 GPIOs and not all 80, but SORRY - there are only 12 GPIOs brought outside/are connectable. What the hell ... ?
Conclusion: I do not complain, that the OS is partly not really working (f.e. in menues, where the accelerator unit need another angle than the rest to work properly, f.e. some never ending loops in test routines etc. etc.) and I do not complain, that the already installed sample applications are using such a small part of the screen (ridiculous). That is all quite normal, when a system is pretty new - and I'm sure, there will be (or even are already) new versions availlable. But the whole concept seems to me not at all a development system, where you can test your target µC in real life situations. Here, the target µC is deeply hidden behind the OS and a secondary processor. I wouldn't even notice, when someone replaces my target µC with a complete different controller ... uuh
$1
So guys, who are using this for a while: Am I wrong ?
Or should I just put this EVO Primers in a drawer to get some "STM32 Discovery" boards from ST for a little bit more than 10 bucks and try them with the Ride7 (probably not working) or any other (true) Development platform ?
I don't want to spend hours and hours (probably days and days) to get familar with this "toys", when it ends up, that their datasheets just telling the truth: It's just for FUN !
I think this product is meant to be use in small and unique applications -> no big mass of customers.
I think some application areas of this product could be: - data gathering - debug device of bigger system - UI for device that communicate trought bus (TWI, UART, IRDA) - some special solutions that are unique to special customer
I think this isn't supposed to be eval board for mass products.
I use Primer2 and other CPU there are used for only debug interface. I have also hit that IO map wall in my desing.
Edit: I think this is so called fast prototyping device where you don't have to think about mechanics, UI, Filesystem and OS. If you also have to do this in unique target task where you need only 20-40 devices max then this is almost best solution.
Hi jogi, I have an EvoPrimer too, but I am just a hobbyist. Here are my thoughts:
1. Hardware I am pretty sure the second processor is used for the programmer/debugger. It is an on-board version of the Raisonance RLink product that works with the Ride7 IDE to program/debug the STM32 processor and the software running on it. If you look at the schematic, all the peripherals are connected directly to the STM32F103VET6 processor - LCD screen - SDIO card connector - MEMS sensor - joystick (which gives you basically 5 buttons) - 2 LEDs The extension connector gives you access to 13 GPIO pins directly I agree that the onboard audio codec/DAC is an additional piece of equipment that you don't see on other development boards, but judging from what I read on other boards about the STM32, if you want to do audio encoding with the processor itself it is pretty resource intensive and you'll end up with an external chip anyway for serious applications.
So from my personal point of view, the EvoPrimer gives you kind of a "reference implementation" of some of the most commonly used peripherals, like touch-screen LCD, MEMS sensor, SD Card interface, some basic user controls (joystick). In addition you have some other functions available through the extension connector (like USART2, I2C, general GPIO, SPI).
2. Software You can completely bypass/wipe out the default CircleOS, there are some examples (like the TOGGLE example) which you can load that show that. In that case you have full control over the software. You can write your own OS for the device, LCD routines etc. I think the purpose of the CircleOS again is to give you a reference software implementation of how to control the LCD, read the MEMS sensor values, etc. The source code for CircleOS is freely available.
What I ran into is that in some cases the CircleOS can interfere with some of the things you try to do, i.e. I found it interferes with the USART2 on the extension connector, I think others found the I2C is influenced by the LCD FSMC logic. But that is just because of how the components are wired together or the timers etc. are used. You would probably run into the same issues with other boards.
One drawback I think is that you are basically locked into the Raisonance toolkit and their RLink programmer. You cannot use anything else than Ride7 to debug/program the EvoPrimer as far as I know. Overall as a hobbyist I found the whole STM32 programmer/debugger market very fragmented. the ST DISCOVERY boards have an on-board STLink debugger, which again you cannot use with Ride7. If you work with these processors in your job it probably doesn't matter that much how much these programmers and IDEs cost, but for a hobbyist the cost is a big factor.
I don't know much about the F107 devices, but I think you still need some external components for the ethernet, like the pulse transformer. Why they didn't put that on the Target board, I don't know. I would think that should be included because that's the reason you'd look into the F107 devices, which is their "connectivity line".
Just few remarks - obviously, the target processor is on the "target board", and the µc of the base is only the embedded RLink. - the F107 board have not a Eth port, because the Primer is a portable equipment, not forseen for PC wired connection. For Ethernet tests, you can use the Raisonance's Reva dauther board (http://www.mcu-raisonance.com/index.php … 4ezgbct4rd. - the "big monster OS" is only a set of API functions to facilitate the implementation of peripherals. it is not mandatory to use it. - about the small screen area used by application demos, most of them were developped for Primer1 & 2, and show the binary compatibility between Primer versions, thanks to the CircleOS API. - Primer is a simple and "funny" way to be familar with the STM32 and ST librairies, but can also be used for "serious" development : some customers have used Primer2 as demonstration equipment for extension card developped by them self (ST, Nanotron, Dizic...).
I think this is so called fast prototyping device where you don't have to think about mechanics, UI, Filesystem and OS. If you also have to do this in unique target task where you need only 20-40 devices max then this is almost best solution.
Same, what I've thought.
mikepo :
If you look at the schematic, all the peripherals are connected directly to the STM32F103VET6 processor..
You are right. It was my biggest concern, that the peripherals might be connected through the 2nd processor, but they are NOT !
mikepo :
The extension connector gives you access to 13 GPIO pins directly
I would love to have much more, but keeping in mind, what Yves said: "the Primer is a portable equipment" - it makes (a little bit) sence.
mikepo :
What I ran into is that in some cases the CircleOS can interfere with some of the things you try to do, i.e. I found it interferes with the USART2 on the extension connector, I think others found the I2C is influenced by the LCD FSMC logic. But that is just because of how the components are wired together or the timers etc. are used. You would probably run into the same issues with other boards.
Exactly - but that's a common issue, when using the same timers for different actions - and no problem, as you can easily make some changes there (=use other timers !) to get it fixed.
mikepo :
One drawback I think is that you are basically locked into the Raisonance toolkit and their RLink programmer. You cannot use anything else than Ride7 to debug/program the EvoPrimer as far as I know.
You'll be $1 after you've tested the (way too mighty) Atollic True Studio ! So this is not such a big issue, but the other way round, when trying to use other dev.-boards, and you can't find any support for them in Ride7, that's a true problem !
mikepo :
the ST DISCOVERY boards have an on-board STLink debugger, which again you cannot use with Ride7.
My thoughts: It's a pity ... but that's business.
yrt :
the F107 board have not a Eth port, because the Primer is a portable equipment
Okay - but WHY offering a F107, when they are NOT using that, what's the main reason to take one of those: the Ethernet capability ? They better should have taken a F100 instead: That saves costs $1 !
yrt :
...but can also be used for "serious" development : some customers have used Primer2 as demonstration equipment for extension card developped by them self (ST, Nanotron, Dizic...).
You are right !
Due to your help, I didn't throw out the EvoPrimers. It's actually pretty easy to build little apps in no time ...
when trying to use other dev.-boards, and you can't find any support for them in Ride7, that's a true problem !
Which cards did you talk about ? For example, all ST evaluation cards are supported by Ride7 (STM32, STM8, STR7, STR9, PowerPC...), and any card with JTag or SWD can be driven, if the MCU is supported by Ride7, thanks to RLink debug probe. Notice that some Cortex M3 from other manufacturers will be soon supported (NXP, T.I.).
mikepo :
the ST DISCOVERY boards have an on-board STLink debugger, which again you cannot use with Ride7
Effectively, Ride7 is not yet compatible with ST Discovery, for business reasons; but that could be changed in the future.
Jogi :
but WHY offering a F107, when they are NOT using that, what's the main reason to take one of those: the Ethernet capability ?
We hesitated, and the final choice was to privilege the OTG USB and the 2 CAN channels. An Eth plug is also a little big compared to the available surface of the Evo target board.
