Author Topic: microchip or atmel ARM's  (Read 30461 times)

0 Members and 1 Guest are viewing this topic.

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
microchip or atmel ARM's
« on: May 11, 2017, 04:40:14 pm »
I'd like to start looking at ARM uC's. I don't know if microchips IDE supports ARM for free and is a decent compiler available but given the merger should I consider them or plough on with atmel. microchip do have the SAM (atmel) chips advertised on their site so I assume they are not ditching them.
 

Offline mubes

  • Regular Contributor
  • *
  • Posts: 237
  • Country: gb
  • Do Not Boil
Re: microchip or atmel ARM's
« Reply #1 on: May 11, 2017, 05:08:37 pm »
Without wanting to ask dumb questions, but why have you selected atmel/microchip? ST have 50% of the market and cheap starter boards, which means there's a lot of community info out there.

I'm not saying there's anything wrong with your choice, just wondering if you've got a specific reason for making it....when I'm going into a fight, i like to have the odds stacked in my favour.

Dave
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #2 on: May 11, 2017, 05:12:39 pm »
I'm after a free toolchain and some simplicity.
 

Online ajb

  • Super Contributor
  • ***
  • Posts: 2582
  • Country: us
Re: microchip or atmel ARM's
« Reply #3 on: May 11, 2017, 05:16:16 pm »
Microchip doesn't have any ARMs other than the Atmel SAM parts, which are supported by Atmel Studio (as are all of the AVRs) which is 100% free.  I don't know what Microchip's long term plans are for the Microchip/Atmel toolchains, but at the moment I don't think anything has changed since the merger in that realm.

If you don't like Atmel Studio for whatever reason, there's always Eclipse or one of the other pre-packaged ARM toolchains.  I don't think support for Atmel's ICE debugger is very widespread, though, so you might need to use a third-party debug probe like the J-Link with other toolchains.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #4 on: May 11, 2017, 05:24:46 pm »
yes I looked at ST, looked like real hard work to work out how to fire up the software and get anything done.
 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 2328
  • Country: 00
Re: microchip or atmel ARM's
« Reply #5 on: May 11, 2017, 05:28:14 pm »
 

Offline Kremmen

  • Super Contributor
  • ***
  • Posts: 1289
  • Country: fi
Re: microchip or atmel ARM's
« Reply #6 on: May 11, 2017, 05:36:18 pm »
I don't see any good reason why not Atmel. True, ST is very common and i for one do use ST ARMs and kind of like them. Eclipse can be a bittersweet experience but the SW4STM32 (also free) IDE does work OK.
That said, Atmel Studio is easier to setup and use IMO, and combined with e.g. J-Link is easily the equal of Eclipse + ST-Link + OpenOCD.
Nothing sings like a kilovolt.
Dr W. Bishop
 

Offline dgtl

  • Regular Contributor
  • *
  • Posts: 183
  • Country: ee
Re: microchip or atmel ARM's
« Reply #7 on: May 11, 2017, 07:02:36 pm »
ST software offerings were quite non-existant until the recent years. Due to this, the internet is full of different solutions, that different people have come up with for their needs. As of now, the System Workbench (SW4STM32) is their supported and free IDE and toolchain. The toolchain includes graphical pin planning tool, that is the best i've used so far. ST-s development boards are cheap and a lot of them have on-board stlink. Alternatively, the stand-alone st-link can be bought quite cheaply as well, it is also quite cheap and comes in a nice plastic case. For hobbyists, the aliexpress, ebay etc have very cheap STM32F103 boards and ST-link clones, it costs almost nothing to start.
NXP was one of the first to provide free development tools with Code Red's code red studio alongside with cheap development boards and on-board debuggers, that got renamed to lpcxpresso and then bought up by NXP. Lately it was renamed again to mcuxpresso and now they are adding the support for the Freescale Kinetis parts after the merger with Freescale. With the coming of mcuxpresso, the code size limit was lifted and now it is free unless you want support or some advanced features (trace). Their development boards are also quite inexpensive and some have on-board debugger. The original mbed board had nxp mcu, before ARM itself bought them.
Cypress has very good software, sadly windows-only. They have gone beyond what the others have done and a lot of the hardware related stuff can be configured with the GUI wizards. Their PSoC boards are very cheap and most come with on-board debugger.
Silabs with their former Energy Mircro microcontroller line have also a very good free IDE and nice dev boards with integrated debuggers. They are concentrating to the very-low power segment of the market, their tools have power profiling correlated to trace etc.
Atmel's studio is also a quite old piece of software (renamed from AVR studio after they added support to Cortex-M SAM controllers). Also sadly windows-only, although they run gcc under the hood. At the beginning they had re-branded segger jtag/swd probes, that were not that cheap. Now there is Atmel ICE, still quite expensive compared to others.

I'm using usually ST, NXP or Cypress parts, depending on the required functionality. I've had too many issues with Atmel (mainly with SAM9 series, but some SAM3 as well), so now we're trying to avoid their stuff if possible. Also at the last Embedded World, the Atmel was kind of un-represented at the Microchip booth and their booth was one of the most pointless booths at all.
 
The following users thanked this post: Karel

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: microchip or atmel ARM's
« Reply #8 on: May 11, 2017, 07:59:18 pm »
For ATSAM parts your target IDE is still ATMEL studio, which is derived from visual studio.
NXP instead promotes its ide which is derived from eclipse

both have an assortment of very useful plugins, for example one that gives you access to the peripheral registers written in their way, you can flip bits etc. very useful to understand how to set up a peripheral.

Me, i never found ST very attractive. little offerings in small packages and with very little memory. Very hard to understand the documentation (for me)
but they do tend to come with a crapton of timers/pwms/dacs.. if i have to use arm i tend to look at nxp and atsam
 

Offline XFDDesign

  • Frequent Contributor
  • **
  • Posts: 442
  • Country: us
Re: microchip or atmel ARM's
« Reply #9 on: May 11, 2017, 08:35:11 pm »
If you're after spending a few thousand on a compiler, go for something else. If you're after spending lots of money on hardware tools, go for something else. If you're after spending numerous hours trying to piece meal a toolchain for your chosen arm, go with something else.

If you're after writing code and working with an ARM in the quickest way possible, go with the Atmel.

I recommend buying a dev board like this: http://www.mouser.com/ProductDetail/Microchip/ATSAMD21-XPRO/?qs=%2fha2pyFadugeFtluLDCUNfmpIrYOIwyAFtT2psUGQi%2fyMIDajXbM7g%3d%3d
as it includes the programmer on-board, so you're actually up and running in about 10 minutes. I've never been able to say that for any other ARM vendor who I have tried.

Once you want to set out on your own, you will need to buy the SAM-ICE programmer at around $100. The CortexM0 arm is also a very friendly device to get started with, if you have past microcontroller experience.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: microchip or atmel ARM's
« Reply #10 on: May 11, 2017, 08:45:10 pm »
Me, i never found ST very attractive. little offerings in small packages and with very little memory.
They offer up to 2MB flash and 256kRAM, if you want more buy a raspberri pi.
 

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1663
  • Country: us
Re: microchip or atmel ARM's
« Reply #11 on: May 11, 2017, 11:33:11 pm »
yes I looked at ST, looked like real hard work to work out how to fire up the software and get anything done.

Did you expect it to be easy?
Complexity is the number-one enemy of high-quality code.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #12 on: May 12, 2017, 06:30:18 am »
yes I looked at ST, looked like real hard work to work out how to fire up the software and get anything done.

Did you expect it to be easy?

I expect them to talk in easy to understand language for the new comer, we all have to start somewhere. I already have new chips to learn, the software need not be made unnecessarily hard.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: microchip or atmel ARM's
« Reply #13 on: May 12, 2017, 07:11:45 am »
Arm 32 bits start is tough even for an experienced 8 bit software engineer, hardware engineers have to work even harder although they have the benefit of dealing with the peripherals more easily.
 

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: microchip or atmel ARM's
« Reply #14 on: May 12, 2017, 07:40:12 am »
Me, i never found ST very attractive. little offerings in small packages and with very little memory.
They offer up to 2MB flash and 256kRAM, if you want more buy a raspberri pi.

I admit it was a while since i last checked them out. they do have moved to smaller packages and more memory on F0 and F1 line
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4694
  • Country: au
  • Question Everything... Except This Statement
Re: microchip or atmel ARM's
« Reply #15 on: May 12, 2017, 08:09:37 am »
Arm 32 bits start is tough even for an experienced 8 bit software engineer, hardware engineers have to work even harder although they have the benefit of dealing with the peripherals more easily.

As someone about to try and jump into the world of 32 bit arms, any pointers towards why the transistion is hard?
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: microchip or atmel ARM's
« Reply #16 on: May 12, 2017, 08:38:35 am »
I admit it was a while since i last checked them out. they do have moved to smaller packages and more memory on F0 and F1 line
They have this stepping marketing, they offer a lot of different ROM/RAM and packagesizes per base cortex family (M0/M1/M2/M3/M4/M7) when you run out of space on one cortex family you probably have to step up to the next one.
It all has to do with prices. Competitors offer only a few packages with lots of ROM/RAM costing more, that is a choice.

The way I would suggest to work is make an accurate estimation of the total ROM/RAM you need for the final product (code optimized) and add at least 25% for future development/features.
Then and this is a mistake that a lot people make an can cost you, also check out there is an exact same footprint package in the same family preferably the exact same package with around twice the ROM available for development debug purposes. If you don't do that, you can forget in the end of your development that you can still on target debug or you have to mix debug and release modules  :(
I have been burnt before due to lousy estimations from the architects that already designed in a package that was at the end of the line (no larger ROM available) and took many manweeks of extra effort in the end to release the product, been there, experienced it and never again  :)
 

Offline julian1

  • Frequent Contributor
  • **
  • Posts: 721
  • Country: au
Re: microchip or atmel ARM's
« Reply #17 on: May 12, 2017, 09:02:26 am »
I'm after a free toolchain and some simplicity.

On linux, I got started with a stm32f4 board using just vim, gcc-arm-none-eabi, and openocd + gdb with a $10 stlink programmer.
 

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: microchip or atmel ARM's
« Reply #18 on: May 12, 2017, 10:14:45 am »
I admit it was a while since i last checked them out. they do have moved to smaller packages and more memory on F0 and F1 line
They have this stepping marketing, they offer a lot of different ROM/RAM and packagesizes per base cortex family (M0/M1/M2/M3/M4/M7) when you run out of space on one cortex family you probably have to step up to the next one.
It all has to do with prices. Competitors offer only a few packages with lots of ROM/RAM costing more, that is a choice.

The way I would suggest to work is make an accurate estimation of the total ROM/RAM you need for the final product (code optimized) and add at least 25% for future development/features.
Then and this is a mistake that a lot people make an can cost you, also check out there is an exact same footprint package in the same family preferably the exact same package with around twice the ROM available for development debug purposes. If you don't do that, you can forget in the end of your development that you can still on target debug or you have to mix debug and release modules  :(
I have been burnt before due to lousy estimations from the architects that already designed in a package that was at the end of the line (no larger ROM available) and took many manweeks of extra effort in the end to release the product, been there, experienced it and never again  :)


developing always happens with the biggest chip available in the family. eventually you scale back, that's my usual approach. I say eventually because the price difference is usually peanuts and doesn't really make a difference with my numbers :)

