So the RS-232 input is bit-banged? Probably why it’s called a diagnostic port and download port.
I take it pin 15 is the hardware USART. Figures. A lot of data goes out that port to the SSC-32.
I’d be tempted to “double up” on the hardware port. Let it receive from COM, and xmit to SSC-32. Although you wouldn’t be able to get replies from the SSC-32. The SSC-32 doesn’t seem to mind too much when it receives irrelevant text. However the levels would now be wrong; would need another part.
Guess I can’t get away with buffered COM I/O that easily!
That kinda explains why a delay at the bottom of the big loop is used, and why as you indicated the “receive” time matters to the speed of the 'bot.
Yep, all of the code that deals with serin/serout is bit-bang code. Only hserout/hserin uses the hardware usart and also has interrupt code to do the buffering of the IO… That is why the handshaking is so particular. It is also why having interrupt processing code has a tendancy of screwing up some of the bit bang functions…
Nathan last year was talking about maybe adding hardware assisted serial IO that would use a timer tick to help control the IO. Not sure what the progress is on that. I also wish the BAP40 would come out with a new controller board as not only does it have 12 more IO pins, it also has a second USART, but that is a different topic!.
Seems funny that the Atom Basic module would use bit-bang on it’s RS-232 buffered (and connector’d) COM port. I realize that’s the programming port, maybe that’s it.
We use RS-232 “debug” modules to get from rarely used TTL on our boards at work out to a PC. Simple Maxim chip w/ caps. That could work I suppose. And a BlueTooth module is TTL anyway.
More I/O could be useful. And I’d love to have the 2nd USART.
Anyone tried the ‘C’ compiler on the pro? Of course some of the routines that are now LIB would have to be written in C, or possibly the LIB files (do they work the same as the Atom Basic?) could be adapted for linking with the C files.
Yes, it was surprising that their main RS232 comm port does not have any hardware support, Although it is nice that they left it available on P14 and P15. I have meant to try to plug P14 and P15 into the Max232 type chip on the SCS32, but have not tried it yet.
I have also used the Max232 type chips on the SRS workshop kit and I have experimented with one plugged into a breadboard with the appropriate capacitors plugged in.
I have done a little experimenting using the C compiler on the Pro. Not much, but did have a hello world type app that blinked leds. I was working on having the PS2 working as well not sure if it was working when I stopped probably six months ago…
More or less the Basic code is not compatabile with C. They developed their own calling conventions and the like. It would great if we could modify some of this code to build some libraries that we all could call. My guess is that Basic Micro does not currently have t he bandwidth to do this.
The LIB code, at least for the Basic Atom, is .ASM code, which should suggest either C code or inline .ASM code for the C compiler. I take it the GNU C compiler supports inline ASM?
Won’t be a “drop-in”, but do-able. I have C code for the PS2, but I’m not happy with it. It works, just. I haven’t looked at it for a year. I am finding that the battery level of the PS2 wireless joystick is quite important; and I’m always leaving my PS2 on. Might be part of my problem.
I did just get a LA1024 logic analyzer! I intend to analyze the PS2 SPI waveforms, and see if I can make mine conform a little better. I think you mentioned the LA1024 to me?
I’ve used PASCAL calling conventions at other time to call various libraries. the Atom LIB files aren’t true “LIB” files, more like “include” files of inline ASM (SURPRISE!). don’t know if it’s the same for the 'pro. I have a 'pro chip on order. It would be a kick to run my code on the 'pro in C.
So what are you using for a compiler manual for C?
Can you connect a bluesmirf to the mini-abb board for serial comms from a pc? i have found on the forums how to connect to a ssc-32 board but what if it needs to be connected to the brains! Mini-abb???
I’m about to find out. The SIN/SOUT pins on the Basic Atom are level shifted already (~RS-232) for connection to a PC; the Blue Smirf wants to talk TTL. If you just want comms, then using pins 14 & 15 give you a TRUE hardware USART (pins 1 and 2 are bit-banged, pin 3 for reset via RTS).
Re- level-shifting could allow a Blue Smirf to talk to pins 1,2,3 (takes a chip).
There might be an RS-232 level Blue Smirf.
Using pins 14,15 would be OK for just coms. Probably what I’m going to do for telemetry/debug (although the IDE has a nice debug window).
