Understanding programmers for microcontrollers
There is no magic sauce, it's all just clocks and data lines going up and down in voltage in the right succession. Sometimes the programming voltages are a bit higher than the normal interface voltages, but that's not hard to reproduce. As you noticed, your arduino can do that too, if you know how the protocol works. And that's where the problem lies.
On one hand the more complex the microcontroller is, the more complex the protocol to program it will be. You will have modes to initialize different forms of memories, set configuration parameters that control fundamental behaviour of the controller (e.g. Atmel "Fuses" which can shut off SPI or disable the internal clock source oscillator). The protocol how to do this is very low level and usually not of interest to the developer who wants to use the controller for his own product. So naturally it is the creator of the microcontroller providing an abstraction layer between controller and PC, which makes it easier to program the controller.
The other aspect is monopoly in order to profit from selling the hardware and software needed to program a certain controller. Most companies aren't interested in making it easy to program their devices with third-party or DIY programmers. Not because they're evil, but simply because it's their price policy to make the controller cheap but the periphery necessary to develop with it expensive, which results in less per-device cost. So some companies might even go the extra mile and add security mechanisms and tamper-proof protocols. A simple example would be a secret key generation algorithm and a key verification algorithm, on the programmer and the controller, respectively. When the programming begins, they perform a handshake with challenge-response-authentication. So even if you sniff the protocol and replay the exact bits on the lines, it won't work because the controller will randomly provide a different challenge at the handshake, and your parrot-programmer will produce a wrong response, telling the controller that it's not talking to the original programmer.
A STMicro ST-Link/V2 can be picked up for ~$22 from Mouser. A ST-Link/V3MINI is only $9.75 from Mouser.
And then you have the MBed compatible STMicro Nucleo series which all have an on board ST-Link/V2-1, which can also be converted to a OEM JLink. The ones on the 64 and 144 pin models can be detached and used stand alone. They range in price from $10(which include some 64 pin parts) to $30. Note, all of the ST-Link/V2-1 allow drag and drop programming, when you plug them into the USB they appear as mass storage.
But the way to do it even cheaper is to buy a 5 pack of blue pills(AKA STM32F103 minimum development board) from Amazon for $16(Prime), and convert 1 of those 5 into a Black Magic Probe. You then have good Cortex-M probe/debugger(JTAG and SWD) and 4 boards to play with. That is what I did for two of my nephews who showed an interest in getting into embedded development.
So no, you do not need a JLink to do ARM development, nor do you have to spend a lot money. If you just want to dabble a little bit, get a NUCLEO-F303RE which mounts a STM32F303RET6, it costs $10.33 at Mouser. This gets you at STM32 with 512KB flash, 64/16KB SRAM, 4 5MSPS ADCs, etc.
Yes, I know it's an older question.
There are four methods to get code into a microcontroller. In order of accessibility:
Bootloader.
This is what the arduino uses. There is code running on the microcontroller that is capable of receiving and programming the internal flash over some interface. In this case UART.In System Programming (ISP)
You use additional hardware to communicate with a peripheral inside the microcontroller to program the internal flash. Or accessing more such are core registers and sram, then it becomes debugging. Of even more by streaming live data to the IDE, as ARM CoreSight can do.
The Arduino based on ATMega chips has Atmel ISP while ARM uses the debug core in their processor over SWD. It does not have any of the other fancy debug features.Off board programming
More common with older parts. You have to take the part off the board, put it in a socket and use specialty hardware to program is.Mask ROM
During manufacturing code is put in the chip using the various lithography steps fabricating the chip. This is permanent and cannot be altered.
When I read about ARM processors, often I read that I need a Segger JLink. Otherwise I cannot program it.
Some chip vendors include ROM bootloaders that can be accessed by an interface when keeping some combination of pins in the correct state on power-up. An example of this would be the LPC11U24 with a USB Mass Storage bootloader. Drag&Drop the .bin file.
Also, what is so special about programmers that it has to be hardware and cannot just be software as long as the microcontroller pins can be hooked up properly and the software can control those pins?
In production, this code would only be used once. During the lifetime it would just occupy expensive flash or ROM real-estate.
If this really is the case, why are Segger products so expensive?
Aside from hardware, they also need to develop software and drivers to be able to support all of the chip vendors and IDE's. You can buy fake JLinks for $10 in china... the hardware is not expensive.
Do not buy fake Jlinks