but it always comes down to what you need. i needed to make a -very- small gadget that interfaced to two separated can bus-es. the stm32 offering started at 64 pin tqfp. atsamc21 with 2 can bus for 32 pin tqfp (or even qfn, i don't remember. still in alpha stage, design not finalized). atsam was the choice

then i again tend to use nxp LPC.. they have cool shit, like the dual core m4-m0 combo, now with usb that i think it's slightly less broken and as simon says things doesn't have to be unnecessary hard. looking at you, impossible-to-understand stm manuals, with lots of unsaid stuff and differences between registers names from documentation and include files (register access, not hal or whatever. i don't want to think about it ever again.)
and setting up the toolchain. god i want to download an installer. install and start coding.

again, these things might have changed for the better, i hope, but i like those cortex m0+ from atmel and nxp better
« Last Edit: May 12, 2017, 10:28:17 am by JPortici »
 

Offline ptricks

  • Frequent Contributor
  • **
  • Posts: 671
  • Country: us
Re: microchip or atmel ARM's
« Reply #19 on: May 12, 2017, 11:48:53 am »
ST has some powerful and widely used ARM chips but they as a company have never been good at writing easy to understand documentation.
I really like NXP both in the chip and documentation.
My second choice would be cypress .
If just starting out look for the chips that have a serial bootloader burned in ROM that can't be corrupted,these are really easy to get going and don't require any programmer other than a serial port or special software.

 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: microchip or atmel ARM's
« Reply #20 on: May 12, 2017, 12:24:15 pm »
ST has some powerful and widely used ARM chips but they as a company have never been good at writing easy to understand documentation.
I really like NXP both in the chip and documentation.
Same here. NXP's ARM are way more consistent too and had a good serial bootloader from the start.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: microchip or atmel ARM's
« Reply #21 on: May 12, 2017, 04:15:32 pm »
I admit it was a while since i last checked them out. they do have moved to smaller packages and more memory on F0 and F1 line

If you need anything higher end, why would you use the F0/F1 lines? F0 is meant to replace the smallest 8bitters and be as cheap as possible (some cost <$1/piece). F1 is an old entry level line as well.

For more complex stuff take F3/4 or even F7, then you have tons of memory, peripherals, etc. And the prices are still reasonable.
 

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1663
  • Country: us
Re: microchip or atmel ARM's
« Reply #22 on: May 12, 2017, 04:43:10 pm »
I'm after a free toolchain and some simplicity.

How about a free toolchain that works with all ARM Cortex parts? Just take Eclipse, add GCC, and CDT and you're off and running. Takes about thirty minutes to download and install.
Complexity is the number-one enemy of high-quality code.
 

Offline mubes

  • Regular Contributor
  • *
  • Posts: 237
  • Country: gb
  • Do Not Boil
Re: microchip or atmel ARM's
« Reply #23 on: May 12, 2017, 08:00:41 pm »
The problem with a roll-it-yourself is all the detail problems you bump into when something changes (a software version here, an install directory there....) and you don't want that complexity when you're just setting out.  Personally, even now, I prefer a 'clean' gcc/makefile environment to pretty much all the alternatives, but that's not the easy way into this stuff.

I can't speak for the Atmel/Microchip stuff 'cos I've not used their development environments, and maybe it's great, but the pain of ARM falls into two distinct sectors; learning the chip architecture and learning the peripherals.  The chip architecture you can (obviously) use anything from that family for...there's little difference between manufacturers; A missing SYSTICK register here, an MTB there....it's not a big deal and it won't get in the way. A *much* bigger problem is the peripherals; A modern CORTEX-Mx lives or dies on it's peripherals since it's just the same as the next CORTEX-Mx along in most other respects...and those peripherals can be complex.  That means you really want to invest in one family and stick with it as much as possible (based on the assumption that their IP remains consistent across their range...not _always_ the case). From that perspective I would highly recommend the NXP stuff; Very nice, reasonably consistent, peripherals and a decent Eclipse-based/gcc development environment.  A good, flexible, starter chip would be the LPC1549, or the LPC1347 if you want something rather simpler...the LPC5411x is the next step up, and the LPC43's thereafter (LPC4367 features a CORTEX-M4 and two CORTEX-M0s and a shed load of peripherals). They've bundled the chips onto boards which they call LPCXpresso and which also have a debugger (Proprietary, CMSIS-DAP or SEGGER compatible) and quite reasonable library support...although it's not perfect. The merger with Freescale has created an even richer ecosystem, but I do prefer that old Philips  lineage.

ST certainly has the most extensive range, and their M7/H7 chips are very cool, but if you're needing that level of firepower then quite frankly in my opinion you should be looking for something with a real MMU on it (i.e. A-series or MIPS) because with that amount of functionality on board you really should have as much help on your side as possible.

In answer to the OPs original question; No manufacturer is going to dump a line of embedded ARMs, it would be commercial suicide. What they might do is orphan one, but that's no real problem.  There _is_ an investment in learning ARM (and spending your apprenticeship fighting your way out of the Hardfault_Handler) but there's an equal investment in the peripherals to be made .... learning what you can do with the timers on a STM32F4 or the SCT on a LPC4330 is a chunk of effort .... and that's the bit where you want the continuity.

Regards

DAVE
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #24 on: May 12, 2017, 08:27:28 pm »
What interface does a SAM D20 use for programming ? As usual a basic peice of information that I have to dig for and have not found yet. I have an Atmel ICE and it has a same port on it as well as an AVR one and it's 10 pin
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #25 on: May 12, 2017, 08:42:46 pm »
I see the marketing wankers have gotten hold of the SAM dev boards. Farnell want £72 for a ATSAMD20J18 (£2.99 in low volume) on a board with a programmer/debugger and a bunch of headers. I could buy the materials to make a 1 off for that.....
 

Online thm_w

  • Super Contributor
  • ***
  • Posts: 6278
  • Country: ca
  • Non-expert
Re: microchip or atmel ARM's
« Reply #26 on: May 12, 2017, 08:57:07 pm »
What interface does a SAM D20 use for programming ? As usual a basic piece of information that I have to dig for and have not found yet. I have an Atmel ICE and it has a same port on it as well as an AVR one and it's 10 pin

https://hackaday.io/project/6276-sam-d20d21-breakout-board/log/19423-entry-1-32-pin-schematic
http://www.waveshare.com/product/atmel-ice.htm
SWD IO and CLK.

SWO/reset optional as well
Profile -> Modify profile -> Look and Layout ->  Don't show users' signatures
 

Offline hans

  • Super Contributor
  • ***
  • Posts: 1626
  • Country: nl
Re: microchip or atmel ARM's
« Reply #27 on: May 12, 2017, 09:36:45 pm »
What interface does a SAM D20 use for programming ? As usual a basic peice of information that I have to dig for and have not found yet. I have an Atmel ICE and it has a same port on it as well as an AVR one and it's 10 pin

It's on the front page of the datasheet:
"Two-pin Serial Wire Debug (SWD) programming, test and debugging interface"

There are also a whole range of development boards and such made for these low end chips, that a quick peek on those schematics can also help.

In general cortex m-series can all be programmed using SWD. Most chips also support JTAG but doesn't really add much functionality anymore. Yet for most hardware tools SWD is a subset of the JTAG signals, like present on the ordinary 10-pin 1.27mm Cortex Debug connector or 20-pin 2.54mm legacy JTAG.

Regarding learning curve: hmm, yes, they are a bit steeper than 8-bit micro's. Then again, give it a few more years and we will have engineering students that probably don't get to do that many college projects on 8-bit anymore. Too small memory. Too slow. Not the right peripherals. Not the right availability. Cost. Etc.
Perhaps that is already happening

If you can compare micro's from 15 years ago, then todays 8-bit AVRs and PICs are complex beasts.
It just takes time, hard work, being resourceful to master this stuff in due time. Most of the people replying in this topic have probably hundreds if not thousands of hours work done regarding designing and developing firmware, though.

Toolchain: for a bigger, pick something that works. But that can mean that maybe a big $ toolchain is the desirable.
Or try Atmel Studio, if that's free and connects seamlessly to Atmel ARM that's fine. But I haven't tried it, as the later versions dont run on Linux :(
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: microchip or atmel ARM's
« Reply #28 on: May 13, 2017, 04:37:58 am »
Quote
The problem with a roll-it-yourself is all the detail problems you bump into when something changes (a software version here, an install directory there....)
Unfortunately, you don't get rid of this problem just by using a vendor's pre-packaged toolset.  Even with Atmel Studio, you run into gcc, CMSIS, and ASF versioning issues.


Quote
In general cortex m-series can all be programmed using SWD.
This seems to be the general mechanism at the physical layer, but the "flash memory controller" is usually a vendor-proprietary thing, so I think that actually programming the flash usually requires some sort of chip-specific manipulation.


Quote
As someone about to try and jump into the world of 32 bit arms, any pointers towards why the transistion is hard?
The peripherals tend to be especially complex, compared to an 8bit microcontroller.  As someone said, that IS the differentiating feature for ARM-core chips.  Given a 32bit address space, vendors have caught "feature-itis" is bad way; the GPIO interface on an 8bit chip that ranges maybe 1 (8051?) to 4 (AVR) registers now might have 512bytes (128 32-bit registers) allocated to it (probably only uses 40 or so registers, like the SAM3X.)   Those "complex peripherals" include the clock system and memory controller, so it feels like you can't even get started till you've mastered several hundred pages of datasheet.

ARMs are programmed mostly in C, so the vendors provide libraries to do a lot of stuff.   The libraries, of course, expose nearly ALL of the complexities of those fancy peripherals.  But they're documented separately, and perhaps not so well, and they're an excuse for the datasheet to be less well done.   So now, instead of a 500 page datasheet to understand, you have a 1200 page datasheet and 1000 pages of library documentation (which is probably some sort of weird cross-index web document), each of which has garnered only partial attention.

My advice is ... probably don't start from "bare metal" the way you would on an 8bit.  Go ahead and use one of the "toy" environments (MBED, Arduino, etc), or a boilerplate vendor-library skeleton.  Pay no attention to the depressing code size (it doesn't matter - you have a lot more flash than on an 8bit), questions of runtime efficiency (doesn't matter either, for startup code), or general incomprehensibility of what happens before your part of the code starts to execute.  Go ahead and explore from there - either upward into peripherals and features that your "environment" doesn't support, or downward into how it provides the services that it does provide...

 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #29 on: May 13, 2017, 06:02:22 am »
Yes I found a document about programming the SAM D20's with ASF and it was not that enlightening. No list of what stuff you need to write to do what functions. Makes me consider going bare metal.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #30 on: May 13, 2017, 06:30:41 am »


In general cortex m-series can all be programmed using SWD. Most chips also support JTAG but doesn't really add much functionality anymore. Yet for most hardware tools SWD is a subset of the JTAG signals, like present on the ordinary 10-pin 1.27mm Cortex Debug connector or 20-pin 2.54mm legacy JTAG.



Thanks for the connector link, that might have been the next question. I must be mad doing a 30 day trial of circuit studio using my first ARM test board as a test project :(
 

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: microchip or atmel ARM's
« Reply #31 on: May 13, 2017, 06:50:01 am »
Yes I found a document about programming the SAM D20's with ASF and it was not that enlightening. No list of what stuff you need to write to do what functions. Makes me consider going bare metal.

i suggest you open one of the demo projects and start looking at what they did, then do it bare metal (though i prefer to use their functions for interrupt/canbus/usb/etc)

if you get confused, register names should be the same as in the datasheet.
registername.w access the whole register
registername.bit.blabla access the single field

Re: programming, at the end of the datasheet (IIRC device, not reference manual) there is also a bare minimum circuit, the the programming header connections, usb considerations etc.
« Last Edit: May 13, 2017, 06:53:25 am by JPortici »
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #32 on: May 13, 2017, 06:55:27 am »
Yes well my "C" skills are not that well developed either so I tend to fall over quite quickly when looking at other peoples examples. I need things along the lines of "write this to select 12 bits of ADC resolution". the ADC examples in the document did not make anything clear at all. Like you say I'd have to reverse engineer one of the sample projects at which point I end up decoding the bare metal. I'd love to find a nice higher level environment that truly takes care of this stuff. If ASF was all it promised then the arduino would have died a death. Yes ultimately I want to be doing CAN communication and USB is anice as it gives direct access to a PC link instead of going through an FTDI cable.
 

Offline mubes

  • Regular Contributor
  • *
  • Posts: 237
  • Country: gb
  • Do Not Boil
Re: microchip or atmel ARM's
« Reply #33 on: May 13, 2017, 07:08:27 am »
Thanks for the connector link, that might have been the next question. I must be mad doing a 30 day trial of circuit studio using my first ARM test board as a test project :(

...so to my second dumb-ass question then....why are you building hardware when the fundamental problem is a software/firmware one? Cortii are just like any other chip in a similar package...heck, even the LDOs are embedded nowadays so there are no real PSU frets to deal with. The key issue seems to be finding your way around a new software ecosystem....are you falling into the trap I've been in a thousand times of doing the bits you're comfortable with??  >:D

If you want something as close as possible to click-and-go you are going to need something that insulates you from the hardware, and that means an operating system with a good set of drivers. The good set of drivers requirement is the constraining feature in that case, not the chip manufacturer.

The best I've found for completeness is chibios with its hal....but that is pretty much going to constrain you to st, unless things have changed a lot recently......

Dave
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #34 on: May 13, 2017, 07:10:47 am »
Thanks for the connector link, that might have been the next question. I must be mad doing a 30 day trial of circuit studio using my first ARM test board as a test project :(

...so to my second dumb-ass question then....why are you building hardware when the fundamental problem is a software/firmware one? Cortii are just like any other chip in a similar package...heck, even the LDOs are embedded nowadays so there are no real PSU frets to deal with. The key issue seems to be finding your way around a new software ecosystem....are you falling into the trap I've been in a thousand times of doing the bits you're comfortable with??  >:D

If you want something as close as possible to click-and-go you are going to need something that insulates you from the hardware, and that means an operating system with a good set of drivers. The good set of drivers requirement is the constraining feature in that case, not the chip manufacturer.

The best I've found for completeness is chibios with its hal....but that is pretty much going to constrain you to st, unless things have changed a lot recently......

Dave

As i said i am also trialing Circuit studio so I'm trying to use it to design something i may need anyway.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: microchip or atmel ARM's
« Reply #35 on: May 13, 2017, 08:22:28 am »
Yes well my "C" skills are not that well developed either so I tend to fall over quite quickly when looking at other peoples examples.
So learn C first! You can't run before knowing how to walk.
Do you already have the book 'Creating Embedded Systems'? I think this could also be helpful for you.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #36 on: May 13, 2017, 08:31:03 am »
I won't learn C simply by reading a book, I have the 2 most recommended books but i need to use C for something useful for me to retain the information. I mange ok on AVR but even on AVR can fine other peoples programs hard to understand. I don't have the book you mention. I'll have a look.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: microchip or atmel ARM's
« Reply #37 on: May 13, 2017, 10:53:06 am »
I won't learn C simply by reading a book, I have the 2 most recommended books but i need to use C for something useful for me to retain the information.
I hear you but sometimes you just have to take a step back in order to go forward otherwise you keep banging your head against a wall.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #38 on: May 13, 2017, 11:15:12 am »
True

I try to learn a bit of everything as I go along.
 

Offline asgard20032

  • Regular Contributor
  • *
  • Posts: 184
Re: microchip or atmel ARM's
« Reply #39 on: May 13, 2017, 11:27:02 pm »
I mange ok on AVR but even on AVR can fine other peoples programs hard to understand.

C is probably the easiest language to learn : few keyword, easy syntax... THE LANGUAGE ITSELF IS EASY, no one can argue with that. The challenge is doing something with it. Contrary to other language, the C standard library is... very modest about what it does. Most of the time, you have to reinvent the wheel. Also, the second challenge is about programming logic. Even if you know the language, being able to do something with it, or to be able to read others people program, require some programming logic. Programming logic is independent of the language. So even if you know a language, you need to have a good programming logic to understand, how a particular program is working.

So you will have the same challenge if you switch to other language, like say python. Even when you will know the language, you still will have a hard time to understand others people program, as long as you won't have reached a certain level in your programming logic.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: microchip or atmel ARM's
« Reply #40 on: May 13, 2017, 11:45:35 pm »
Even when you will know the language, you still will have a hard time to understand others people program, as long as you won't have reached a certain level in your programming logic.
It is up to the programmer to spice the code with enough comments so every colleague can read and understand the code without brainwarping.
For a codereview you have a few hours not an entire day or more to figure it out.
If the code is not obvious or thoroughly explained in the comments, I just return it with a fail!
 

Offline asgard20032

  • Regular Contributor
  • *
  • Posts: 184
Re: microchip or atmel ARM's
« Reply #41 on: May 13, 2017, 11:52:42 pm »
It is up to the programmer to spice the code with enough comments so every colleague can read and understand the code without brainwarping.

Enough comment? A code should almost never contain comment. People should ALWAYS write self describing code. Just by using significant variable name, significant function name, and by doing the code enough modular, comment can be avoided. Comment are the cancer of programming. What do you trust more, comment or code? Its hard to be sure that comment are really up to date with the code.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: microchip or atmel ARM's
« Reply #42 on: May 14, 2017, 12:11:45 am »
It is up to the programmer to spice the code with enough comments so every colleague can read and understand the code without brainwarping.

Enough comment? A code should almost never contain comment. People should ALWAYS write self describing code. Just by using significant variable name, significant function name, and by doing the code enough modular, comment can be avoided. Comment are the cancer of programming. What do you trust more, comment or code? Its hard to be sure that comment are really up to date with the code.
Then we disagree. We use doxygen, the comments are used to generate the documentation, works brilliantly and the documentation is always upto date with the code. Try that without (doxygen) comments.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: microchip or atmel ARM's
« Reply #43 on: May 14, 2017, 04:13:48 am »
Quote
I won't learn C simply by reading a book, I have the 2 most recommended books but i need to use C for something useful for me
Well, yeah.  This is true of any language.  And sadly, a lot of the complex C projects that might otherwise be good to look at, get "polluted" with stuff to make them portable to N different chips, M different OSes, O different compilers, and P different host/ide environments.  And also, a lot of the things that one DOES want to do with a microcontroller frequently turn out to be too simple to really get familiar with the language (which makes things like the huge mass of non-programmer "Arduino programmers" possible, which is not necessarily a bad thing...)


Quote
We use doxygen, the comments are used to generate the documentation, works brilliantly and the documentation is always up to date with the code.
Meh.   Documenting every function is not the same as having adequate documentation.  This is probably 50% of the problem with a lot of the vendor libraries - they've got Doxygen comments for every function, and they think they're done.   But there's no overall documentation describing design philosophy or general "theme" of how things work, so it's difficult to figure out if you're trying to figure out how to use it from scratch (a sort of "bottom up" vs "top down" problem.)   I first used self-documenting code like that back in '78 or so (did you know that the DEC "Runoff" document processor would accept source code files, and only look in comments for text/commands to produce a document?  Run the same source through a MACRO-10 and RUNOFF, and you'd get an executable and a pretty document.)  It had the same problems back then, and I only did it once...
 
The following users thanked this post: HackedFridgeMagnet, newbrain

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: microchip or atmel ARM's
« Reply #44 on: May 14, 2017, 05:55:26 am »
Yes well my "C" skills are not that well developed either so I tend to fall over quite quickly when looking at other peoples examples. I need things along the lines of "write this to select 12 bits of ADC resolution". the ADC examples in the document did not make anything clear at all. Like you say I'd have to reverse engineer one of the sample projects at which point I end up decoding the bare metal. I'd love to find a nice higher level environment that truly takes care of this stuff. If ASF was all it promised then the arduino would have died a death. Yes ultimately I want to be doing CAN communication and USB is anice as it gives direct access to a PC link instead of going through an FTDI cable.

but asf is easier (to me / than other libraries) but as with anything you have to familiarize with it. it's not about "C", at all. And you still have to know your device or at least have the device/reference manual at hand to know what to do and what name they have used for the more verbose defines.

just for your ADC example, all of these are interchangable

DATASHEET: "For 12bit operation bit six of ADCCON1 must be set to zero."
HAL#1: ADC_SET_ADCCON1(_ADC_RES_12BIT);
HAL#2: you have a structure and one of the field is resolution, so something like adccon.resolution = _ADC_RES_12BIT and the ADC_SETUP(&adccon);
BARE METAL Microchip: ADCCON1bits.RES = 0; or ADCCON1 &= ~(1<<6);
BARE METAL Atmel: ADCCON1.bit.RES = 0; or ADCCON1.w &= ~(1 << 6);

and so on. you should see the similarities. but first you had to read the datasheet to know why the bit was set to zero.

At the very least if you don't want to read the datasheet (very bad idea) then there is the library documentation which tells you what the defines are and the functions are, and their description. Or also the include file, at some point that should be self explanatory
« Last Edit: May 14, 2017, 06:06:56 am by JPortici »
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #45 on: May 14, 2017, 07:41:44 am »
I just get the feeling that as I need to read the documentation anyway it won't take ling to write my own library. Or I could read the datasheet and try and fathom out the loose instructions to ASF. I have already done some work on AVR with basic port defines that mean something without comment and management of PWM and analogue.
 

Offline mubes

  • Regular Contributor
  • *
  • Posts: 237
  • Country: gb
  • Do Not Boil
Re: microchip or atmel ARM's
« Reply #46 on: May 14, 2017, 08:49:03 am »
Checkout CMSIS .... It's basic port defines but no additional crud. Building your stuff on top of that means you don't get addresses wrong.

Dave
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #47 on: May 14, 2017, 09:13:12 am »
err, CMSIS seems to be a whole development platform of it's own but I'm still looking at it. Looks like the sort of thing Atmel would have based ASF on ?
 

Offline mubes

  • Regular Contributor
  • *
  • Posts: 237
  • Country: gb
  • Do Not Boil
Re: microchip or atmel ARM's
« Reply #48 on: May 14, 2017, 10:36:25 am »
CMSIS is lots of things but, at its core, is a set of include files that define symbolic names for all of the peripheral registers and bits within them.  On top of that are 1001 other things, but the core bit has zero overhead and is (hopefully) accurate for your chip.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: microchip or atmel ARM's
« Reply #49 on: May 14, 2017, 10:39:40 am »
Quote
We use doxygen, the comments are used to generate the documentation, works brilliantly and the documentation is always up to date with the code.
Meh.   Documenting every function is not the same as having adequate documentation.  This is probably 50% of the problem with a lot of the vendor libraries - they've got Doxygen comments for every function, and they think they're done.   But there's no overall documentation describing design philosophy or general "theme" of how things work
:-+ So true! Doxygen created documentation isn't documentation. I can get the same information from Eclipse and that keeps realtime track with the source. What needs to be documented (and often isn't) is why a piece of software is structured the way it is.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #50 on: May 14, 2017, 10:40:05 am »
Well I am assuming that Atmel studio already dos this. For example I refer in my defines to PA1, PA2 etc, not port/pin addresses. What I was planning to do was do the same, I believe that the names carry across from one ARM to another particularly in the same family so I could start with a 32 pin chip and then decide to move my code to the 48 pin version and my code and definitions still work, I noticed this would not have worked so well on AVR with register names or locations of bit in registers being different between an ATtiny24 and the ATmega328,
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: microchip or atmel ARM's
« Reply #51 on: May 14, 2017, 12:31:10 pm »
What needs to be documented (and often isn't) is why a piece of software is structured the way it is.
Thats the software architecture and software design documentation which should be finished before any loc is written
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #52 on: May 14, 2017, 12:33:24 pm »
What needs to be documented (and often isn't) is why a piece of software is structured the way it is.
Thats the software architecture and software design documentation which should be finished before any loc is written
You wanna bet ? 😂


Sent from my Moto G (4) using Tapatalk

 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: microchip or atmel ARM's
« Reply #53 on: May 14, 2017, 12:36:13 pm »
What needs to be documented (and often isn't) is why a piece of software is structured the way it is.
Thats the software architecture and software design documentation which should be finished before any loc is written
You are right to use the words should be. With good design document you don't need the Doxygen generated crap.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: microchip or atmel ARM's
« Reply #54 on: May 14, 2017, 02:12:31 pm »
Ymmv i found doxygen extremely usefull to get a global function and module calls picture on unknown software i had to add code to. It showed some problems with sw eng. Not sticking to the architecture and calling hw peripherals directly in their modules instead of using the hal.
Try that without pictures with over 1 million locs in your devtree.
Then if you have a small sw stack and a one or two person sw team it might be overkill.
 

Offline h00p

  • Newbie
  • Posts: 2
  • Country: us
Re: microchip or atmel ARM's
« Reply #55 on: May 14, 2017, 02:24:48 pm »
Yes well my "C" skills are not that well developed either so I tend to fall over quite quickly when looking at other peoples examples. I need things along the lines of "write this to select 12 bits of ADC resolution". the ADC examples in the document did not make anything clear at all. Like you say I'd have to reverse engineer one of the sample projects at which point I end up decoding the bare metal. I'd love to find a nice higher level environment that truly takes care of this stuff.

Sounds like you'd be very happy with the Teensy 3.x line of dev boards, which are based on NXP Cortex-M4: https://www.pjrc.com/teensy/index.html

Programmed through USB, and virtually every Arduino library is supported, so it's extremely easy to get up and running.  You can use any IDE you want, including the free Arduino IDE (with a free Teensy-specific wrapper called Teensyduino).

To your example, getting data from the ADC is easy.  Treat it like an Arduino and use analogRead() to get 10-bit data, or load up the Teensy ADC library (with a mouse click) and run

ADC *adc = new ADC();
adc->setResolution(16); // 16-bit resolution
int value = adc->analogRead(readPin);

Easy peezy.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #56 on: May 14, 2017, 03:50:12 pm »
Yes I have a couple of teensy's but I'd like something I can production use more easily. Plus at some point I'd need to move off the arduino environment and then where do I go?

Sent from my Moto G (4) using Tapatalk

 

Offline danadak

  • Super Contributor
  • ***
  • Posts: 1875
  • Country: us
  • Reactor Operator SSN-583, Retired EE
Re: microchip or atmel ARM's
« Reply #57 on: May 14, 2017, 07:13:35 pm »
Cypress PSOC (ARM core) -

An excample -

https://www.google.com/search?q=cypress+psoc+digital+filter+image&rlz=1C1PRFI_enUS740US740&source=lnms&tbm=isch&sa=X&ved=0ahUKEwj09v6Ei_DTAhVT02MKHcUBAzwQ_AUIBigB&biw=1874&bih=923#tbm=isch&q=cypress+psoc+digital+filter+image+hackster&imgrc=-OyYm9-BDvawAM:

For me what stands out is -

1) Routability
2) Fast 12 bit SAR A/D and slow 20 bit DelSig
3) DFB (Digital Filter Block) that is dual channel, handle FIR or IIR filters, or DFB
can be used as a GP fast processor block, similar to RISC block
4) MSI logic elements GUI based and/or the UDB Verilog capability. Eg. the FPGA
like capability
5) Onboard Vref
6) IDAC, VDAC, OpAmps (up to 4), comparator, mixer, switch cap, analog mux....
7) LCD,  COM, UART, I2C, I2S, One Wire, SPI, Parallel, LIN, CAN, BLE, USB
9) Custom components capability, create with schematic capture or Verilog
10) DMA to offload processes like filters, COM, Display
11) ARM M0 (PSOC 4) or M3 (PSOC  5LP) or 8051 core(PSOC 3)
12) Extensive clock generation capabilities
13) All components supported by extensive prewritten APIs

