@arhi: looks like you found the essential document for Atollic TrueSTUDIO® - here are the three essential documents for using TrueSTUDIO® for development with STM32VLDISCOVERY:
@Markus: Agreed, the LPCXpresso boards/modules are really versatile and well supported evaluation platforms. They have an on-board JTAG debug interface (based on an LPC3154) you can actually seperate from the MCU part of the boards and use them as a stand-alone debug interface. The LPCXpresso boards are supported by the Code Red Toolchain - the limited but sufficient version (for the LPC1343 based board) is free. Featurewise the available LPCXpresso modules do not compare directly with the STM32VLDISCOVERY (the LPC1114 has far less memory/flash and the LPC1343 and LPC1768 have far more features/on-board peripherals than the STM32F100) but the concepts are very similar and the best documented and supported and affordable entry points into the Cortex-M3 world.
We have used the LPCXpresso LPC1343 board as a starting point for a project and were surprised how easy and simple it was to get the project up and running.
LPCXpresso boards are available from Farnell, Digi-Key and Future Electronics at a little higher price than from Embedded Artists as well (for those who want to save on shipping cost).
I don't want to go into details on this subject (because I don't want my letter mail box flooded with "shut up or cease to exist on this planet" letters) ... I pointed Ian at root/dedicated servers with unlimited/unthrottled traffic in the performance and price range of Hetzner's Xn/EQ4 dedicated/root servers.
The other point is that I don't have the slightest idea about the total traffic and the traffic profile DP experiences ... so it's hard for me to assess what server configuration and amount of included traffic is required. Btw. I know of at least 2 German providers with offers similar to Hetzner.
One example is 1&1 - all offers seem to include unlimited/unthrottled traffic. Funny thing is that the prices are lower if you don't order via their US/English site but via their German site. They are as stable/reliable as Hetzner - at least that's what friends from the US who use them tell me.
/EDIT:/ However, read the fine print (actually all the contractual details) for the 1&1 special offers very carefully. In some cases the price applies for the first 3 month only and rises drastically thereafter and most contracts can not be cancelled for at least 12 month /EDIT/
I was talking about the Xn root servers and not the EQn servers - for the Xn servers Hetzner states (in small print):
Quote
*There are no charges for overage. We will permanently restrict the connection speed to 10 MBit/s if more than 2000 GB/month are used. 100 MBit/s speed can be optionally restored by committing to pay 6,90 € (incl. VAT) per additional TB used.
True, their EQn root servers have 5TB/month traffic inluded.
[quote author="arhi"] [quote author="IPenguin"] Indeed, hetzner root servers are good but you get only 2TB/month at full speed (100MBit/s) [/quote]
you actually get 5T @ 100mbps and then it's throttled to 10MB/s if you don't want to pay 7E/T, compared to how much T cost in the "cloud" that's cheap.
[/quote] The root server provider I suggested to Ian does not offer i7 quad core servers comparable to the Hetzners EQ8, yet - at least they don't offer it as a standard product. Since their data/server center is located in Germany as well and they can't guarantee 100% uptime (so I experienced only a 2h (scheduled) downtime over ther last 24 month period) it may not be an option for you, afterall.
Indeed, hetzner root servers are good but you get only 2TB/month at full speed (100MBit/s). After that they either charge 6.90 €/TB extra or throttel the speed to 10MBit/s for the rest of the month.
If your current server exceeded 2TB traffic last month I may have a better option (e.g. unmetered/unthrotteled root servers for well under US$ 100/month and 100% control over the server and access to it) ... their service is at least as good as hetzner's ... check PM.
Maybe I somehow misunderstood you. The AVRmega's SPI module's functionality (in particular considerations regarding the SS pin) is described in far greater detail in AVR151: Setup And Use of The SPI than in the ATmega48/88/168/328 manual.
I don't think there is a "hidden" way to disable this feature on ATmegas. However, rsdio's idea of asking Atmel tech support may come up with some interesting answer as they have improved the SPI module on their AVR32s - on AVR32s you can disable the detection of NSS being driven low and the resetting/disabling of the SPI module:
Quote
18.7.3.8 Mode Fault Detection A mode fault is detected when the SPI is programmed in Master Mode and a low level is driven by an external master on the NPCS0/NSS signal. NPCS0, MOSI, MISO and SPCK must be configured in open drain through the GPIO controller, so that external pull up resistors are needed to guarantee high level.
When a mode fault is detected, the MODF bit in the SR is set until the SR is read and the SPI is automatically disabled until re-enabled by writing the SPIEN bit in the CR (Control Register) at 1. By default, the Mode Fault detection circuitry is enabled. The user can disable Mode Fault detection by setting the MODFDIS bit in the SPI Mode Register (MR).
Btw. the SPI module in the newer XMEGAs (8-Bit) acts the same way as the ATmega version:
Quote
If the SS pin is configured as an input, it must be held high to ensure Master operation. If the SS pin is input and being driven low by external circuitry, the SPI module will interpret this as another master trying to take control of the bus. To avoid bus contention, the Master will take the following action: 1. The Master enters Slave mode. 2. The SPI Interrupt Flag is set.
I have looked at their blog and store and it becomes more than obvious that they are somehow related regarding their "sources" for parts and designs and if only because both are in the same area and address the same market. I am not talking about simple cloning of designs ... just take a look at Seeeds and their announcement regarding the new (upcoming) generation DSO nano design:
I have split the last two posts of this topic as it continued to drift further away from the original subject. Cortex-M3 based Arduino form factor platforms and IDEs for them based on the original Arduino IDE are a very interesting subject of their own:
The Maple IDEhas already accomplished merging the GCC toolchain for ARM (including Cortex-M3) with the Arduino IDE!
The only major difference will be the peripheral support packages (libraries) for other ARM Cortex-M3 based MCUs (NXP LPC, Atmel SAM3L/SAM3U, Energy Micro EMF32 ...). For the LPC1343 for example the STM32 libraries would have to be replaced by libraries supporting the LPC1343.
After having played around with the Maple and the STM32VLDISCOVERY and having LPCXpresso boards as well, I have been looking in this for the last couple of days a bit ... understanding the structure of the STM32F peripheral support library and how it's integrated into the Arduino/Maple IDE is essential to replace them with the equivalent Atmel SAM3 and/or LPC1343/LPC1768 parts.
Ah, I almost forgot the most important part - the bootlaoder. It will take to port the Maple bootloader to the other platforms as well
In essence following steps are required (no details):
- get a working GCC based toolchain and the peripheral/USB support libraries for the specific ARM Cortex-M3 based MCU family (requires the specific Peripheral/USB support libraries) - port the bootloader and get it working - exchange the peripheral libraries specific to the MCU family - PID/VID ?
This should work for - Atmel SAM3L/SAM3U - Energy Micro EMF32 Gecko/Super Gecko - NXP LPC1343, LCP1768 - TI Stellaris
... and for the ARM7 based MCUs as well, like Atmel AT91SAM7, NXP LPC2xxx (in essence the Netduino and the FEZ platforms could be supported as well) ... in theory.
All this leads to the more general question of (ab)using the Arduino/Maple IDE for Cortex-M3 based designs that have no Arduino form factor (headers) ...
While checking for something in the Watterott store I saw that they sold 28 OLS (22 left) and 49 probe cable kits (1 left) - they had 50 of each on Sept. 30.
The actual PIC32MX "equivalent" to the STM32VLDISCOVERY board would be the UBW32 (32 bit PIC32 based USB Bit Whacker), an open source design by Brian Schmalz. All I/O pins are brought out to headers and it actually fits on a (full-size) bread board because it's less wide than the DISCOVERY and the CUI32... but it shares one issue with the DISCOVERY, the header on the small side opposite the USB connector that can't be populated on the bottom side if you want to use it on breadbords ... anyway it's a minor issue.
The UBW32 ships with a bootloader and StickOS is available for it, too. Like the CUI32 you can buy the UBW32 from SparkFun and some of their distributors for the same price as the CUI32, US$ 39.95 or more than 4 times the price of a STM32VLDISCOVERY.
With the CUI32 and the UBW32 there are some real PIC32MX (MIPS4k) alternatives to the ARM Cortex-M3 based phalanx of boards out there ... if you can live without the onboard (proprietary) debuggers you get with the STM32VLDISCOVERY and the LPCXpresso boards.
I wasn't speaking of the USB interface but pointing at how the issue of making the power supply design (external power in parallel with VUSB) safe can be solved by easy and efficient means.
Obviously the STM engineers don't care so much about EMI via the USB cable shield in the STM32VLDISCOVERY design. In this STM32F103RE (same USB MCU as on the Discovery kit) based inertial sensor platform reference design - which is due to the nature of the analog components used rather sensitive to EMI - they put more effort into noise reduction: a 1M resistor in parallel with a 4.7nF cap between USBGND and the connector shell plus an USBUF EMI filter and line terminator device - usually used in upstrem devices - on the data lines.
/EDIT/
?