Ok so in the process of trying to figure out why my BAP isn’t transmitting serial to my PC I found the DTR thing being discussed in the new ABB thread. However now that I’ve got a meter and cut a serial cable to release the pin I still have not figured out what is up with this thing.
Using the Atom-Pro 7.2.0.6 IDE and the FindAtomPro button returns ATOMPRO28 on COM1, which is a hardware serial port on a desktop PC.
I have tried having the FIFO enabled and disabled (through the advanced properties dialog in device manager) with no difference.
Some simple code that I can’t figure out what I am missing
loop
hserout [mycntr, 13]
pause 2000
mycntr = mycntr + 1
goto loop
end[/code]
which I think should send a character starting with ‘0’ then ‘1’, ‘2’, ‘3’, … followed by a every 2 seconds out the serial port.
Any idea what I’m missing?
edit: Oh, I’ve tried the 8.0.0.0 IDE too and it doesn’t seem to matter.
Are you getting gobblygook output at all? You definitely won’t get “1”, “2”. etc using the above code.
You should set mycntr=1 and use DEC mycntr in the hserout command as follows:
mycntr = 1
loop
hserout [DEC mycntr, 13]
pause 2000
mycntr = mycntr + 1
goto loop
The above code should get you what you want if the hardware serial output is working and everything is properly connected.
I found a post in june of 2006 by Acidtech in the Atom Pro Hardware forum for basicmicro that related the contents of the atompro24 data sheet to the atompro28 module which you know still doesn’t actually have a data sheet. At the moment I can’t actually see how it is the S_IN and S_OUT pins connected to the DB-9 on the ABB and used to program the Atom board actually have anything at all to do with the hserial commands, which seem to be coming from P14 and P15… but then I can’t tell if the P14 and P15 are the signal names on the 3664-48F pins 35 and 36 or pins 37 and 38… and that’s made worse by pins 35 and 36 being named P21/RXD and P22/TXD (suggesting these are the hardware serial pins) while 37 and 38 being named P14/IRQ0 and P15/IRQ1. So we have about 4 entirely different sets of “names” applied to any one of the aforementioned pins and I’ve about had enough for tonight.
btw, if the parameter string to hserout works the same way as the parameter string to the debug command then it will spit the value of the mycntr variable out the serial port, which is initialized to 48 decimal = 0x30 = ASCII for the character ‘0’, followed by the value 13 decimal = 0x0d = ASCII for a carriage return. It works in debug mode using “debug [mycntr,13]” which is why I thought it would work as serial output too.
The H8/3664 pin numbers are depend on the actual package that is used. P14 and P15 of the Atom PRO should be the hardware serial port pins. I don’t think these pins go to the DB9 connector though. I took the chip pin numbers from the Renesas H8/3664 hardware manual.
I think you will have to wire up a two pin serial cable to use the hardware serial port P14/P15 pins on the Atom PRO, but this is just a guess since I have never tried this.
This is the best information I can dig up from manuals and datasheets.
It would be interesting to see how this resolves out.
My assumption is that hserial referes to RXD, TXD pair that on page 187 shows that these are on pins P14 and P15 (pins 23 and 24) of the Atom Pro. And these do not connect up at all with the DB9 that is on the ABB board. The S_IN and S_OUT (debug) pins are connected to the RS232 port and are physically on pins 1 and 2 of the Atom Pro.
I have been meaning to try out the hardware serial port, but I thought I would probably need to wire up some additional hardware like a MAX232 to convert the signals from TTL to signals that a PC would want…
yeah I’m thinking you are probably right in that the hardware serial port has nothing to do with the db9… which defies logic and means I wasted some money as I was trying NOT to have to breadboard up a rig to connect this to the mini-ITX board. If I wanted to do that I could have just wired up a pic ands saved a bunch of $. I’ll come up with something eventually. thanks for the thoughts in figuring this out.
Depending on what you need to do, you can always poll on S_IN. It is not the greatest, but my Brat program does this. It has code like:
[code] ;
; now lets try to get some serial input from our Host PC
;
serin s_in, i2400, 250, GCHTimeout, [sdec GHCCnt]
; Ok we got a count. If it is -1 then it is a do immediate!
if GHCCnt = -1 then
; now lets try to get some serial input from our Host PC
serin s_in, i2400, 5000, GCHTimeout, [sdec GHCVals(0), sdec GHCVals(1),sdec GHCVals(2),sdec GHCVals(3),sdec GHCVals(4),sdec GHCVals(5),sdec GHCTime]
[/code]
in it’s main loop to see if I have any code on the PC that is telling it to try to do something…
yeah you could probably implement something using the bit bang routines and half duplex. not really ideal but I’ll mess with it and see what I can get it to do. it’s not gonna work right with a comm program without handshaking because of the asynchronous nature of a command being sent and the need for the loop in the bap to be in the serin routine at that moment. rts is shunted to dsr on the db9 so I might be able to bring a port pin to cts on pin 8 and enable hardware handshake at the PC. that way it could clr cts as you call serin and set it when you exit (remember it’s inverted) but it might need a pull-up resistor to work. I’ll mess with it and see if I can get it to work acceptably.
the other piece of this is I was hoping to read the two quadrature encoders using interrupts but if I use the bit banged serial routines I’m either gonna get screwed up communication or miss counts when I disable the ints.
I tried and tried to get interrupts to work on the Atom PRO, without success. I tried everything I could find in the hardware manual too. If you have success, please post your results.
It may depend on which interrupts you wish to get working. The TV Brat code uses two interrupts. WKINPT_3 and TIMERA. The code for these are posted under the Biped forum.
Dale, I forget which Interrupt you could not get to work…
But back to serial communications. Yes I fully understand your desire to use the hardware serial port. I have had some of the same issues when I added code to my Brat to handle a serial LCD and also to talk to the PC to see if there are any commands for it. I have a rudimentary program like SEQ that allows me to try different servo sequences and so my main loop looks to see if there is any commands coming in from the PC. I had problems at 9600 baud. I finally got it to work reasonably well at 2400 baud.
Well I have looked at trying to add very few parts to allow the hardware serial port to share the db9 connector with the ba§ module. The biggest problem is the ba§ modules are half duplex, that is the s_in signal is wire-or’d back to the s_out at the ttl level. so at the db9 you would have to “break” the half duplex which means a jumper selection on either pin 2 or pin 3 (of the db9). depending on which way you go you wind up having to add more parts than just the simple wire-or’d inverters I’d hoped for to get shared rs-232 signals. I didn’t think the addition of the half dozen parts including a 3-pin jumper to the abb was going to fly so I just sort of dropped it.
I DO think there is still merit in adding the 2-pin jumper header to the DTR signal from the DB9 pin 4. If you are willing/able to use the software bit-bang based serin/serout signals and half duplex communications the DB9 can be used for communication, and being able to disconnect the DTR from the ba§ reset helps use several more common communication programs on a PC.
Another addition that may have significant value is the addition of a SECOND jumper to allow a connection from a ba§ port pin (pick one) to the DSR signal on the DB9 pin 8. This allows the ba§ to be the master of the half-duplex communication much like the direction signal used in an RS-485 style connection. Its use this way doesn’t really conform to the textbook definition of the DSR handshake but… it lets the ba§ module tell a host whether or not it is listening with the serin command.
In reality implementing that second jumper on CTS would be more useful as that is really what it is meant for (CTS = Clear To Send) but I don’t have the knowledge to know what the implications of breaking the existing hardwired RTS to CTS connection at the DB9 would be to other software using the abb+ba§ combination. So unless somebody else who knows a lot more about all the things typically connected to an abb wants to chime in and say that manipulating the handshake lines would have no impact then I’m just gonna walk away.
I’ve already posted in the walter thread (I think it was) that I used the guts of A-Bot’s ping)) code to read my sensor successfully.
My infrared sensors near the tracks are reporting correctly, but it’s not like that was difficult or anything.
I have not done anything with reading the quadrature encoders using interrupts yet. I’ll try and get to that this weekend and see what happens. If I can get the interrupts to be recognized it should just be a couple of simple conditionals in the service routines so hopefully it won’t screw anything up timing wise.
I just wanted to explain why the hardware serial pins are not the S_IN and S_OUT pins. We did not want to limit the hardware serial to only be used with inverted(eg PC style) signallying. The S_IN/S_OUT pins must be PC style because they are used to program the module from the PC. There are many applications that connect serial to other devices using TTL level signalling and since there is only one hardware port on the Atom/AtomPro we decided to error on the side of flexibility.
I think my initial reaction was this didn’t make sense but after having spent several hours deciphering what is going on and if there was some way to work with or around it I had pretty much gathered it was a cover as many bases as you could solution. I also figured there may have been some established precedent device that the circuit wanted to be compatible with so as not to alienate portions of a market. I actually went so far as to enter the abb schematic into my capture and layout program and replicate most of the abb layout to see if I could find a way to add the rs232 flexibility to the hserial pins. There just were not any “simple” changes that could be made, and there is always a lack of enthusiasm to make more involved changes to an established and functioning design without some significant gains (which this isn’t), so like I said I just let it drop.
Not to worry. Just thought I’d let you know the AtomPro40+(yes the plus is part of the name) has two hardware serial ports so we were able to put one on the S_IN/S_OUT pins and another on the P14/P15 pins. I finished testing our prototype last weekend. We’ll be sending them out for production as soon as we get the PCBs in. 56k program memory, 20mhz and onboard RTC are the main improvements of the “regular” AtomPros. There will be a new release of the AtomPro software as well when we start shipping these which has all the current bug fixes in it and a slightly updated hservo system(32 servo background support with max of 2.02% processor usage).
thanks for the thoughts in figuring this out.