https://www.element14.com/community/thread/23736/l/100-projects-in-100-days?displayFullThread=true

http://www.cypress.com/documentation/code-examples/psoc-345-code-examples

Great video library

Attached component list.  A component is an on chip HW resource.

Free GUI design tool with schematic capture, "Creator". Components have rich API library attached
to each component. Compilers free as well.

PSOC 4 is low end of family, consider 5LP parts as well. PSOC 4 also has arduino footprint boards (pioneer) as well

https://www.elektormagazine.com/labs/robot-build-with-cypress-psoc

http://www.cypress.com/products/32-bit-arm-cortex-m-psoc



Regards, Dana.
Love Cypress PSOC, ATTiny, Bit Slice, OpAmps, Oscilloscopes, and Analog Gurus like Pease, Miller, Widlar, Dobkin, obsessed with being an engineer
 

Offline donotdespisethesnake

  • Super Contributor
  • ***
  • Posts: 1093
  • Country: gb
  • Embedded stuff
Re: microchip or atmel ARM's
« Reply #58 on: May 15, 2017, 09:38:56 am »
Yes I have a couple of teensy's but I'd like something I can production use more easily. Plus at some point I'd need to move off the arduino environment and then where do I go?

I know your problem, when moving to ARM there is a lot of choice, and there is a lot of new info to sift through. I wouldn't expect newcomers to know that SWD or EDBG are anything to do with debug.

