it appears I skipped a step and followed the instructions for creating a binary from the online IDE. I've re-read and have just installed and registered/activated Xpresso
STM32 + STlink V2 Clone (or one included on Discovery and Nucleo series of boards) + CooCox CoIDE is I think the closest you will get for free, that resembles a commercial toolchain.
It's generally the same thing as "frankenstein" toolchains (editor, gcc, gdb, openocd, zlin CDT and so on), but all the stuff is already done and configured (CoIDE is a proprietary modified compilation of Eclipse), you only need to install the GCC and provide path to it in the IDE. It has some code generation tools, libraries and so on.
I'll be basically taking the plunge and learning almost from scratch [because CCS was weird]
Not compared to the other people in the EdX class! The class will include people who've taken an introductory CS class that programs in Javascript, and don't quite understand things like "bits." Reading and Helping out on the forums is a education in itself (a worthwhile one, I think.) MOOCs are weird; they have a MUCH wider range of "previous knowledge" than real classes.
My ' Way forward ' was PIC24 . I found 16's a good introduction to the mcu world eventually I was seduced by PIC32 in the form of CHIPkit UNO ..
Now whizzing along with 24 my latest diy lashup PIC24EP512GU810
Very ghetto-ish - liked that. I have a few PIC24F on pcb adapter boards too.
Really nice chips. Way under-marketed by Microchip.
I never got past the obligatory flashing led demo on the pic24's. Having used CCS I got too comfortable with I/O being done for you by the compiler. Things such as UART setup is done with a single preprocessor command at the beginning of your code. I've never been able to get much from the UART in Microchip C without a lot of messing around.
FWIW I had a brief dalliance with CCS about six years ago having been staunchly Microchip C16. However they had a great board at the time, DSP Analog, with a top of the line dsPICs, before the PIC32 was released. While I found the CCS environment OK in itself, I found it altogether too different from the "standard" C and despite building some hardware around their demo board and writing some stuff for it, I went back Microchip's compiler and IDE.
As you say, the programmer can forget about a lot of the intricacies of the devices as it's taken care of for you to a large extent in CCS. However it wasn't long before I found myself constrained by it too.
The thing I despised most about the CCS IDE was the bloody ribbon menu (a la Office) taking up enormous amounts of screen real estate. Another irritating modern day "feature" we have Steven Sinofsky to thank for. I wonder if he did Clippy too?
pmurray4.. Strange I found PIC24 EUART the easiest peripheral to run in C , TX .. check MT flag and write to TXREG . RX.. interrupt writes to circular FIFO and sets flag. Now I2C was a challenge...
I wasn't a fan of the ribbon stuff either. When I started using CCS (at a company I worked for) its IDE was used because the MPLAB IDE at the time would crash a lot (ver 5 or 6, it was in 2006 anyway). I learned C on the job using CCS. I wanted to learn PIC assembly but I had no resources available at the time so I used what I had access to.
22swg: I did all the writing to registers OK, it was the configuration of the clocks and baud that I had the most trouble, whenever I wrote to the UART, I would get gibberish out.
I wasn't a fan of the ribbon stuff either. When I started using CCS (at a company I worked for) its IDE was used because the MPLAB IDE at the time would crash a lot (ver 5 or 6, it was in 2006 anyway). I learned C on the job using CCS. I wanted to learn PIC assembly but I had no resources available at the time so I used what I had access to.
Even MPLAB 8.92, the last release, has, shall we say, "character". MPLAB X is now largely bug free and production strength, but is still nowhere near as fast as MPLAB IDE for the edit-compile-debug cycle. So my default is still the old MPLAB IDE, unless the device isn't supported, when I have to go to MPLAB X.
I'll be basically taking the plunge and learning almost from scratch [because CCS was weird]
Not compared to the other people in the EdX class! The class will include people who've taken an introductory CS class that programs in Javascript, and don't quite understand things like "bits." Reading and Helping out on the forums is a education in itself (a worthwhile one, I think.) MOOCs are weird; they have a MUCH wider range of "previous knowledge" than real classes.
Man, you've got that right. Having relatively little programming experience (LabView doesn't count), I thought I'd be at the bottom of the "previous knowledge" chain - but not even close. Then there were many in the UT embedded class like you with extensive previous background. Amazingly, all seem to have benefited.
I'm still trying to decide which IDE to devote my energy to. The edX embedded class uses the free version of Kiel which I found very nice to use. I'm not sure if or when the limitations of the free version will impact my modest hobby projects. I can't ever see myself being able to justify a full license purchase. I've started to play around with the free CCS which doesn't have those limitations but I do not hear a lot of CCS love coming those with more experience.
I'm still trying to decide which IDE to devote my energy to.
Eclipse is the most versatile IDE IMO. I used it for programming microcontrollers (C/C++), mobile devices (Android, Java) and cloud servers (C++, Java). It also has plugins for many other languages and tools.
I'm still trying to decide which IDE to devote my energy to.
Eclipse is the most versatile IDE IMO. I used it for programming microcontrollers (C/C++), mobile devices (Android, Java) and cloud servers (C++, Java). It also has plugins for many other languages and tools.
CCS is Eclipse based, isn't it?
I'm still trying to decide which IDE to devote my energy to.
Eclipse is the most versatile IDE IMO. I used it for programming microcontrollers (C/C++), mobile devices (Android, Java) and cloud servers (C++, Java). It also has plugins for many other languages and tools.
CCS is Eclipse based, isn't it?
Yes, you are right. This will give you then general Eclipse experience that will be very useful with other Eclipse based products. It may feel sometimes a little too generic for the specific application since it was designed as a flexible IDE framework but once you get the hang it will be useful for other projects.
I don't know about the latest releases but none of the versions I've used were.
Yes, you are right. This will give you then general Eclipse experience that will be very useful with other Eclipse based products. It may feel sometimes a little too generic for the specific application since it was designed as a flexible IDE framework but once you get the hang it will be useful for other projects.
Thanks. Yes, reading more about it, it looks like CCS has been Eclipse based since version 4. It's just an embedded specific overlay. Apparently you can even install it as a plug in to an existing Eclipse installation.
I'll have to spend some more time with it. I do wish it had the (emulated) logic analyzer that Keil has. I find that to be a very usefull debug tool.
I must have stopped using the CCS IDE before it switched to Eclipse, the last versions I used were in the 4 range I think.
I switched fully to use MPLAB as the IDE when I switched to the ICD2 (and then ICD3).
The company I worked for originally had the PICStart Plus, we had to compile in CCS then use MPLAB to flash the hex. was a nightmare until I introduced them to ICSP
I don't know about the latest releases but none of the versions I've used were.
There are three different CCSs, two mentioned inter-changeably in this thread.
They are night-and-day different from each other and are completely unrelated.
I don't know about the latest releases but none of the versions I've used were.
There are three different CCSs, two mentioned inter-changeably in this thread.
They are night-and-day different from each other and are completely unrelated.
Indeed.
The CCS I was referring to was in respect of a proprietary development environment solely for Microchip PICs.
http://www.ccsinfo.com/CCS in the TI world is Code Composer Studio, an IDE for TI's offerings, both ARM and non-ARM, currently Eclipse based, but was their own IDE not too long ago.
Don't know about a third option.
For your second question, my understanding is that ARM product from different vendors differ in the I/O but the general architecture and possibly also basic I/O such as GPIO are similar. I don't really know, others can add more information.
The ARM Cortex core itself provides the NVIC (nested vectored interrupt controller), SysTick (a timer typically used to generate RTOS timer ticks), and very little else. All of the other peripherals, including GPIO, are vendor-specific and vary widely in capabilities and complexity.
Porting from one vendor's ARM Cortex to another's requires a complete rewrite of the peripheral drivers.
the NVIC and SysTick sound very useful.
So I should get used to the coding of the arm then choose a vendor when I'm comfortable and base my designs on that vendor. but I still have the option of moving to a different vendor with only having to rewrite the peripheral drivers?
doesn't sound too bad.
I'm looking forward to what the EdX course teaches me, it starts tomorrow
the NVIC and SysTick sound very useful.
So I should get used to the coding of the arm then choose a vendor when I'm comfortable and base my designs on that vendor. but I still have the option of moving to a different vendor with only having to rewrite the peripheral drivers?
doesn't sound too bad.
I'm looking forward to what the EdX course teaches me, it starts tomorrow
I would pick a platform first, one that has the USB (the right speed) and Ethernet that you want, mindful that it might not be your final one, and run with it.
Exactly as Sal Ammoniac suggests, each vendors' peripheral libraries are different, and there will be fundamentals in the different hardware implementations that means providing your own generic layer except at a very basic level will be difficult. You can only design a more comprehensive generic layer if you know what all the possible hardware options are that you're going to support, and I'd say you'll be facing a losing battle with that one. Just accept that there will be fundamental differences, sometimes even as simple as how to perform atomic GPIO port bit operations.
