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

0 Members and 1 Guest are viewing this topic.

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17731
  • 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.....
 

Offline thm_w

  • Super Contributor
  • ***
  • Posts: 6285
  • 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: 1628
  • 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: 4197
  • 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: 17731
  • 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: 17731
  • 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 :(
 

Online 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: 17731
  • 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: 17731
  • 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: 26794
  • 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: 17731
  • 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: 26794
  • 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: 17731
  • 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: 4197
  • 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

Online 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: 17731
  • 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: 17731
  • 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: 26794
  • 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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf