[sdiy] MCU IDEs
sleepy_dog at gmx.de
sleepy_dog at gmx.de
Sat Feb 20 18:49:41 CET 2016
Hey Barry,
btw I'm the guy with the stupidly named facebook page, asking for your
book some days ago ;)
Just joined this list after you mentioned it, wasn't aware of it!
I'm not familiar with AC6.
Did you use an external ST-link, or a devboard with an embedded one?
The ST-link supports JTAG and SWD (single wire debug, ST specific?)
protocols -- the correct one of which, according to the connection to
your board, needs to be set in the IDEs debugger settings (and a speed
the debugger supports, default usually does it).
Also windows update may install crappy drivers for the derbugger, I'd
get them from STMicro, install manually.
Atollic TrueStudio Lite worked for me so far, although I find their
behavior with regards to include directories reachability from where etc
weird so far.
Some IDEs can only deal properly with at most one of the ST-link connected.
If the ebook teaches the innards of the cortex M3 it would be helpful to
understand why one needs to do all the different kinds of setup things...
the stm32 / cortex M in general are complex beasts, even just their
GPIOs are more complex than in simpler microcontrollers (so I was told,
I only ever used Cortex M for firmware stuff), and all the peripherals,
their clocks etc are disabled by default to save power, and one needs to
set a host of config stuff to get things running :-)
The STMicro MCUs don't only have a datasheet, but seperate documents,
usually a
- datasheet with the electrical specs and peripherals it contains,
- reference manual, giving instructions how to configure periherals, in
all detail, memory maps, registers etc
- a host of separate app note PDFs
- a more generic programming manual for the series, if I remember correctly
What I tend to do lately is to grab the reference manual and read the
chapter about a peripheral I want to use, and use the CMSIS lib register
definitions to implement a driver for it.
The HAL stuff could theoretically be saving time with that, especially
when just trying out and performance is not an issue,
but for me it often cost more time in the end. HAL imposes or at least
"strongly suggests" a rather peculiar structre on the program that uses
it... which I found to be quite an annoyance. (and do they really need 4
or so indirection layers in what should be one callback? Ugh...)
All this HAL API stuff and CubeMX was made to give a quick start,
somewhat taming the complexity of those devices.
I'm not too convinced of the effort so far, though. I do look at working
examples using the HAL to understand how things work.
I learned what I know because we had a guy who has read all the books
from cover to cover, alas I can't currently recommend books myself.
Only "The Definitive Guide to ARM Cortex-M3 and Cortex-M4 Processors" by
Joseph Yiu, which was what he was getting back to mostly.
Steve
Am 20.02.2016 um 17:34 schrieb Barry Klein:
> Maybe you guys have a clue for us then. We are doing stm32L031 product (not EM related). I don't do firmware but was overseeing issues we had and was going to get my laptop setup as a learning platform - with my friend's help. I installed a bunch of various tools - I am not even sure what they do and what uses what. We had two issues - one on my laptop and one on our main pc platform. On the main platform the AC6 stuff was working on the ST eval boards. When we tried using the stlink tool to our board it would not work - it would see it but debugger would not run. We then used the attachment tool off a larger eval board and tied that to our board - would not work either. Like the driver wanted to see the stlink usb device only. ST recommended A6 to us but after seeing our issue they backed off. My friend gave up and spent two hours installing Keil. We then found that the main.c and other files were gone! Luckily I had them on my laptop and we copied them over. This got him up and running. On my laptop the .project file was associated to a program I had installed - Studio Workshop I think it was and was not seen by AC6. Using Windows 10, reassigning the filetype wouldn't work like it used to on XP etc. - not given the right options to reassign to. Probably if I were to delete that Studio Workshop software (Atolic?) it might play nice. I guess it will be a longterm learning exercise for me - this and I want to play with Cypress PSOC BLE stuff and RPI stuff (no way I'm going to get very far with any of it). I should mention there is an ebook on the STM32 (~$15) that seems like it may be good for starters like me. It tried to just replicate my friend's setup so we could do our work - but now he's good I'm going back to the ebook.
>
> Barry
>
>> On Feb 20, 2016, at 4:38 AM, Mikko Helin <maohelin at gmail.com> wrote:
>>
>> System Workbench for STM32 (abbreviated SW4STM32) is the free IDE to
>> use with the STM32 chips these days:
>>
>> http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1533/PF261797
>>
>>
>> It's basically Eclipse + plugin, works fine with STM32CubeMX. Be sure
>> to learn the new HAL library as well.
>>
>> Both SW4STM32 and STMCubeMX also support Linux.
>>
>>
>>
>>> On Thu, Feb 18, 2016 at 10:07 PM, <sleepy_dog at gmx.de> wrote:
>>> I am only familiar with ARM Cortex stuff. There are different implementers
>>> of ARM Cortex M processors, like STM, NXP, even Atmel has some.
>>> Usually (from my experience), there will be IDEs (as in, commercial,
>>> packaged with compiler / linker toolchain) which support a whole range of
>>> MCUs with ARM core (cortex, partially also arm9, arm7) across different
>>> implementers - but not other MCU types like avr or pic.
>>> I don't know anymore what Ksil supports, but believe me, I have looked for
>>> ARM tool chains and have seen none that also supported completely different
>>> MCU cores. That would have to be some behemoth with several compiler suites.
>>> I could be wrong but from what I've seen so far...
>>>
>>> Some IDEs I have at least tried, which all support Cortex M from different
>>> implementers:
>>> (- I hate Keil. Not because it looks like from 1989, but the usability is
>>> similar. And meta infos in project files, seriously? And when I last tried
>>> Keil (V4.x ?), it was not able to do debugging with threads, e.g.. RTOS
>>> based firmware)
>>> - Atollic TrueStudio (eclipse based, some fancy features (some of which are
>>> addons costing extra, like test automation for embedded), Lite version free
>>> but somewhat crippled, full version in the thousands of $)
>>> - Rowley Crossworks (their own editor, used to suck, but has gotten better
>>> over the years. They have a ~ 150 bucks non-commercial license)
>>>
>>> Those two set up all the debugging stuff, I installed it and it just worked.
>>> Tried Olimex and ST-link debug adapters.
>>>
>>> free and open:
>>> - Eclipse-CDT + ARM GCC NONE EABI compiler toolchain + OpenOCD + GDB, then
>>> as debugger perhaps Olimex adapters, or ST-link if you use ST. I like SWD
>>> for my projects -> smaller connector than JTAG
>>> This option used to be (IMO) horrible and frustrating, half baked, half
>>> working, but it is getting less and less so.
>>> You need to set up the debugger settings yourself, there are tutorials. Once
>>> that works, it does so pretty decently.
>>>
>>> Free but not open, and every other version update has some annoying flaws:
>>> - CooCox CoIDE. But a version that works often allows very quick setup of a
>>> project and get going actially initializing some devboard and testing
>>> hardware.
>>> But since you said *reliable*, this is probably not your first choice :-D
>>>
>>>
>>> Steve
>>>
>>> Am 18.02.2016 um 02:59 schrieb Chris Juried:
>>>
>>> Hi Group,
>>>
>>> With all the discussion of Microchip acquiring Atmel, I began to wonder if
>>> there is a group favoured IDE for various MCUs. I am currently using Atmel
>>> Studio for Atmel products and Keil for TI products . If I wanted to expand
>>> to Microchip, TI MSP, Cortex, Parallex, NXT, STM, etc.. products, is there a
>>> recommended IDE that is user-friendly with the many different MCUs
>>> available?
>>>
>>> Sincerely,
>>>
>>> Chris Juried
>>> Audio Engineering Society (AES) Member
>>> InfoComm-Recognized AV Technologist
>>> http://www.JuriedEngineering.com (Juried Engineering, LLC.)
>>> http://www.TubeEquipment.com (Tube Equipment Corporation)
>>> http://www.HistoryOfRecording.com (History of Recording)
>>>
>>>
>>> This e-mail, and any attachments thereto, is intended only for use by the
>>> addressee(s) named herein and may contain legally privileged and/or
>>> confidential information. If you are not the intended recipient of this
>>> e-mail, you are hereby notified that any distribution or copying of this
>>> email, and any attachments thereto, is strictly prohibited. If you have
>>> received this email in error, please immediately notify me at (754) 300-9972
>>> and permanently delete the original and any copy of any e-mail and any
>>> printout thereof.
>>>
>>>
>>> _______________________________________________
>>> Synth-diy mailing list
>>> Synth-diy at dropmix.xs4all.nl
>>> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy
>>>
>>>
>>>
>>> _______________________________________________
>>> Synth-diy mailing list
>>> Synth-diy at dropmix.xs4all.nl
>>> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy
>> _______________________________________________
>> Synth-diy mailing list
>> Synth-diy at dropmix.xs4all.nl
>> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy
More information about the Synth-diy
mailing list