baseig -> Jeg skal til at finde ud af hvordan man programmerer en Atmel AVR MCU fra vb/windows, hvis du kender du noget til elektronik ??, så har jeg et diagram af det dongle/programmer som skal sidde mellem comporten og MCU´en. Jeg ved at TX, skal bruges til at trække reset høj på MCU´en, og at DTR skal sende data, og DSR/RTS er sat sammen og skal modtage data.
Det er det jeg har prøvet, men såvidt jeg kan finde ud af er det ikke muligt at sende via DTR med MsComm kun via TX og dette kan jeg ikke bruge til noget.
Normalt er det sådan, at TX bruges til at sende data, og DTR er et signal man kun sjældent sætter enten højt eller lavt. Kan det virkelig være rigtigt, at din anvendelse forlanger det omvendte?
cristian_h >> Du kan jo evt. prøve at vise os det dokumentation / diagram du har, så er det nemmere for os at danne os et overblik over hvordan problemet kan løses. Som jespernaur siger, er det normalt TX der sendes data over, og hvis man umiddelbart bruger MsComm eller Windows API, kan der ikke laves om på dette.
Diagrammet ligger her http://www.olimex.com/dev/images/avr-pg1b-sch.gif det er det sted hvor jeg køber dem, og de anbefaler at man bruger Ponyprog, og det virker også kanon, men jeg skal til at lave en app. som skal kunne ganske få af funktioner i forhold til ponyprog, og som jeg kan medsende sammen med mine egne programmer.
DTR is a flow control signal line, you don't actually send data with it.
Usually DTR is left on all the time, lets say you were connecting 2 PCs, the DTR lines would simply indicate that the other PC was actually present. So, using the MSCOMM control you'd set the flow type to RTS/CTS and let the MSCOMM control handle all the flow control for you but before you actually sent anything you'd check to see that the other PC's DTR signal was high because there'd be no point in sending anything if it wasn't
All i can tell you is that DTR is connected to the pin on the MCU witch is used to programm it with (MCU recived), the TX pin is connected to the Reset on the MCU and DSR/RTS is connected to the pin that sends data back from the MCU to the comport.
christian, I must admit that I dont know much in this area although my brother does and he says the follow (dead simple stuff)
------ "Just looking at the diagram I can see that they're not actually sending RS232 data at all.
What they do is use all 3 outputs, DTR, RTS and TX to toggle different things in the device they're talking to.
One of them you call "Ready", The other you call "Clock" and the other you call "Data".
To send the remote device a binary '1' or binary '0' you raise or lower the "Data" and send a blip down the "Clock". The other device sees the Clock signal and reads the state of the Data, the state indicates a binary 1 or 0.
Then by raising or lowering "Data" to indicate 1's or 0's and blipping the Clock you send binary data into the remote device.
To write software such as ponyprog you can use the MSCOMM control. With that you can switch the DTR and RTS signals on or off and sense the state of CTS. You can't EASILY control the TX signal with the MSCOMM control although it would be possible to set the baud rate really slow, say 50bps, use the RTS or DTR for the "Data" and the TX for the "Clock".
The circuit primarily converts the RS232 signal levels (plus/minus 12 volts) into a 5v DC (possibly TTL signal levels) used by the external device.
Or, if the device uses a thing called an "Internal Shift register" (A kind of input buffer) You use your 3 outputs like this.
1 Load 2 Clock 3 Data
Hold the Load signal at logic 1, use the data and clock as per my previous mail to send 32 bits of data (or whatever the shift register size is) into the shift register. Bits are clocked into the regsiter on the falling edge of Clock. Then set Load to a Logic 1 which makes the device take the whole 32 bits (or whatever size it talks in) from it's register and load them into memory.
said it's not as easy to use the TX line in this way. Using the DTR and RTS lines is easy. But, it's just as easy to use the TX. Just use the break Signal instead of the Output method.
Instead of using MSComm1.Output You use MSComm1.Break to set the line one way or the other.
There you go terry, when do i collect my 100 points.
Or, better still tell them if they cross my palm with silver I'll write them a programmer.
That sounds REALY easy !!!!! nooootttt, to me anyway.
Is there a way that i can talk to your brother, and explain to him what I want, and maybe hereafter he can tell me a price ??, or is he just kitting about that ?.
My brotherhas his own company (in UK) and does quite a bit with Seriel communications so he should be able to do something for you
Here is something else he says Well, now that I've read what they're talking about........
The answer is yes you can send data with the DTR line using the MSCOMM control (MSComm1.DTREnable=true/false). But only one bit at a time. The TX line can send whole bytes at a preconfigured Baud rate with start, stop and parity bits. With the DTR line, all you can do is toggle it one way or the other to indicate a binary 1 or 0.
Obviously there's a problem because the MCU does not know when or how fast you're toggeling. So, you use a second line, usually the RTS line and as you toggle the RTS line off, the falling edge triggers the other device to sample the DTR line to read the 1 or 0.
The TX line is used to reset. You send any value at all. it doesn't matter what you send, the falling edge of the last bit simply resets the MCU
There should be a programming document for the MCU indicating what protocol to use. By protocol I mean how to toggle the DTR line and whether to use the RTS as a clock (or whether the MCU supplies it's own clock through pin 9 on the MCU (The PC's Pin 8))
All this seems very complicated. Why not use proper RS232. Well, proper RS232 needs the expense of plus and minus 12 volts as well as a 16550 UART and 1488/1489 line trancievers as well as a interupt mechanism. Much cheaper to do it this way. And once you get it going it really is very quick and efficient.
AND
In one of his mails he said that the MCU sends data back to the PC via the PC's RTS/DSR. Well, looking at the diagram I'd say he's wrong. At the PC end the diagram clearly shows RTS and DSR looped together. This can therefore not be used by the PC to receive anything except it's own RTS state. The RTS signal is clearly being used to SEND something or set some state in the MCU. I'd suggest it's the clock signal as mentioned in my previous mails.
Your brother is right, I said that the MCU sends data back to the PC thru RTS/DSR it is NOT, I think it is sending data from the MCU to the PC thru CTS, hope this makes more sence PC pin 8.
Sorry for the delay, but i've been very busy, I have a friend lokking at the problem, if he can' fix it, I will write your brother.
The reason why I want my own ActiveX components that can do this is because pony can do alot of things, and what my program should be able to do is only to read/write/verify and erase one special MCU, that I'm using with some other app i'm making, and another thing, you have to ask the author if you want to detribute his app. with your own, I did, and got NO answer.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.