I've tried several of the ARM cortex M0/M3/M4 offerings, in order of "easiness" - a combination of availability of cheap tools, good online info, and built-in bootloader:

NXP LPC812, LPC1343
STM32 e.g. F103, F072
Atmel D10, D20, SAM3S

Infineon XMC1302
Freescale K10,K20

Atmel is not a bad place to start, plus there is also "official" Arduino support for D20. For cheap dev boards, look at http://uk.farnell.com/microchip/atsamd10-xmini/eval-brd-samd10d14a-smart-mini/dp/2451533 or http://uk.farnell.com/atmel/atsamd21-xpro/evaluation-board-sam-d21-mcu/dp/2407175. Those boards come with USB debug (EDBG). For rolling your own, I would get ATMEL-ICE http://uk.farnell.com/microchip/atatmel-ice-basic/debugger-atmel-arm-avr-basic-kit/dp/2407172 Then all you need is Atmel Studio 7.

The other vendors have similar debug boards and free tools. If you are expecting to try a few different vendors I would recommend JLINK-EDU.
Bob
"All you said is just a bunch of opinions."
 

Offline Gibson486

  • Frequent Contributor
  • **
  • Posts: 324
  • Country: us
Re: microchip or atmel ARM's
« Reply #59 on: May 15, 2017, 12:42:56 pm »
I am late to this, but the reason to use Atmel is that they have a really good dev package and very solid documentation. 

The reason to use ST is because they are a bit better hardware wise (small m4 core package in Atmel? no way...) and they own a huge market share, so there really is no need to worry about stuff being obsolete (not that it is an issue with Atmel).

My biggest reason for liking ST is the cheap debugger. Atmel has one that is relatively cheap, but not as cheap at the ST one. All use ARMs do have SWD or JTAG, so this may be a non issue if you already have a JTAG.

If you really want to get the most out of learning something, you may want to do everything off of the CMSIS library. That way, you learn how to interface with the chip directly without using those painful libraries that some (ahem...ST) manufacturers include. It has the biggest learning curve by far, though. Also, if you move to a different platform, the change will be "easier" (I said easier, not easy).

For learning, just pick platform and start. My first was Freescale. I made LEDs blink and talked I2C and SPI. Using the libraries was easy. When I moved to ST (because of work), it was like a whole new universe. I had to change IDE (Freescale has a decent IDE once you get it going) and it did not work out of the box. The libraries kind of worked, but I ended up just working backwards until I realized that if I just use the CMSIS. I can get it to do exactly what I want, but it takes  A LOT of effort.



« Last Edit: May 15, 2017, 12:54:56 pm by Gibson486 »
 

Offline Gibson486

  • Frequent Contributor
  • **
  • Posts: 324
  • Country: us
Re: microchip or atmel ARM's
« Reply #60 on: May 15, 2017, 01:03:50 pm »
Yes I have a couple of teensy's but I'd like something I can production use more easily. Plus at some point I'd need to move off the arduino environment and then where do I go?

Sent from my Moto G (4) using Tapatalk

You can always buy the equivalent Freescale dev board...the only caveat is that you have to switch between boards when you switch environments.
 

Offline Syntax_Error

  • Regular Contributor
  • *
  • Posts: 204
  • Country: us
Re: microchip or atmel ARM's
« Reply #61 on: May 16, 2017, 02:18:18 am »
Google turned up nothing under that exact title. Do you perhaps refer to this similarly named title: 'Making Embedded Systems: Design Patterns for Great Software'?

https://www.amazon.com/Making-Embedded-Systems-Patterns-Software/dp/1449302149/ref=pd_sim_14_4?_encoding=UTF8&pd_rd_i=1449302149&pd_rd_r=V9TR6BSQ6H70EYM4SFX2&pd_rd_w=92ZUa&pd_rd_wg=Kfilh&psc=1&refRID=V9TR6BSQ6H70EYM4SFX2
It's perfectly acceptable to not know something in the short term. To continue to not know over the long term is just laziness.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3998
  • Country: nz
Re: microchip or atmel ARM's
« Reply #62 on: May 18, 2017, 08:34:53 am »
The problem with a roll-it-yourself is all the detail problems you bump into when something changes (a software version here, an install directory there....) and you don't want that complexity when you're just setting out.  Personally, even now, I prefer a 'clean' gcc/makefile environment to pretty much all the alternatives, but that's not the easy way into this stuff.

"Even now"?

ARM is an absolutely mainstream CPU. It has great support in both major free compilers, gcc and llvm.

For me, I can't imagine anything simpler than using gcc (with make or ninja whatever to drive recompilation), the appropriate tool to talk from the host to the particular dev board (OpenOCD, AVRDude, ADB (Android) or whatever), gdb, and if necessary the appropriate tool to convert an elf file into the appropriate load format for the board (hex, binary, whatever). One job, one tool, and you change only the tools.

