I am writing my program with the ASF in Studio 6.1 on a SAMD20J18 MCU.
I found that the possible pin multiplexing options in the ASF usart library do not have the TX pin on PAD1 options. Is this a limitiation on the MCU or only the usart.h library is not complete?
Also, how about the RTS and CTS pins? The usart library seems do not care about these two pins. So do I have to control the RTS and CTS as a GPIO pin my own?
Thanks a lot!
Note that the SAMD20 is not an AVR32 - it is an ARM Cortex-M0+
Is this a limitiation on the MCU
OMG, I have checked the datasheet and even the USART application note, but they did not mention the TX pin should not be PAD1. After reading these documents, I even have the perception that I can assign the 4 PADs to any combination. However when I read to the detail of the register map, I realized that the register for assigning the TX pad has only 1 bit! It only allow to assign the TX to PAD0 or PAD2! How come it did not mention this important information at the description of the USART chapter!
Time to market is very important, it is usually not possible for engineer to read through all the *detail* of a 650 pages datasheet before starting the design. Therefore the datasheet should be clear. I have made the PCB layout and waiting to receive my 2nd EVT samples....that means I have to cut the trace of the PCB....:(
it is usually not possible for engineer to read through all the *detail* of a 650 pages datasheet before starting the design
Try a SAMD21J18 instead. It's pin compatible with more features, which includes a SERCOM fix to allow for better MUXing of USART pins on the four pads.
Best part? It's cheaper.
- Dean :twisted:
(The D21 series is essentially a new revision of the D20, but with the modules that weren't specc'd in time and with enhancements due to whinging from the Apps guys and FAEs)
Then you rather get what you deserve. Reading and background research are probably 20-25% of a project. It's probably more costly to skip it than to take the time.
I've not tried the UART, but I did have to spend some considerable time checking that I had a usable configuration of the SPI pins.
There's a well-known graph that shows how the cost of fixing erros/mistakes/bugs escalates the later they are addressed in the project...
... enhancements due to whinging from the Apps guys and FAEs)
https://www.avrfreaks.net/index.p...
:shock:
You mean somebody actually asked for that stupid hardware SS operation on the SPI Question Question
The part when you need to actually schedule multiple bytes via spi_write_buffer_job(), spi_read_buffer_job() or spi_transceive_buffer_job() instead of using the byte-wise APIs?
(This is from memory - if the select pin toggles between each byte in a job transfer I agree there's a HW/SW bug somewhere)
- Dean :twisted:
the select pin toggles between each byte in a job transfer
:x
It is particularly galling for the R21 as this operation makes it entirely unusable with the "integrated" (sic) RF233 :!:
:roll:
What were they thinking??!!
I agree there's a HW/SW bug somewhere)
Quote:Then you rather get what you deserve. Reading and background research are probably 20-25% of a project. It's probably more costly to skip it than to take the time.it is usually not possible for engineer to read through all the *detail* of a 650 pages datasheet before starting the design
The sad part is I am not the boss ...The boss and customer assign the project to me and request to deliver it in a short time, then I have to do it. There is lots of thing to research in this project. I have worked from 8:00am to 2:00am everyday. If it has problem, then of course it is my problem rather than the problem of my boss or the customer ....:cry:
However, I think to provide more user friendly environment for the customer is one of the goal for Atmel. Is it really not reasonable to mention this information in the description part of the peripheral?
The boss and customer assign the project to me and request to deliver it in a short time ... There is lots of thing to research in this project.
Is it really not reasonable to mention this information in the description part of the peripheral?
Having said that, I have found the SAM D20/D21/R21 and associated tools to be particularly full of "gotchas" and traps for the unwary.
It's not helped, of course, by them being very new; eg, the ridiculously long delay in publishing the R21 datasheet! :shock:
But such is life at the bleeding edge...
In this case specifically, it would be helpful if they just told you exactly where to go to find what MUX options are possible.
Unfortunately @garypty didn't know about the decoder ring required to find what pin a signal is on with an Atmel part. I just spent 30 minutes going over a 703 page PDF and I can't tell you where the TX/RX pins are. This is THE main reason I switched to Freescale/SMT products: With Freescale's Processor Expert I can tell which pins do what and generate the initialization code in 10 minutes. With SMT's Qube I can do the same. Microchip was working on some software and after waiting two years I sold all my programming/debugging hardware and left and haven't regretted 10 years of loyalty flushed.
I did some searches on the 703 page document looking for issues and there are many, it makes me take a new option back to the money people:
A standalone MCU and standalone 9DOF since the MCU can be had for under $0.50 that does what the SAM D20 does while the 9DOF device can be had for half the price without the SAM D20 reducing the cost of the hardware by ~10 times.
I still can't believe there is no mention of UART RX TX in a 703 page PDF. SERCOMx PADx and decoder rings
atmel-42129-sam-d20_datasheet.pdf
I still can't believe there is no mention of UART RX TX in a 703 page PDF. SERCOMx PADx and decoder rings
Seriously?
Took me 3 minutes:
CTRL-F is your friend.
Maybe time for glasses? ;-)
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
 |
Oh, and:
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
I'm not to embarrassed : I removed Adobe Reader since Google can read PDF files BUT I was having trouble selecting text inside the PDF files so I installed an extension, that extension didn't use the Ctr+F but it's own Search which when used found everything.
I think they did good by allowing each engine to be configured to what is needed, I just hope it works.
I found what was needed for the BMF055 but I'm concerned that no one is dealing with the MCU in the BMF055 as BOSH points to Atmel and Atmel has no 28 pin SAM D20.
This is not AVR related, I'll try to move it to the right place.
What does AVR mean? I found this post about a USART/COM problem on a SAM D20 by searching in the below forum, where does AVR come into play?
Thanks
What does AVR mean?
Usually 8 bit AVR chips but some UC3 stuff also. So 3 and 5 above would be appropriate forums for ARM related stuff. I guess the OP was posted in an 8 bit forum??
This post is here: Home » Communities » Atmel SMART ARM-based MCUs » Forums » Tools » Atmel Studio (ARM-related) » UART Pin Multiplexing on SAM-D20 MCU
Where the AVR forums seem to exist
Home » Communities » AVR Freaks
With crossovers in tools and touch since 8 to 64 bit processors use both.
I'm still working on my ATA6614Q project, it came back to life after CHIP/Pine64/PI Zero happened.
Have a good New Year~!
I'm sorry can you sort your source on this TX problem. I'm not finding it
Never mind. Great first post, eh?
