Last week I ordered an ST32VLDISCOVERY evaluation board out of curiosity - what can you do much wrong when paying about US$ 10 for an evaluation board with
- a 32-Bit ARM Cortex-M3 MCU (128k Flash, 8k RAM) - STM32F100RBT6B - an integrated SWD (Single Wire Debug) debug adapter (they use a more powerful STM32F103 than the actual MCU for this and call it Embedded ST-LINK) that can be used as a stand-alone SWD debugger/emulator interface for other STM32 based boards as well - all 64 pins of the STM32100 are brought out on extension headers - 2 user LEDs and one user push button
The advertisement that caught my attention claimed: "Extension header for all QFP64 I/Os for quick connection to prototyping board or easy probing".
The board (I got from Farnell) comes in a transparent plastic sales box - with a card containing some short getting started instructions and links - without any visible static protection. After unpacking the board - you actually have to hold it by the pins to pull it out - I faced the first problem - it won't fit on any of my numerous breadboards! The two main header rows are spaced too wide apart (about 30,5 mm, exceeding the width of the breadboarding area) and the short header row at the small side opposite to the USB connector makes it completely impossible to insert the board into (a) breadboards (the 6 pins PB10 ... PB15 either collide with solid areas or will get shorted).
But then I took two half-sized breadboards and inserted each of the long header rows in one of them ... works perfect (see picture below)! An other good thing is that the pins stick out a good way above the board, enough to attach LA probe cables or female flywires directly!
Power can be either applied via the USB connector - an USB cable is not included in the kit! - or via the header pins (5V or 3V3 and GND) due two protection diodes.
How to get started? All essential documentation and links to the software can be found on the STM32VLDISCOVERY page - user manual for the board and the STM32VLDISCOVERY firmware package. ST provides easy to follow introductions that explain how to develope and debug code for the STM32VLDISCOVERY for 3 development environments - IAR Embedded Workbench - Keil MDK-ARM - Atollic TrueSTUDIO Free versions can be downloaded from the manufacturers' websites - so they are code limited they are sufficient to compile all examples provided and to do some serious evaluation. It's a good starting point, later you can switch to a GCC based free toolchain. For this I chose Atollic TrueSTUDIO STM32 Lite version as it's Eclipse/GCC/GDB based. However, the Lite version supports C only but not C++.
You may want to try the STM32 ST-Link Utility (documentation) as well - it's a stand-alone tool that makes use of the onboard ST-Link interface and allows programming, erasing, tracing, single-stepping and viewing the MCUs core registers from outside the development environment.
For about US$ 10 you get a well designed basic 32-bit ARM Cortex-M3 evaluation board with an integrated SWD debug interface that's supported with good documentation and software. In contrast to many if not most other much more expensive evaluation kits you see these days, this one has (almost) no restrictions - all pins are easily available and can be used for experiments and designs. It's a perfect platform to start exploring the STM32 (value) line of MCUs and for your own perfboard projects.
The most drastic change is that they have replaced the FT232RL with an AT90USB82 (2,-- EUR @ 100qty) for the USB-serial chip!!!
The Arduinos now have their own VID/PID and need no FTDI driver any longer! Like the DP projects that make use of PIC USB MCUs (Flash Destroyer, IR Toy) only an .inf file is needed for the installation.
Maybe we should consider moving away from the FT232R for future projects with MCUs that provide no USB port and look in the direction of PIC18F24J50 or AT90USB82/162 for the USB-serial interface.
I am not sure if this board is the right place to post this but then I got inspired by RJSC's post in the hardware biz section/"distributors be aware" thread on this board in which he "complained" about RIGOL Technologies selling the same digital storage oscilloscope in a 50MHz version (DS1052E) and a 100MHz version (DS1102E) - hardware and firmware are identical, just a few configuration bytes and the model sticker are different (see discussions on the EEVblog.com and RCGroups.com boards and on the hackaday.com site) - so here I go.
After watching David L. Jones' video blogs #70 and #77 on EEVblog.com and since I had planned on buying a low-cost DSO for some time anyway and a local distributer had an attractive summer special, I ordered a RIGOL DS1052E and applied the hack within one hour after unboxing the unit.
The DS1051E came with the new software Ver. 2.04 that prevents the hack from being applied directly (by disabling the model and serial number modification SCPI commands that had been used to perform the hack via RS-232 or USB with earlier software versions). So I downgraded the software to Ver. 2.02 SP2 first (as described by David in his blog #70) and then executed the actual hack (as described by David in his blog #77) successfully.
I have written up a detailed summary of how I executed the hack and share it as a PDF document attached below - to oppose rumors being spread that the hack can not be performed anymore on DS1052Es sold lately (with software Ver. 2.04) - documentation accompanying my unit suggest that it was shipped from China on or after June 19, 2010 (so there is no guarantee that the hack will work on other units shipped earlier or later) - to document the exact steps of how I applied the hack and to share this information with whoever may be interested - to make all looking into buying "cheap" DS1102Es from "unknown" sources (non-official RIGOL distributors/resellers) aware of the fact how easy it is to hack a DS1052E into a DS1102E ... and the likelyhood of some "black sheep" jumping on this bandwaggon and trying to mod and relable DS1052Es and resell them as DS1102Es - but not to encourage anyone who would not try the hack anyway - rather to help those who will attempt the hack anyway to stay clear of some not so obvious pitfalls (I spent a few hours watching David's blogs, reading the various posts on the sites mentioned above and RIGOL docs before I felt cofident that I would be able to apply the hack and ordered the unit)
There is no certainty that RIGOL does not use selected components/assemblies for the 100MHz DS1102E models but it appears rather unlikely. On the above mentioned boards owners of DS1102Es have compared markings of critical components (ADC, memory chips etc) with the markings on the same components in DS1052Es and found no significant differences (except between different revisons or assemblies). On the other side there is no guarantee as well, that the hack can be applied to all DS1052Es and that units will work properly after the hack has been applied. In any case the hack will void the manufacturer's warranty!
In my opinion the Rigol DS1000E series DSOs (still) offer the best value for the money in their class. With prices dropping below US$ 400 for the DS1052E (inluding national shipping and a carrying case - however, not the original RIGOL case) they open up new possibilities for students, hobbyists and professionals that were out of reach before ... I am about to ban the rather cumbersome Hameg and Tektronix analog scopes from the lab but I will keep them as in some cases there is nothing that can beat a good analog scope
After I found and looked at the D model firmware (comes in the same software update packages as the firmware for the DS1052E) I have ordered a DS1052D (basically the same as a DS1052E but with an integrated 16-channel logic analyzer) and will check if the hack will work on this model, too (essentially attempting to hack a DS1052D into a DS1102D) ... most distributors have special "summer break" offers atm with discounts ranging from US$ 100 to US$ 300 or even more depending on the models ...
As of software/firmware version 00.02.04.00.03 it is no longer possible to downgrade with standard RIGOL firmware packages to a version that will allow the hack (you can see the full firmware version by checking via the Utility --> System Info screen)! You will need a modified firmware image or modify the version number in an original image with a hex editor yourself!
Today the Flash_Destroyer kit I had ordered on May 30 arrived (it shipped on June 30). Not sure why Seeed shipped it with DHL, I had selected the free shipping option with Hongkong Post. However, the free priority shipping by Seeed being the real nice part from their side turned into something close to a fiasco due to some security screening at the DHL station in Hongkong, which obviously included unpackaging and improper repackaging during the screening, this leading to damages on a couple of parts included in the shippment.
I am explaining this for a better understanding of the issues I found with the kit. There is only one problem with the kit from Seeeds end, the 24AA01-I/P EEPROM and the ISP header listed on the partlist in the product description are missing in both kits I received:
The 7-segment LEDs have a black front, are marked LS-5161AS and have long, thick round pins. The PCB is yellow as announced.
Seeed added a real nice thing to the kit (which is not on the part list) - two single row 64-pin DIP sockets for the LEDs - one of the slight modifications I descriped in the "Flash_Destroyer free PCB prototype write-up". The LEDs fit nicely into the DIP sockets except for the pins being a bit too long.
The negative side (definitely NOT Seeeds fault) is that the pins of the PIC and the LEDs have been extremely dented and bent during transport due to improper repackaging after the security screening. I will post pictures later ... first I will file a complaint with DHL
Next Ian asked me where he shall send the PCB to and last Saturday (06/05/2010) it arrived ... yesterday I got the tiny 0.125W resistors, finally.
And now we have a second Flash_Destroyer sending a Microchip 24AA01-I/P EEPROM to the grave (while Windows Automatic Update is sending my PC to the grave in the background ...)!
When assembling the Flash_Destroyer I did two slight modifications: a) instead of soldering the 7-segment LEDs directly on the PCB I installed single row DIP sockets ... to be able to remove the LEDs, put in LEDs with other colors ... for flexibility b) and 2 4-contact female headers (Arduino style) instead of the DIP-8 socket for the EEPROM for easy extension/modification ... and built an adapter with an DIP-8 socket for the 24AA01.
All parts are through-hole so assembling the Flash_Destroyer is rather easy ...
Then I tested the assembled board for shorts and installed the bootloader with MPLAB and a PICKit3 (power must be connected to the Flash_Destroyer to program the PIC with an ICD or PICKit!) and used the bootloader to install FD-firmware-v1.1.hex.
... an other Flash_Destroyer sending an innocent EEPROM to SiO[sub:]2[/sub:] heaven ... (not sure what kind of glitch I caught on the first picture - the rightmost digit doesn't look like a number )
Once the test is over, I plan to add a temperature sensor and run the test with an other 24AA01 at 85Â°C and with an automotive grade 24LC01B at 125Â°C ...
Ian, thanks for the PCB and most of all for sharing an other fun project!
[quote author="rsdio"] P.S. While we're talking about breadboards and circuit boards that don't fit, can anyone tell me why it is that all of the SMD adaptor PCBs are so wide? They end up covering 2 or 3 holes on either side of the center, and that's again a lot of real estate. Is there a source for narrow SMD adaptor boards? Ideally, I would prefer 300 mil. [/quote]
rsdio came up with above interesting question. Many others may have asked the same question before ... the obvious answer being that the footprint/size of most SMD ICs up from 14 or 20 pins will not allow them them to be put on .300 mil wide 2-layer PCBs together with the pins/headers.
However, a simple solution would be to think vertical instead of horizontal ... as in breadboarding there is (in theory) infinite space in the 3rd dimension (up!).
Examples for this exist in various multiple degrees of freedom IMUs and other devices, so in most cases for other reasons (orientation of the sensors) - simple example.
I think almost every .600 mil (or other width) wide (2-row, .100 mil spaced) adapter can be modified into a .300 mil wide adapter by installing right angel headers ...
The problem is where to get the long right angel headers from ... straight versions are available in variable lengths ...
A first attempt at modifying standard breakout boards below (left) ...
Would it make sense to design new breakout boards following a more refined concept like shown in the picture on the left?
If this is from the SUMP client then please remove resetting additional comports. Its annoying.
Toshiba Qosmio/Windows 7 32bits.[/quote]
[quote author="ian"] ... Hi ben51 - I'm not sure who is causing that, but I doubt it's the OLS hardware resetting the additional ports. Bug reports for SUMP should be directed to the SUMP project, we're don't maintain that project.[/quote]
[quote author="ben51"] Ian,
Your right, i'll do that. ...[/quote]
@ben51: thanx for the info - from the info you gave it looks to me like this: ...
2. I attached an USB Arduino (actually a Freeduino) to my PC (Windows XP Pro) and performed a quick test running some "fast blinky LED" test on the Arduino (using COM 16) and then connected an OLS (using COM 19) and launched the SUMP Java Client .... BANG the blinking LED stopped and the Arduino performed a reset .... next I started a capture .... BOOM the blinking LED stopped and the Arduino performed a reset again. Whenever I started a capture from the SUMP Java client the Arduino would reset. However, after loading a new sketch to the Arduino - while keeping both the Arduino IDE and the SUMP Java Client open - starting a capture from the SUMP Java client would not reset the Ardino anymore. Next I tried to connect the SUMP client to the COM port the Arduino was using and ... BANG the Arduino was reset. When trying to connect the SUMP Java Client to the OLS I saw for the first time the "device not found" message
I don't think the OLS board has anything to do with the reset of your virtual Arduino COM port, at least not directly - However, I assume that you had absolutely no problem to run the SUMP Java client on your Mac and to connect to the OLS when you launched it the first time since librxtxSerial.jnilib and RXTXcomm.jar were already installed with your Arduino/Processing IDE prior to connecting the OLS for the first time. I would have to test it myself but I assume that your Arduino (actually the connection/virtual COM port) will be reset every time the SUMP Java client is started, at least whenever it opens the COM port to the OLS to initiate a capture ... I have hardly any Java experience but checking the code for [font=courier:]public boolean attach(String portName, int portRate)[/font:] in FpgaDevice.java it seems that a general [font=courier:]detach[/font:] performed before attaching the COM port to the device may actually cause the input stream and the output stream of the "first" open port in the COM port list to be closed ... in your case it's the Arduino's COM port - anyway, I could be wrong here.
I agree with Ian that the SUMP Java client is not maintained by the OLS project ... and the issue does not qualify for an OLS fail.
On the other side there will be a considerable number of OLS users who will want to use the OLS in Arduino development. Since the problem is not restricted to Mac OSX (as shown above) and appears to origin from the SUMP Java client there should be a general interest to get it fixed. Actually the conflicts will not be restricted to the Arduino IDE but extend to all/most Java applications that will make use of librxtxSerial.jnilib and RXTXcomm.jar. I will seperate this part of my post along with ben51s posts and merge them into a new "Conflicts between SUMP Java Client and Arduino IDE" thread later.[/quote]
[quote author="rhyde"] ... The reason I have not seen the arduino interaction problem is I only have one usb port, and have failed on all attempts with powered hubs. So it is clear why I did not hit it.[/quote]
Actually the conflicts will not be restricted to the Arduino IDE but extend to all/most Java applications that will make use of librxtxSerial.jnilib and RXTXcomm.jar.
I hadn't thought of this. Both SUMP and the Arduino IDE use the java rx/tx library. Both the FTDI chip and the OLS appear on the system as a serial port. COuld be an interaction there, but ti seems like no system should reset one serial port when another is added.[/quote]
[quote author="sdixon"] [quote author="ian"] I hadn't thought of this. Both SUMP and the Arduino IDE use the java rx/tx library. Both the FTDI chip and the OLS appear on the system as a serial port. COuld be an interaction there, but ti seems like no system should reset one serial port when another is added. [/quote] Ian- The way most Arduino boards are set up, the processor is wired to reset to the boot loader whenever the DTR line is toggled, which generally happens when the port is opened. This is used by the Arduino IDE to automatically put the processor into the boot loader to load new code (it avoids requiring the user to manually reset the processor each time). So it perhaps isn't surprising that SUMP would cause an Arduino reset when it starts up since it seems to go through all of the available serial ports looking for the FPGA. But it doesn't really make sense that the reset happens each time a capture is started, as people are reporting. Once the correct serial port is selected in SUMP, it shouldn't be messing with any other port.[/quote]