I've been programming professionally for 30 years but I've never been able to get my head around Eclipse. It just seems nuts to me. Visual Studio or XCode are a bit better, but still waaay too "magic" and impenetrable for my taste. Let me choose my own editor (that's another job, so another tool ...)
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: microchip or atmel ARM's
« Reply #63 on: May 18, 2017, 08:12:37 pm »
Quote
I can't imagine anything simpler than using gcc...
I agree with you almost 100%
Where "just use gcc" starts to fall apart is when you start needing multiple cross compilers.  Sure, you can download the arm version of gcc or llvm, but then you need to get the correct .h files defining peripherals for the chips you're using, and maybe a different set of newlib build options (the arm download does already have newlib, which is something.  But ... maybe not the version you need...) (or maybe a different libc or libgcc or libm.)   And linker maps and a possibly bewildering array of compiler options so that it won't end up generating instructions that don't work on your chip.   And perhaps other stuff as well.  And then it would be nice if you had some sort of logical directory/file structure for the tools so that if you switch chips, you can add the second vendor without messing up the first.  And if your OS of choice isn't development-friendly (*cough* windows), you probably have to install make separately, and programmer tools separately, and a bunch of other stuff that makefiles commonly use...
A chip-vendor-packaged IDE will do that for you; for a single vendor's chips.  Keil or IAR will do that for you, for $$$$.
You probably need to download the vendor's IDE just to extract the chip .h files anyway.
Grr.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: microchip or atmel ARM's
« Reply #64 on: May 18, 2017, 08:47:43 pm »
Hmm... I'm using GCC but never have any of those problems.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: microchip or atmel ARM's
« Reply #65 on: May 18, 2017, 09:13:54 pm »
Against all warnings and hate threads and other anti ST campaigns I decided for a next project to just try out the CubeMX / SW4STM "experience"  ;D
Bought a few nucleo 476 boards and downloaded a lot of stuff from st.com
Yesterday evening I spent two hours installing and watching some youtube movies instead of reading 5000 pages of manuals  ;D
I am old school but lets do this the 21st century way, leave the books and follow the video.
This evening another three hours watching some youtube instruction movies and just went for it.
Downloaded and installed the packages for the STM32L4 family and tried to create a blinky.
First tries failed miserably because I choose the nucle board layout with tons of peripherals that are not configured ok it seems or I have to do some extra stuff.
So followed the kid on the video erased all pins and defined a couple of pins for the simple experiment.

Total of five hours and I have a blinky, MX generates the code for whatever toolchain you want (IAR,Keil, SW4STM and some other stuff), i choose the SW4STM and can now compile, run and debug.
Yeah, I am totally happy actually after all the hate threads I read earlier. Total code size for my debug blinky is 5kB which can be considered large (although I think it is peanuts if you look at everything that needs to be initialized) yes but hell my $7 chip has 1MB , who gives a *(&^ ?
Then the clocksettings are a miracle, you can just see the page from the datasheet as a GUI, experiment with all the settings and directly see if something is going wrong (out of the correct parameter space) and let MX correct it automagically. Beautifull, I can't see why someone does not love this.

The thing I do not like is the comment in between where the user can put its code, rather ugly but necessary if you want MX to change something and re-generate the rest of the code.
Perhaps in a few weeks when I am struggling with some peripherals my experience will change but for now I am really puzzled why there is so much anger against this 100% cost free toolchain.
 

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1663
  • Country: us
Re: microchip or atmel ARM's
« Reply #66 on: May 18, 2017, 09:19:15 pm »
ARM is an absolutely mainstream CPU. It has great support in both major free compilers, gcc and llvm.

If you have performance requirements, you should benchmark the available compilers before choosing one. The free compilers may not be the best performers for your particular application.

According to my benchmarking, I found that the IAR compiler generated the fastest code, followed by Keil (the original compiler), then GCC, and finally LLVM in last place. The IAR generated code was about 12% faster than GCC in my tests.
Complexity is the number-one enemy of high-quality code.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #67 on: May 19, 2017, 07:05:58 am »
if only I could find where to download STM cube etc, this is why I shy away, if they can't even give you the stuff without you have to search high and low will they have bothered to make it usable ????
 

Offline poorchava

  • Super Contributor
  • ***
  • Posts: 1672
  • Country: pl
  • Troll Cave Electronics!
Re: microchip or atmel ARM's
« Reply #68 on: May 19, 2017, 07:25:28 am »
I've worked quite alot with STM32F4 and SAM4 for cuite complex projects and I'd compare them in a following way:

SAM4SAM7:
-simpler peripherals than STM32F4
-typically less current consumption than similar STM32F4
-IDE is free, quite easy to use (being based on Visual Studio)
-MUCH simpler and less powerful DMA engine than STM32F4
-timer module can only be described as completly f***cked up.
-SAM7x parts at 300MHz are the fastest ARM microcontrollers on the market, until STM32H7 goes into full procduction
-ADCs have overall better analog specs (INL, DNL, noise etc) than STM32s
-literally the first uC where I was able to get I2C up and running in and hour or so without any issues. At the cost of I2C module simplicity
-f***cked up pinouts, eg SPI pins scattered all over one side of a QFP

STM32F4/F7:
-complex peripherals with many configuration options like injected ADC conversion modes, ADC interleaving, timer chaining etc
-FMC / FSMC if great for driving graphical LCDs, RAM, FLASH or simply fast uC-uC communication
-some have DSI controllers
-Very powerful DMA engine
-some have a 2D graphics accelerator which is essentially a 2D-array oriented DMA engine with some simple math functions (eg add x to all calues in array etc)
-typically cheaper for similar flash and RAM capacity than Atmel
-lots of free IDEs, but neither one of them is a proffesional grade tool that would compare with Visual Studio. STM32s are supported by VisualGDB though. STM's "own" IDE is made by a 3rd party, based on eclipse and is a pain to use IMO.


I love the smell of FR4 in the morning!
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #69 on: May 19, 2017, 07:42:21 am »
ok but I am looking at M0 here and I can't even find any ST software on their fucked up pointless website.
 

Offline gmb42

  • Frequent Contributor
  • **
  • Posts: 294
  • Country: gb
Re: microchip or atmel ARM's
« Reply #70 on: May 19, 2017, 11:41:15 am »
Relatively easy, home page (http://www.st.com), from the menu Tools & Software then in the submenu Software Development Tools, then on that page use the Product Tree menu, open the STM32 Software Development Tools item and click on the STM32 IDEs link.

You should end up [http://www.st.com/en/development-tools/stm32-ides.html?querycriteria=productId=LN1200]here[/url] which has a list of 22 items to select from.

Or just Google "STM32 IDEs" which gets me the same page as the first link.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3998
  • Country: nz
Re: microchip or atmel ARM's
« Reply #71 on: May 19, 2017, 11:48:02 am »
ARM is an absolutely mainstream CPU. It has great support in both major free compilers, gcc and llvm.

If you have performance requirements, you should benchmark the available compilers before choosing one. The free compilers may not be the best performers for your particular application.

According to my benchmarking, I found that the IAR compiler generated the fastest code, followed by Keil (the original compiler), then GCC, and finally LLVM in last place. The IAR generated code was about 12% faster than GCC in my tests.

I write compilers and JITs for a living, including on various flavours of ARM from IoT to smartphones. I seldom see more than 1% or 2% difference between gcc and llvm on real programs.

I don't know what your benchmark is, but if you see that big a difference then it's probably either:

- a microbenchmark where a single instruction plus or minus makes the difference.

or

- non-equivalent code generation models, ABIs, or optimisation levels.

You should probably write the critical loop or function in assembler anyway if the last 10% is so important to you.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #72 on: May 19, 2017, 12:08:13 pm »
Relatively easy, home page (http://www.st.com), from the menu Tools & Software then in the submenu Software Development Tools, then on that page use the Product Tree menu, open the STM32 Software Development Tools item and click on the STM32 IDEs link.

You should end up [http://www.st.com/en/development-tools/stm32-ides.html?querycriteria=productId=LN1200]here[/url] which has a list of 22 items to select from.

Or just Google "STM32 IDEs" which gets me the same page as the first link.

And STM cube etc is not on the list, of what is on the list I have no idea of what I need, this is why I just looked at the SAM D20 as I have the IDE with no messing about and I am familiar with Atmel datasheets. I have since learned that D21 is a better series and that D20 was a mess because it was their first one.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: microchip or atmel ARM's
« Reply #73 on: May 19, 2017, 12:40:26 pm »
ok but I am looking at M0 here and I can't even find any ST software on their fucked up pointless website.
Sorry to say but you sound like a young kid that does not get his toy to run after 5 minutes.
If that is the effort you want to invest in this endeavour I would quit now, because there are very heavy storms ahead on the ARM seas (5000+ pages of datasheet/refmanual/prog manual/arm core etc.)

First you have to get an account on the st site before you can download any software.
Then spent a few hours of reading about the topic, watching youtube or the stm forum and you know exactly what you need and if you still don't get it read my above post:

Choose the chip you are going to need, select it on the st site and with tools/software/download you can find everything exept the last sw4stm you get that on the ac6 site (same account as st).
- CubeMX
- STM32F0 or L0 HAL
- SW4STM
and an stlink debugger (added to most dev boards already).
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #74 on: May 19, 2017, 12:48:25 pm »
ok but I am looking at M0 here and I can't even find any ST software on their fucked up pointless website.
Sorry to say but you sound like a young kid that does not get his toy to run after 5 minutes.
If that is the effort you want to invest in this endeavour I would quit now, because there are very heavy storms ahead on the ARM seas (5000+ pages of datasheet/refmanual/prog manual/arm core etc.)

First you have to get an account on the st site before you can download any software.
Then spent a few hours of reading about the topic, watching youtube or the stm forum and you know exactly what you need and if you still don't get it read my above post:

Choose the chip you are going to need, select it on the st site and with tools/software/download you can find everything exept the last sw4stm you get that on the ac6 site (same account as st).
- CubeMX
- STM32F0 or L0 HAL
- SW4STM
and an stlink debugger (added to most dev boards already).


I don't have a problem with taking the time when taking the time is due, but I am on the page about the software and there is no link, yes I have an ST account and was signed in.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: microchip or atmel ARM's
« Reply #75 on: May 19, 2017, 01:21:03 pm »
On the bottom of the page there should always be some matrix with blue download button, i am on an ipad now will check in fifteen minutes for you, could ofcourse be that just for that specific micro something broke.
Do you have a link where you are exactly looking at the site?
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: microchip or atmel ARM's
« Reply #76 on: May 19, 2017, 01:40:00 pm »
So CubeMx enter "CubeMX" in search field and one of the first hits is
https://my.st.com/content/my_st_com/en/products/development-tools/software-development-tools/stm32-software-development-tools/stm32-configurators-and-code-generators/stm32cubemx.html

There you can on the bottom see the blue button get software. Click and download.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: microchip or atmel ARM's
« Reply #77 on: May 19, 2017, 01:47:22 pm »
Next step get the firmware and drivers.
Type in the search field STM32CubeL0 for the L0 series or  STM32CubeF0 wait and the first hit is the homepage of the drivers.
There again on the bottom you can download the driverpackage.

Last step is the SW4STM from AC6 or better the free Keil compiler for the L0/F0
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #78 on: May 19, 2017, 02:42:12 pm »
can't even log into the dumb website, just sits there wirling, will report back later... possibly much later :)
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #79 on: May 19, 2017, 02:45:53 pm »
so what is the difference between L0 and F0 ? I assume they are both based on the M0+ core ?
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: microchip or atmel ARM's
« Reply #80 on: May 19, 2017, 02:52:53 pm »
The L series is low power, think orders like 2-3mA to run the darn thing and 200nA to keep it sleeping.
The counterside is the performance, the L series use lower frequencies thus have less DMIPS.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #81 on: May 19, 2017, 02:57:35 pm »
I see I thought that might be the case. I am doing automotive so don't need to run things off static ;)
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #82 on: May 19, 2017, 04:24:34 pm »
wow, if I read the table right none of the F0 parts have any EEPROM that
 

Offline ez24

  • Super Contributor
  • ***
  • Posts: 3082
  • Country: us
  • L.D.A.
Re: microchip or atmel ARM's
« Reply #83 on: May 19, 2017, 04:32:57 pm »
Watching
YouTube and Website Electronic Resources ------>  https://www.eevblog.com/forum/other-blog-specific/a/msg1341166/#msg1341166
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
 

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: microchip or atmel ARM's
« Reply #85 on: May 19, 2017, 05:27:52 pm »
wow, if I read the table right none of the F0 parts have any EEPROM that

neither do dspic, that doesn't stop me from using them extensively. if i need an eeprom a use an external one. if the processor stopping during internal flash erasing/writing doesn't affect me (or if i'm using mcus with multiple partitions so i can use the inactive as eeprom) i have eeprom emulating routines
 

Online thm_w

  • Super Contributor
  • ***
  • Posts: 6278
  • Country: ca
  • Non-expert
Re: microchip or atmel ARM's
« Reply #86 on: May 19, 2017, 08:54:11 pm »
wow, if I read the table right none of the F0 parts have any EEPROM that

You either use flash to emulate eeprom, or if your design has a RTC then you can use the low power sram or rtc registers (not sure if all chips have this).
Or put an external eeprom.

Its typical of newer micros.
Profile -> Modify profile -> Look and Layout ->  Don't show users' signatures
 
The following users thanked this post: JPortici

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: microchip or atmel ARM's
« Reply #87 on: May 19, 2017, 09:42:51 pm »
If you want to store nv Data once in a while permanently you can use the internal flash but remember erasing erases an entire bank.
If you have to write nv data often use an external fram.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: microchip or atmel ARM's
« Reply #88 on: May 20, 2017, 12:54:01 pm »
wow, if I read the table right none of the F0 parts have any EEPROM that
neither do dspic, that doesn't stop me from using them extensively. if i need an eeprom a use an external one. if the processor stopping during internal flash erasing/writing doesn't affect me (or if i'm using mcus with multiple partitions so i can use the inactive as eeprom) i have eeprom emulating routines
That will wear out the FLASH pretty quick. When I have to resort to solutions like that I make sure there are final checks so the right flash banks are written/erased, have checksums on the content, verify after write (and go to the next sector on fail) and use multiple sectors so if a sector goes bad there are (hopefully) other sectors which still work.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: microchip or atmel ARM's
« Reply #89 on: May 20, 2017, 02:23:28 pm »
wow, if I read the table right none of the F0 parts have any EEPROM that
neither do dspic, that doesn't stop me from using them extensively. if i need an eeprom a use an external one. if the processor stopping during internal flash erasing/writing doesn't affect me (or if i'm using mcus with multiple partitions so i can use the inactive as eeprom) i have eeprom emulating routines
That will wear out the FLASH pretty quick. When I have to resort to solutions like that I make sure there are final checks so the right flash banks are written/erased, have checksums on the content, verify after write (and go to the next sector on fail) and use multiple sectors so if a sector goes bad there are (hopefully) other sectors which still work.
i wrote eeprom emulation, those routines takes care of cells wear-out, just as you said.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #90 on: May 20, 2017, 02:25:27 pm »
It's not something I need right now, it's just odd that something this powerful does not have this despite poxy 8 bit MCU's having it.
 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 2328
  • Country: 00
Re: microchip or atmel ARM's
« Reply #91 on: May 20, 2017, 03:24:00 pm »
 

Offline Vasi

  • Regular Contributor
  • *
  • Posts: 60
  • Country: ro
    • Visual Pin Configurator for Nucleo L152RE - produces SPL code.
Re: microchip or atmel ARM's
« Reply #92 on: May 20, 2017, 04:16:24 pm »
Simon, this may be perfect for you
https://community.st.com/community/stm32-community/blog/2017/02/02/stm32-cores-enabled-in-arduino-ide

Look at one of the supported Nucleo boards. Mine is not supported but I don't need Wiring language, HAL libraries are fat enough.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #93 on: May 20, 2017, 06:04:16 pm »
Simon, this may be perfect for you
https://community.st.com/community/stm32-community/blog/2017/02/02/stm32-cores-enabled-in-arduino-ide

Look at one of the supported Nucleo boards. Mine is not supported but I don't need Wiring language, HAL libraries are fat enough.

Indeed, it sidesteps the difficulty of using teensy for production and allows me to slide over to native ST software for more complicated projects.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #94 on: May 20, 2017, 06:48:44 pm »
Looks like they got cute at arduino and did something more meaningful than the perhaps overpowered Due: https://www.arduino.cc/en/Main/ArduinoBoardZero runs on a D21, I have not looked in detail at the D21 range but it is impressive that ST have CAN on an M0+ core based uC
 

Offline Gibson486

  • Frequent Contributor
  • **
  • Posts: 324
  • Country: us
Re: microchip or atmel ARM's
« Reply #95 on: May 22, 2017, 05:39:41 pm »
FYI...most ARM cortex series do not have EEPROM. At least not that ones I have used.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #96 on: May 22, 2017, 06:32:54 pm »
I see, I suppose because they are more powerful uC's the assumption is that you would use external EEPROM
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: microchip or atmel ARM's
« Reply #97 on: May 22, 2017, 09:13:51 pm »
Perhaps since they have multiple spi and i2c interfaces onboard you can spare one easily and you can pick the size you want, but my guess is that it is also a  process thing.
They rather spent the surface to more RAM and Flash since those need to be on chip to be as fast accessible as possible while eeprom is already slow. One thing I do know, the die is the same in a subfamily if it has 64kB or 320kB RAM, same die they just OTP fuse out access to the extra RAM , ROM.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: microchip or atmel ARM's
« Reply #98 on: May 22, 2017, 10:23:04 pm »
Newer ARM devices from NXP tend to have EEPROM nowadays with pretty good retention time and endurance (100 years and 1million cycles IIRC). One of the advantages of internal EEPROM is that it is slightly harder to hack or do a man in the middle attack.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: microchip or atmel ARM's
« Reply #99 on: May 23, 2017, 02:14:24 am »
Quote
I suppose because they are more powerful uC's the assumption is that you would use external EEPROM
\
I've been suspecting that the semiconductor processes used for ARM chips (finer lithography, etc) just isn't very compatible with creating EEPROM cells.  Yes?  No?
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: microchip or atmel ARM's
« Reply #100 on: May 23, 2017, 07:03:24 am »
Newer ARM devices from NXP tend to have EEPROM nowadays with pretty good retention time and endurance (100 years and 1million cycles IIRC). One of the advantages of internal EEPROM is that it is slightly harder to hack
If you have sensitive info on the external eeprom you just encrypt the data and perhaps sign it if you want to check the integrity. The key you keep internal to the uC or derive it from that key.
That is so common practice nowadays and costs so little cycles that is not a great disadvantage. I do not know how large the internal eeproms are but now you can choose 1MB flash or whatever you want for instance to store firmware updates. Try that with an internal 8kB eeprom  :)   
BOM cost and PCB surface would count more I think.

 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #101 on: May 27, 2017, 01:24:51 pm »
Well I got an ST Nucleo-F091RC board and guess what ? yup, nothing supports it! cube MX only goes "down" to a F1 device board and so does the arduino addon, it's like F0 chips don't exist. So basically the message is that rather than totally waste your time listening to the bullshit people come out with is be prepared to go bare metal! because somehow there is always a catch. I mean this is not hard but it is being made hard and I'm wasting more time trying to do it he easy way than just doing it the hard way! Further the cube mx softwarte does not even display properly on my monitor, another piece of junk ware thrown out there to draw people in.
 

Offline Kalin

  • Regular Contributor
  • *
  • Posts: 101
  • Country: ca
Re: microchip or atmel ARM's
« Reply #102 on: May 27, 2017, 01:45:23 pm »
Well I got an ST Nucleo-F091RC board and guess what ? yup, nothing supports it! cube MX only goes "down" to a F1 device board and so does the arduino addon, it's like F0 chips don't exist. So basically the message is that rather than totally waste your time listening to the bullshit people come out with is be prepared to go bare metal! because somehow there is always a catch. I mean this is not hard but it is being made hard and I'm wasting more time trying to do it he easy way than just doing it the hard way! Further the cube mx softwarte does not even display properly on my monitor, another piece of junk ware thrown out there to draw people in.
You can use the mbed website to program it. Is that an option for your application?

Sent from my SM-G930W8 using Tapatalk

 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #103 on: May 27, 2017, 01:47:35 pm »
an online program, yea that just gives me the shivers. I'm also not sure how/if it helps me setup the chip or am I doing a lot of low level stuff. Just watching Dave video on doing the same thing and he was about as baffled at the time. This is being made unnecessarily hard.
 

Offline Kalin

  • Regular Contributor
  • *
  • Posts: 101
  • Country: ca
Re: microchip or atmel ARM's
« Reply #104 on: May 27, 2017, 02:21:27 pm »
an online program, yea that just gives me the shivers. I'm also not sure how/if it helps me setup the chip or am I doing a lot of low level stuff. Just watching Dave video on doing the same thing and he was about as baffled at the time. This is being made unnecessarily hard.
I have found it very easy to start with and I am not an ee. No low-level stuff and very quick to start. After you compile you program it downloads a bin file that you drag to the boards and that's it.

Sent from my SM-G930W8 using Tapatalk

 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #105 on: May 27, 2017, 02:25:19 pm »
Yea I am just "trying" to download the USB driver, which requires a log in, I am AGAIN waiting a ling time just to log in. ST suck balls big time in terms of anything that is not the chip itself (if I am to believe everything I am being told that I can only verify having jumped through so may hoops I will feel locked in!)

I have written this post in less time than it has taken to log in and fail and now i will have to try again to in to the ShiTware website.
 

Offline Kalin

  • Regular Contributor
  • *
  • Posts: 101
  • Country: ca
Re: microchip or atmel ARM's
« Reply #106 on: May 27, 2017, 03:59:45 pm »
Yea I am just "trying" to download the USB driver, which requires a log in, I am AGAIN waiting a ling time just to log in. ST suck balls big time in terms of anything that is not the chip itself (if I am to believe everything I am being told that I can only verify having jumped through so may hoops I will feel locked in!)

I have written this post in less time than it has taken to log in and fail and now i will have to try again to in to the ShiTware website.
I guess I was able to avoid that headache using Linux. Drivers weren't an issue.  I think your frustrations probably are a result of windows and the related drivers not because of ST.


Sent from my SM-G930W8 using Tapatalk

 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #107 on: May 27, 2017, 04:06:41 pm »
Well having to log in to download a driver is not the fault of windows. Hopefully I only have to restart my machine to make it work as the board still does nothing when plugged in. The board that had zero instructions. Yes arm is hard, but this is making it harder.....

Sent from my Moto G (4) using Tapatalk

 

Offline Kalin

  • Regular Contributor
  • *
  • Posts: 101
  • Country: ca
Re: microchip or atmel ARM's
« Reply #108 on: May 27, 2017, 04:23:42 pm »
Well having to log in to download a driver is not the fault of windows. Hopefully I only have to restart my machine to make it work as the board still does nothing when plugged in. The board that had zero instructions. Yes arm is hard, but this is making it harder.....

Sent from my Moto G (4) using Tapatalk
I didn't? have to install any drivers on Linux. I plugged it in and it showed up immediately as a mass storage device

Sent from my SM-G930W8 using Tapatalk

 

Offline julian1

  • Frequent Contributor
  • **
  • Posts: 721
  • Country: au
Re: microchip or atmel ARM's
« Reply #109 on: May 28, 2017, 12:38:37 am »
On linux getting started with stm32 was as easy as apt-get install the arm compilers, apt-get install openocd for the swd comms, apt-get install gdb, apt-get install gmake etc.

Then git clone the libopencm3 libraries. I was up and running and modifying blinky with an arm discovery board in 20 minutes. Getting a completely undocumented/unblogged about Chinese stm32f4 board from ebay - with remote debugging over stlink and with most of the basic peripherals works, writing my own ring-buffer for uart, dac control etc took a few days.

Likewise, for arduino, I never installed any external party's application/dev tools. Likewise for basic fpga and verilog development on the ice40.

The more languages and software that you need to code for and support - the simpler you want the development toolkit to be, and the smaller the dependency footprint. My first instinct would be to run a mile from any vendor created gui to manage auto-magically handle the configuration and make things 'simple'.

Honestly how does anyone put up with rebooting to install some stupid proprietary comms driver?

Disclaimer - I am not a professional embedded developer.
 

Offline Throy

  • Regular Contributor
  • *
  • Posts: 53
  • Country: de
Re: microchip or atmel ARM's
« Reply #110 on: May 28, 2017, 04:12:43 am »
Well I got an ST Nucleo-F091RC board and guess what ? yup, nothing supports it! cube MX only goes "down" to a F1 device board and so does the arduino addon, it's like F0 chips don't exist. So basically the message is that rather than totally waste your time listening to the bullshit people come out with is be prepared to go bare metal! because somehow there is always a catch. I mean this is not hard but it is being made hard and I'm wasting more time trying to do it he easy way than just doing it the hard way! Further the cube mx softwarte does not even display properly on my monitor, another piece of junk ware thrown out there to draw people in.

After taking about 10 seconds to start a new project and use the board filter built into Cube, I found your ST Nucleo-F091RC that isn't supported...
 
The following users thanked this post: thm_w

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #111 on: May 28, 2017, 07:21:23 am »
ok I have found it also, although an updates was downloaded as well before it let me open it. This software was never made for 4K screens and reading text in it is not easy. In any case it's the same result as reading what chip you have on the board and just choosing it in the chip setup menu instead of board setup menu, using the board selection does not relate functionality to the headers or anything like that if for example you are planing to design a PCB for the nucleo to plug into. The software I doubt was written by ST themselves as there is a select your chip brand option.

I have downloaded SW4STM32 and not got very far with it yet, I'm still trying to find some example code just to see what a project looks like, naturally the one and only document out of several on the page for this nucleo board that is any use does not match reality, Not that I am at all surprised.....
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #112 on: May 28, 2017, 07:25:58 am »
oh of course if I select my nucleo board instead of just the chip it tells me what pin the button and LED's are on, because the non existent documentation for this board does not tell you this sort of stuff....
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #113 on: May 28, 2017, 07:27:39 am »
oh and suddenly SW4STM32 wants to install a ton of "updates" I suspect it's the STM32 specific bits of what is otherwise a generic IDE called eclipse.
 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 2328
  • Country: 00
Re: microchip or atmel ARM's
« Reply #114 on: May 28, 2017, 05:51:04 pm »
Wanna play easy and fast with ST-Nucleo-F091RC

http://developer.mbed.org/platforms/ST-Nucleo-F091RC/

 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: microchip or atmel ARM's
« Reply #115 on: May 28, 2017, 07:52:17 pm »
Simon really  :palm:
St has board schematics bom and even pcb layout for all its boards, no other manufacturer does that.
I am going to stop reading this topic because it looks you are prejudiced to the whole thing and have your mind already made up that it s*cks so everything you do will only confirm this.
Please go use At el or NXP to find out they also suck and dont have a 1,23 ready to go solution for you.

Just want to add one thing if you go baremetal as you call it most programmers only do the sunny day scenario. That works till you meet rain. The ST HAL is bloated I agree but it does handle sunny and rainy day scenarios and all possible rainy day scenarios cost five times more code than the sunny day. So if you want realibility 24/7 operation you better add all recovery options or you have to add the watchdog and accept hard resets on occasions.
 
The following users thanked this post: hans, laneboysrc, newbrain

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #116 on: May 28, 2017, 08:21:09 pm »
Simon really  :palm:
St has board schematics bom and even pcb layout for all its boards, no other manufacturer does that.

I am yet to find a scematic, I have been through all of the PDF's on the Nucleo-F091RC page, none have a schematic and infact none have any information that is very useful. The headline document has one page of specs, half a page of waffle, one and a half pages of lists of other Nucleo boards available and a page of disclaimers, nothing really useful about the board.

Quote
I am going to stop reading this topic because it looks you are prejudiced to the whole thing and have your mind already made up that it s*cks so everything you do will only confirm this.
Please go use At el or NXP to find out they also suck and dont have a 1,23 ready to go solution for you.

Indeed ST does seem to offer the best "entry" solution as badly formed as it is, I am sorry if the cube software is just about legible on my screen. It is indeed a great idea but after that I need to work in an IDE, after creating 2 accounts I have downloaded the "link" driver that has done nothing for me, my nucleo board still sits here unrecognized by the computer. I have down loaded the SW4STM32 or A6 or whatever it is called and will be looking at that when i have more time.

Quote
Just want to add one thing if you go baremetal as you call it most programmers only do the sunny day scenario. That works till you meet rain. The ST HAL is bloated I agree but it does handle sunny and rainy day scenarios and all possible rainy day scenarios cost five times more code than the sunny day. So if you want realibility 24/7 operation you better add all recovery options or you have to add the watchdog and accept hard resets on occasions.

Indeed which is why I have been persevering as i don't really want to learn a 1000+ page document of registers if I can help it and then spend hours writing setup code as I have had to do just for a "simple" AVR.

However, I am encountering the same sorts of problems Dave did and documented in a video about how broken the links are between various aspects. I am not a toolchain expert and thought I was going to start learning to program ARM micros rather than learn how to make different parts of a tool-chain talk to each other. I have read countless pages that just send me to other sites that just send me to other sites. As Dave said there is no option to just download something that works to get you going. Sure the reward might be better than Atmel at the end but it's one hell of a ride until I figure out how to make all of the components of the tool chain work together.

Considering they taunt you with the idea that it is arduino compatible in layout, it is quite deflating to find that this statement is purely for the marketing spin as setting up with ST is more complex than bare metalling another manufacturer never mind with an arduino!
 

Offline mrm2007

  • Contributor
  • Posts: 33
  • Country: 00
Re: microchip or atmel ARM's
« Reply #117 on: May 28, 2017, 08:36:40 pm »
Hi,

This is Nucleo-64 series user manual (Nucleo-F091RC is one of them)-UM1724 :

www.st.com/resource/en/user_manual/dm00105823.pdf

At the end of the document  (Appendix A) you can see  the schematics.

Sent from my E2333 using Tapatalk
« Last Edit: May 28, 2017, 08:39:28 pm by mrm2007 »
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #118 on: May 28, 2017, 08:40:20 pm »
Thank you, that looks like a useful document, looks like they didn't include it on the specific board page as it covers the whole range.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: microchip or atmel ARM's
« Reply #119 on: May 28, 2017, 09:09:30 pm »
Just checked that indeed is an omission of st, normally there are three zip files one with the gerbers one with the bom, both are there for your board and one with the schematic which is missing from your page for your board.

Perhaps I am just lucky getting the chain to work for my two L4 boards in two evenings or the many years experience using toolchains, I don't know.
Fact is if you look at the many topics on the st forum and here on this forum using these chips is pretty serious stuff with a lot of pitfalls and challenges which take many hours to investigate experience to solve. The same for Atmel or NXP or other vendors.
 

Offline hans

  • Super Contributor
  • ***
  • Posts: 1626
  • Country: nl
Re: microchip or atmel ARM's
« Reply #120 on: May 28, 2017, 09:10:45 pm »
Yes, the PDF linked by mrm2007 is on the Nucleo product page.
It's called the user manual , last PDF on product page.

I have to agree with Kjelt. This topic has tendency to turn into "where can I find this pdf, its not on the page, much complicated, so sucks". Try to be more resourceful. We all went through the same hoops, it's not going to change a thing between vendors because it's all the same but with a different flavour of sauce. It's not ideal, but finding a way through the system helps.

And yes Microchip/AVR will have the same thing. If you look at a recent PIC24 or PIC32 datasheet, it wont tell much specific about the peripherals anymore. It is in a separate document. Maybe if you're lucky a brief overview of the registers are in there, but it does not explain in an animated way what each bit does.
Atmel used to publish summary datasheets for their parts. That can be confusing as well.

Overcoming 4K difficulties: maybe try Windows magnifier?
I know it sounds stupid, but in XFCE on Linux it has the magnifier hotkeyed to ALT + Scroll. If my eyes are fatigued, I'm sitting far from my screen (like chair back is all the way down), or just plain lazy, it's so helpful.
And no I don't even have 4K or 1440p that is.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #121 on: May 28, 2017, 09:17:00 pm »
Yes it is a mine field, which is why you want the bits that don't need to be made hard, made hard. my understanding is that I need and IDE to hold it all together, a compiler and something from the chip vendor (header files)to give sensible names to pins and registers rather than address numbers.

I have several choices of IDE non of which are probably setup for any particular vendor as they are generic. I believe they come with compilers so it's just a case of getting them to talk the language of the standard definitions for that chip. Of course if I could get my programmer or whatever they care to call the bit on the board that connectors to the computer that you can snap off to even be recognized that would be a bonus.

MBED is not an attractive option for me, I need something to use professionally, I'd not use MBED any more than I would use circuit maker
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #122 on: May 28, 2017, 09:19:11 pm »
Yes, the PDF linked by mrm2007 is on the Nucleo product page.
It's called the user manual , last PDF on product page.



Well maybe I just dismissed it mistakenly when it looked like just another generic bit of stuff like every other PDF on that page as it starts off looking more like a catalogue than anything else.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #123 on: May 28, 2017, 09:22:07 pm »

Overcoming 4K difficulties: maybe try Windows magnifier?
I know it sounds stupid, but in XFCE on Linux it has the magnifier hotkeyed to ALT + Scroll. If my eyes are fatigued, I'm sitting far from my screen (like chair back is all the way down), or just plain lazy, it's so helpful.
And no I don't even have 4K or 1440p that is.

It's not as simple as that, initially, although it seems to have fixed itself a bit since the update stuff did not fit properly on the side bare as it failed to layout properly. After the update it looks a bit better although the search box is too small. It's not size of text it's actual graphical problems where it can't cope with unexpected resolutions and some bit's adapt whereas others don't.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #124 on: May 30, 2017, 12:43:36 pm »
ahem, just plugged a second nucleo board in and it's all lights a blazing. I'm thinking the first one might be a dud, or something is up with the computer.
 

Online newbrain

  • Super Contributor
  • ***
  • Posts: 1714
  • Country: se
Re: microchip or atmel ARM's
« Reply #125 on: May 30, 2017, 02:42:10 pm »
ahem, just plugged a second nucleo board in and it's all lights a blazing. I'm thinking the first one might be a dud, or something is up with the computer.
Reading through the whole thread I'm quite puzzled by the amount of problems you found.
I've been using Nucleos and Discos for some time, 99% in Windows (and 1440p) and with System Workbench and VisualGDB without running into any real issue.

For this last thing, it's very strange that you have a dead board: I've managed to half-kill one, but that took some effort in sloppiness and >20V.

Did you check that all the jumpers are in the correct position?
All the following must be in place:
  • Two on CN2 on the ST-link side of the board to connect the target to the programmer/debugger
  • The jumper on JP5 must be on U5V side, if you power the board through USB
  • The IDD jumper (JP6) must be in place

If enumeration is a problem (underpowered Hub, maybe?) you can try putting a jumper on JP1 too (not in general advisable).

The board should appear as several USB devices, namely (going form memory):
  • The ST-link debugger
  • A mass storage device (handy for programming: just drop the .bin in the disk!)
  • A serial port COMx


Nandemo wa shiranai wa yo, shitteru koto dake.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #126 on: May 30, 2017, 04:57:10 pm »
It turns out to be a duff cable, plugged the "dead" one into the laptop with the cable i used before and still nothing, changed the cable and voila!

As to the other problems it's basically as Dave said in his video where he went through a similar exercise. There is nothing to download and just get going with, you have to be quite knowledgeable about the tool-chain as well.

Unfortunately there are several things i need to learn at the moment apart from spending most of my time in a full time job: a HNC course in electrical engineering, packed with maths I am unlikely to ever use and struggling badly to understand, Circuit studio having wasted time with another software, and attempting to enter into the ARM world. So yes it is frustrating when I also have to become a tool-chain expert. ST do not provide a ready to go tool-chain like for example Atmel have or Microchip do. Once again today when I repeated the whole process of setting up for the Nucleo on my laptop it took several minute just to log into the ST website, and I do literally mean some minutes, this is a constant experience and not very inspiring.

Although not diagnosed it is extremely likely that I have attention deficit that just makes all of the above feel like it is 3 times harder than it should be and probably is 3 times harder for me than it is for most people. This was part of my reason for looking at ARM, in the hope that things like STCubeMX or whatever it is called help take care of stuff that I don't have to get too down and dirty with so that I can spend 3 times the time it may take others to develop my application. typically my application amounts to less than 10 lines, it's all the register setting up that takes a long, long time and I am trying to avoid a bit.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: microchip or atmel ARM's
« Reply #127 on: May 30, 2017, 06:04:03 pm »
yes I looked at ST, looked like real hard work to work out how to fire up the software and get anything done.

Did you expect it to be easy?

I expect them to talk in easy to understand language for the new comer, we all have to start somewhere. I already have new chips to learn, the software need not be made unnecessarily hard.

Everybody is going to jump in with the favorite board so I'll do the same.  Have you considered the LPC1768 version of the 'mbed'?  Not only is the toolchain free, it is reachable via your favorite browser, you don't need to install or configure anything.  Thus you are always using the latest version...  And don't overlook how cool it is to be system independent.  You can reach your code from any browser, anywhere in the world.

In my opinion, you start out closer to the chip with the mbed approach.  You don't get all wrapped up in a HAL that just increases the slope of the learning curve.

I like the 'stamp' format because I can plug it into a prototype board.  I can also build permanent projects on a motherboard and plug in the CPU.

https://developer.mbed.org/platforms/mbed-LPC1768/

Since the PHY is on the underside of the board, adding Ethernet is as simple as wiring up a MagJack.  There is a full TCP/IP stack if that is required.

The MBED libraries provide a lot of code if you want to use them but there is no real requirement to do so.  You can easily get right down to the peripheral registers and work right at the bottom layer of code.

My very first real project required interrupt driven SPI reception at about 10 MHz clock rate.  It was amazingly easy to do.

If you toss out the copyright and the unused #defiines, it took about 50 lines of code to initialize the SPI device and hook it up to the NVIC.  As bytes are received, the device raises an interrupt and the interrupt code (spi_slave_handler) grabs the value before calling enqueue to place it in a circular buffer.

Code: [Select]
/*
Copyright (c) 2012 Richard T Stofer

Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:

The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*/

#include "LPC17xx.h"
#include "spi_slave.h"
#include "queue.h"
#include "cmsis_nvic.h"

// P0.15 SCK    MBED p13
// P0.16 SSEL   MBED p14
// P0.17 MISO   MBED p12
// P0.18 MOSI   MBED p11

// bit positions within the various registers
#define PCSPI       ( 8)    // power control bit
#define PCLK_SPI    (16)    // clock select bits 17..16
#define BIT_ENABLE  ( 2)    // enable width other than 8 bits
#define CPHA        ( 3)    // clock phase control
#define CPOL        ( 4)    // clock polarity
#define MSTR        ( 5)    // enable master mode
#define LSBF        ( 6)    // LSB first
#define SPIE        ( 7)    // enable SPI interrupt
#define BITS        ( 8)    // set transfer width (not used)
#define SPIF        ( 0)    // SPI interrupt flag bit

#define stABRT      ( 3)    // status bits
#define stMODF      ( 4)
#define stROVR      ( 5)
#define stWCOL      ( 6)
#define stSPIF      ( 7)
#define stERROR     ((1 << stABRT) | (1 << stMODF) | (1 << stROVR) | (1 << stWCOL))

spiStatsStruct spiStats;

spiStatsStruct * spiGetStruct(void) {
    return &spiStats;
}

void spi_slave_handler(void) {
    unsigned char status;
    unsigned char value;
   
    status = LPC_SPI->SPSR;         // get status register
    if ( (status & stERROR) != 0) {
       
        spiStats.totalErrors++;
        if (status & (1 << stABRT))
            spiStats.errABRT++;
        if (status & (1 << stMODF))
            spiStats.errMODF++;
        if (status & (1 << stROVR))
            spiStats.errROVR++;
        if (status & (1 << stWCOL))
            spiStats.errWCOL++;
    }
    value  = LPC_SPI->SPDR;         // get the data byte
    spiStats.bytesReceived++;
    enqueue(value);
    LPC_SPI->SPINT = (1 << SPIF);   // clear interrupt flag
}

void spi_slave_init(void) {
    volatile int junk;

    LPC_SC->PCONP           |=  (1 << PCSPI);    // pedantic, should already be powered up
    LPC_SC->PCLKSEL0        &= ~(3 << PCLK_SPI); // reset clock select bits for PCLK_SPI
    LPC_SC->PCLKSEL0        |=  (1 << PCLK_SPI); // set SPI clock to CCLK
    LPC_PINCON->PINSEL0     |= 0xC0000000;       // set up SCK in PINSEL0
    LPC_PINCON->PINSEL1     |=  (3 << 0);        // set up SSEL in PINSEL1
    LPC_PINCON->PINSEL1     |=  (3 << 2);        // set up MISO in PINSEL1
    LPC_PINCON->PINSEL1     |=  (3 << 4);        // set up MOSI in PINSEL1
    LPC_SPI->SPCR            = (1 << SPIE);      // set up control register
    junk                     = LPC_SPI->SPSR;    // clear status register
    junk                     = LPC_SPI->SPDR;    // clear data register
    LPC_SPI->SPDR            = 0x00;             // initial return value
    LPC_SPI->SPINT           = (1 << SPIF);      // clear interrupt flag
                           
    NVIC_SetVector(SPI_IRQn, (uint32_t) &spi_slave_handler);
    NVIC_SetPriority(SPI_IRQn, 1);
    NVIC_EnableIRQ(SPI_IRQn);
}

Pretty easy.

« Last Edit: May 30, 2017, 06:08:28 pm by rstofer »
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: microchip or atmel ARM's
« Reply #128 on: May 30, 2017, 06:23:21 pm »
Although not diagnosed it is extremely likely that I have attention deficit that just makes all of the above feel like it is 3 times harder than it should be and probably is 3 times harder for me than it is for most people. This was part of my reason for looking at ARM, in the hope that things like STCubeMX or whatever it is called help take care of stuff that I don't have to get too down and dirty with so that I can spend 3 times the time it may take others to develop my application. typically my application amounts to less than 10 lines, it's all the register setting up that takes a long, long time and I am trying to avoid a bit.

I don't think ADHD is all that rare among engineers.  Other social ineptitudes also accompany the major.

I have been playing with ST boards using STCubeMX and I really don't enjoy the experience.  Instead of just stuffing values in registers and watching the pretty LEDs blink, I have to try to decipher somebody else's code.  I really think the HAL obscures more than it illuminates.  Give me a datasheet and I'll write my own drivers, thank you very much!  Oh, and copying is allowed.

Allowing STCubeMx to create a basic framework may be a good path for others.  I haven't gotten to the point where I enjoy it.  Obviously, opinions vary...

I started my ARM adventures with a couple of simple but very complete chips, the NXP LPC2106 and the LPC2148.  These are a small subset of the more modern chips but they were pretty easy to understand and provided decent performance.  The LPC2148 has a full USB peripheral so things like VCOM and mass storage were easy to implement by grabbing NXPs sample code.

If you think you might be interested in an older chip, just to get started, consider the LPC2148 and the magnificent code at http://www.jcwren.com/arm/  This is really nice code!

This is the board I used.  I see it is terribly overpriced based on costs today:

https://www.olimex.com/Products/ARM/NXP/LPC-P2148/

All in, I prefer the LPC1768 mbed.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #129 on: May 30, 2017, 07:18:52 pm »
The STM32F091RCT featured on the Nucleo-F091RC is pretty much what I need. It's not too expensive, supports USB, nice fast ADC, and has a CAN channel I'd like to use one day.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: microchip or atmel ARM's
« Reply #130 on: May 30, 2017, 09:33:11 pm »
Quote
lpc2148
I would not recommend it for new designs or for starters, that chip is the past and probably also almost obsolete.
For Arm the Cortex M0,3,4,7 is the present.
Sorry probably my allergy from college where we always got outdated stuff because the teacher knew that stuff and was too lazy to update/upgrade his knowledge and tools, books.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: microchip or atmel ARM's
« Reply #131 on: May 30, 2017, 09:56:48 pm »
Quote
lpc2148
I would not recommend it for new designs or for starters, that chip is the past and probably also almost obsolete.
For Arm the Cortex M0,3,4,7 is the present.
When it comes to NXP it doesn't really matter since the peripherals you'll find in the LPC2148 are also used in their newer chips so many things you'll learn and code you write can be re-used across NXP's entire ARM controller portfolio. IMHO that is a strong point compared to ST's offerings which are not consistent at all.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: microchip or atmel ARM's
« Reply #132 on: May 30, 2017, 10:02:24 pm »
I am not saying it should be ST but then get a modern NXP Cortex M0,3,4 chip.
Some of the even older arm7tdi chips are becoming unobtanium, for new designs a no go.
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: microchip or atmel ARM's
« Reply #133 on: May 31, 2017, 06:22:34 am »
Some of the even older arm7tdi chips are becoming unobtanium
LPC2103? I still have, like, 10 of them. The support circuitry is a bit crazy for me to set up on breadboards so I don't use it that often.
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: microchip or atmel ARM's
« Reply #134 on: May 31, 2017, 07:04:51 am »
For me personally I don't like any vendor toolset for ARM. I have been using vanilla Eclipse CDT + GNU ARM Embedded + J-Link or CMSIS-DAP for my projects.

Does anyone know how to get AMD R9 380 working under macOS Sierra? Ubuntu 17.04 is great but macOS works better. (And no please PLEASE do not suggest Windows to me - it does not work for my purposes.
 

Online newbrain

  • Super Contributor
  • ***
  • Posts: 1714
  • Country: se
Re: microchip or atmel ARM's
« Reply #135 on: May 31, 2017, 07:19:35 am »
The STM32F091RCT featured on the Nucleo-F091RC is pretty much what I need. It's not too expensive, supports USB, nice fast ADC, and has a CAN channel I'd like to use one day.

If you intend to continue with ST, there is a number of online courses that explain the use of CubeMX and the HAL, e.g.:

If you don't like System Workbench (I'm not fond of Eclipse based tools either), specifically for ST F0 and L0 MCUs, the Keil development environment is free without code size limitation.
CubeMX can directly generate Keil MDK projects.
I happen to like Visual Studio Community (free as in beer) + VisualGDB (not free, but not expensive): it just works for me, VS is an excellent development environment and VGBD also supports a number of other vendors' MCUs (ST is one of the better supported). Plenty of tutorials, including importing CubeMX generated projects.

In the Cube, in addition to the HAL, CMSIS and other drivers/middlewares, there are tons of example code for the Nucleo, Disco and Eval boards, providing a good insight on HAL use.

On a completely different note, danadak, ebclr and dgtl have suggested Cypress PSoC, which is a really interesting alternative.
Cheap boards, decent IDE (but one is 100% bound to it for the HW definition part) and great fun.
The peripheral library API is simple and clear, and one can design their own specialized HW: e.g. I recently used it for a reciprocal frequency meter (a couple of evenings), and to make a test harness for a simple ATtiny based project (a couple of hours).

All of the above IMHO, YMMV etc. etc.: this is an hobby for me, though I work with SW.
Nandemo wa shiranai wa yo, shitteru koto dake.
 
The following users thanked this post: thm_w

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #136 on: May 31, 2017, 11:52:16 am »
The cypress website actually seems quite good, no need to log in and wait over a minute for it to log in and download the IDE, I'm yet to grab a part number and find out how much it is and how available. As they do a seperate range on auto ARM chips that don't seem cheap I'm wondering if the cheaper ones will feature CAN.
 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 2328
  • Country: 00
Re: microchip or atmel ARM's
« Reply #137 on: May 31, 2017, 04:54:39 pm »
I assure you, as soon you have proficiency on Psoc you will forget everything else, that family and concept are unique and amazing

Regarding Can

http://www.cypress.com/documentation/application-notes/an52701-psoc-3-and-psoc-5lp-getting-started-controller-area-network
 

Offline Gibson486

  • Frequent Contributor
  • **
  • Posts: 324
  • Country: us
Re: microchip or atmel ARM's
« Reply #138 on: June 01, 2017, 12:07:12 pm »
Just pick one and go. No matter which platform you choose, you are going to hit a roadblock somewhere. It is part of the learning process.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #139 on: June 01, 2017, 02:00:41 pm »
true but I often deal in low volumes so I would rather be in a position of having an easy initialisation process even if the chip cost more rather than send weeks on programming as in low volume it's cheaper in the long run. The Cypress setup does indeed look interesting.
 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 2328
  • Country: 00
Re: microchip or atmel ARM's
« Reply #140 on: June 01, 2017, 03:25:11 pm »
That's is a perfect scenario for a cypress stick,
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: microchip or atmel ARM's
« Reply #141 on: June 01, 2017, 05:07:52 pm »
Well I would ultimately like to be using CAN as well so depends on what is available, the €4 sticks do indeed look very attractive
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf