Reply by Chris Hills August 14, 20062006-08-14
In article <1155492868.615530.152340@p79g2000cwp.googlegroups.com>,
rickman <spamgoeshere4@yahoo.com> writes
>I would like to ask if you tried to contact Atmel about this? I have >had a couple of detailed questions about some of the peripherals and >have not been getting good responses from Atmel support. One problem >with my latest inquiry is that the person who knew the answer (I guess >there was only one person in the whole company) was on vacation. Being >in France they have a different culture from the US in regards to >vacations. My understanding is that most of Europe gets some 4 or more >weeks of vacation a year and not after working at a company for 20 >years!
This is correct. It is usual to have 4/5 weeks vacation + national holidays as soon as you start. It can progress up to 6+ weeks over the years. The Swedes tend to shut down for about 6 weeks in the summer anyway. But then they do have a couple of months of near total darkness. The Parisians always close down for 2 weeks in August (some say it's the heat others that it is too many tourists :-). Interestingly the Europeans are about as productive as the US (some a bit more some a bit less) so personally I prefer the system with the longer holidays. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by martin griffith August 14, 20062006-08-14
On Sun, 13 Aug 2006 22:35:53 +0200, in comp.arch.embedded "Ulf
Samuelsson" <ulf@a-t-m-e-l.com> wrote:

> >> I would like to ask if you tried to contact Atmel about this? I have >> had a couple of detailed questions about some of the peripherals and >> have not been getting good responses from Atmel support. One problem >> with my latest inquiry is that the person who knew the answer (I guess >> there was only one person in the whole company) was on vacation. > >August is not a good month to ask questions to Central Europeans... > >> Being in France they have a different culture from the US in regards to >> vacations. My understanding is that most of Europe gets some 4 or more >> weeks of vacation a year and not after working at a company for 20 >> years! >> > >An on top of that maternity/paternity leave. Here you get 9 months per child >which can be taken out by mom or dad, or shared between the two during a >period of 10 years. > >My previous colleague had 5 kids, and his wife was taking care of kids >in their home, so she only took two weeks out of the 9 months leaving >him with 5 * 8,5 months paternity leave on top of his six weeks holiday. >That is an average of three months+ free time per year. > >Read and weep guys!
and The eurozone economy grew at its fastest rate for six years in the three months to June and even outpaced the US.(ft.com) Even the french economy grew, so it can't be that bad can it! martin
Reply by Ulf Samuelsson August 13, 20062006-08-13
> I would like to ask if you tried to contact Atmel about this? I have > had a couple of detailed questions about some of the peripherals and > have not been getting good responses from Atmel support. One problem > with my latest inquiry is that the person who knew the answer (I guess > there was only one person in the whole company) was on vacation.
August is not a good month to ask questions to Central Europeans...
> Being in France they have a different culture from the US in regards to > vacations. My understanding is that most of Europe gets some 4 or more > weeks of vacation a year and not after working at a company for 20 > years! >
An on top of that maternity/paternity leave. Here you get 9 months per child which can be taken out by mom or dad, or shared between the two during a period of 10 years. My previous colleague had 5 kids, and his wife was taking care of kids in their home, so she only took two weeks out of the 9 months leaving him with 5 * 8,5 months paternity leave on top of his six weeks holiday. That is an average of three months+ free time per year. Read and weep guys! -- Best Regards, Ulf Samuelsson This is intended to be my personal opinion which may, or may not be shared by my employer Atmel Nordic AB
Reply by rickman August 13, 20062006-08-13
Stef wrote:
> In comp.arch.embedded, > Meindert Sprang <ms@NOJUNKcustomORSPAMware.nl> wrote: > > "Meindert Sprang" <ms@NOJUNKcustomORSPAMware.nl> wrote in message > > news:12dobl7c2uk4j91@corp.supernews.com... > >> "Stef" <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote in message > >> news:22591$44daefe4$54f63171$27560@publishnet.news-service.com... > >> > Anyone used the manchester encoder/decoder on the Atmel AT91SAM7S? > >> > I am currently trying to get it to work on the SAM7S-EK (SAM7S256). > >> > > >> > When I enable the manchester, I see my transmitted data getting coded > >> > and there is a pre-amble (For each character! who made that up?). > >> > Also when I enable the manchester, the idle-state of the TXD line > >> > goes to 0 (1 when no manchester) and there are a lot of glitches on it > >> > of about 25ns long. > >> > > >> > I have my TXD looped back to the RXD and my code sends 'messages' of > >> > 8 bytes long which get handled in an interrupt routine that is called > >> > whith the uart timeout interrupt. > >> > >> Isn't that the cause of your problem. I am not familiar with this UART but > > I > >> remember from my Z80SIO in HDLC days that when the TX Empty interrupt was > >> not serviced (new byte delivered) the CRC generation was triggered and > > flags > >> were transmitted. > >> > >> So in your case, using the timeout interrupt of the transmitter could be > > the > >> triggering the preamble when the next byte is loaded into the UART. My > > guess > >> is that you should use the Transmitter Empty (or whatever name is used) to > >> load a new character in the UART. > > > > Mmm.... apparently, the preamble is generated for every character (it says > > so on page 305 of the datasheet), which means that you enable the preamble > > for the first character in your frame and you disable it (set the length to > > 0) before you load the following characters into the TX register. > > > I'm using the receiver timeout interrupt to signal received messages. This > one is triggered when there is no character received for N bit times > (I used N=20). > > Changing the pre-amble length to zero after the first character is sent > means I would need te put the first char seperately in the THR and can > not use the fire-and-forget PDC option. I now send messages by setting > the PDC's transmit pointer and counter regs, the rest is automatic. > I am also not sure how the machester wil respond to changing the pre-amble > length when it is transmitting (The tx-empty interrupt comes as soon as > the char is transferred to the shift register). > > But all that is problems for later. The more urgent problem (to me) is > that the UART does not even regognize it's own transmission when RXD is > loopped back to TXD and that there are glitches on the TXD signal. > > I'm already working on another solution. I now encode the data myself in > such a way that the sequence of startbit, data and stopbits already has > zero DC offset, so I don't need the manchester for that anymore. The > message is started with a series of sync chars that do not have valid > data coding (sort of a pre-amble). That way I don't have to mess with > the manchester encoder and the glitches are gone.
I would like to ask if you tried to contact Atmel about this? I have had a couple of detailed questions about some of the peripherals and have not been getting good responses from Atmel support. One problem with my latest inquiry is that the person who knew the answer (I guess there was only one person in the whole company) was on vacation. Being in France they have a different culture from the US in regards to vacations. My understanding is that most of Europe gets some 4 or more weeks of vacation a year and not after working at a company for 20 years! If your complaints about the transmitter sending those brief pulses are accurate, I would think this would be in the errata. I don't know that 25 ns pulses would be a problem for the UART when receiving, but they could easily be a problem for anything else in the path between and could easily be stretched and become a problem for the receiver. This is not in the errata.
Reply by Stef August 11, 20062006-08-11
In comp.arch.embedded,
Meindert Sprang <ms@NOJUNKcustomORSPAMware.nl> wrote:
> "Meindert Sprang" <ms@NOJUNKcustomORSPAMware.nl> wrote in message > news:12dobl7c2uk4j91@corp.supernews.com... >> "Stef" <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote in message >> news:22591$44daefe4$54f63171$27560@publishnet.news-service.com... >> > Anyone used the manchester encoder/decoder on the Atmel AT91SAM7S? >> > I am currently trying to get it to work on the SAM7S-EK (SAM7S256). >> > >> > When I enable the manchester, I see my transmitted data getting coded >> > and there is a pre-amble (For each character! who made that up?). >> > Also when I enable the manchester, the idle-state of the TXD line >> > goes to 0 (1 when no manchester) and there are a lot of glitches on it >> > of about 25ns long. >> > >> > I have my TXD looped back to the RXD and my code sends 'messages' of >> > 8 bytes long which get handled in an interrupt routine that is called >> > whith the uart timeout interrupt. >> >> Isn't that the cause of your problem. I am not familiar with this UART but > I >> remember from my Z80SIO in HDLC days that when the TX Empty interrupt was >> not serviced (new byte delivered) the CRC generation was triggered and > flags >> were transmitted. >> >> So in your case, using the timeout interrupt of the transmitter could be > the >> triggering the preamble when the next byte is loaded into the UART. My > guess >> is that you should use the Transmitter Empty (or whatever name is used) to >> load a new character in the UART. > > Mmm.... apparently, the preamble is generated for every character (it says > so on page 305 of the datasheet), which means that you enable the preamble > for the first character in your frame and you disable it (set the length to > 0) before you load the following characters into the TX register. >
I'm using the receiver timeout interrupt to signal received messages. This one is triggered when there is no character received for N bit times (I used N=20). Changing the pre-amble length to zero after the first character is sent means I would need te put the first char seperately in the THR and can not use the fire-and-forget PDC option. I now send messages by setting the PDC's transmit pointer and counter regs, the rest is automatic. I am also not sure how the machester wil respond to changing the pre-amble length when it is transmitting (The tx-empty interrupt comes as soon as the char is transferred to the shift register). But all that is problems for later. The more urgent problem (to me) is that the UART does not even regognize it's own transmission when RXD is loopped back to TXD and that there are glitches on the TXD signal. I'm already working on another solution. I now encode the data myself in such a way that the sequence of startbit, data and stopbits already has zero DC offset, so I don't need the manchester for that anymore. The message is started with a series of sync chars that do not have valid data coding (sort of a pre-amble). That way I don't have to mess with the manchester encoder and the glitches are gone. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)
Reply by Meindert Sprang August 11, 20062006-08-11
"Meindert Sprang" <ms@NOJUNKcustomORSPAMware.nl> wrote in message
news:12dobl7c2uk4j91@corp.supernews.com...
> "Stef" <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote in message > news:22591$44daefe4$54f63171$27560@publishnet.news-service.com... > > Anyone used the manchester encoder/decoder on the Atmel AT91SAM7S? > > I am currently trying to get it to work on the SAM7S-EK (SAM7S256). > > > > When I enable the manchester, I see my transmitted data getting coded > > and there is a pre-amble (For each character! who made that up?). > > Also when I enable the manchester, the idle-state of the TXD line > > goes to 0 (1 when no manchester) and there are a lot of glitches on it > > of about 25ns long. > > > > I have my TXD looped back to the RXD and my code sends 'messages' of > > 8 bytes long which get handled in an interrupt routine that is called > > whith the uart timeout interrupt. > > Isn't that the cause of your problem. I am not familiar with this UART but
I
> remember from my Z80SIO in HDLC days that when the TX Empty interrupt was > not serviced (new byte delivered) the CRC generation was triggered and
flags
> were transmitted. > > So in your case, using the timeout interrupt of the transmitter could be
the
> triggering the preamble when the next byte is loaded into the UART. My
guess
> is that you should use the Transmitter Empty (or whatever name is used) to > load a new character in the UART.
Mmm.... apparently, the preamble is generated for every character (it says so on page 305 of the datasheet), which means that you enable the preamble for the first character in your frame and you disable it (set the length to 0) before you load the following characters into the TX register. Meindert
Reply by Meindert Sprang August 11, 20062006-08-11
"Stef" <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote in message
news:22591$44daefe4$54f63171$27560@publishnet.news-service.com...
> Anyone used the manchester encoder/decoder on the Atmel AT91SAM7S? > I am currently trying to get it to work on the SAM7S-EK (SAM7S256). > > When I enable the manchester, I see my transmitted data getting coded > and there is a pre-amble (For each character! who made that up?). > Also when I enable the manchester, the idle-state of the TXD line > goes to 0 (1 when no manchester) and there are a lot of glitches on it > of about 25ns long. > > I have my TXD looped back to the RXD and my code sends 'messages' of > 8 bytes long which get handled in an interrupt routine that is called > whith the uart timeout interrupt.
Isn't that the cause of your problem. I am not familiar with this UART but I remember from my Z80SIO in HDLC days that when the TX Empty interrupt was not serviced (new byte delivered) the CRC generation was triggered and flags were transmitted. So in your case, using the timeout interrupt of the transmitter could be the triggering the preamble when the next byte is loaded into the UART. My guess is that you should use the Transmitter Empty (or whatever name is used) to load a new character in the UART. Meindert
Reply by Stef August 10, 20062006-08-10
In comp.arch.embedded,
Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:
> Anyone used the manchester encoder/decoder on the Atmel AT91SAM7S? > I am currently trying to get it to work on the SAM7S-EK (SAM7S256). >
An internet search turned up nothing usefull and on the at91.com I only found this message on the sam7 forum: http://www.at91.com/www/phpBB2_mirror/viewtopic.php4?t=1480 Seems he got it to work a little more than I, but not completely. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)
Reply by Stef August 10, 20062006-08-10
Anyone used the manchester encoder/decoder on the Atmel AT91SAM7S?
I am currently trying to get it to work on the SAM7S-EK (SAM7S256).

When I enable the manchester, I see my transmitted data getting coded
and there is a pre-amble (For each character! who made that up?).
Also when I enable the manchester, the idle-state of the TXD line
goes to 0 (1 when no manchester) and there are a lot of glitches on it
of about 25ns long.

I have my TXD looped back to the RXD and my code sends 'messages' of
8 bytes long which get handled in an interrupt routine that is called
whith the uart timeout interrupt. This works perfectly when the
mnachester is disabled. With manchester enabled, not a single char gets
through. I have set my TX pre-amble to 15 en RX pre-amble to 4, but
have also tried with setting them both to 15. Pre-amble is set to
all-one on both sides and the start delimiter is set to one-bit.

Any suggestions on what to try? Anyone else see the glitches on the TXD
with manchester enabled?


-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)