BasicMicro - Forums

I have another issue with SERIN command. In short, it cannot receive a string longer than 2 bytes on speeds higher then 4800. All bytes after the second one become corrupted (random bytes instead of expected data).
I tried two connection options: first is the serial adapter I described in one of my previous posts (based on 74LS04 inverters) and second is FT232RL. Results are the same.
The code is:

I use RXTX serial communication Java library to generate serial stream. If I insert 1 ms pauses between individual characters transmission becomes stable and long strings can be transmitted that way.
Another interesting observation is that when I insert INTF = 0 statement at the beginning of the program (right after the array declaration) only one byte can be transmitted reliably, all subsequent ones become scrambled.

Ken, I'm starting to have doubts about your motto on assembly and finishing the project before retirement.
Please, let me know if you need any additional info to reproduce it.
Thank you.

What can I say, Rita? I just measured the bit cell period for a programming download and it was 8.79us. This is approx. 113KBaud. Your slowpoke 4800 Baud is 206us. This is on the same pin, doing bitbang. The manual says the Nano's bitbang serial is good for up to 38400 Baud. So your 4800 is well within this range, but the very high download speed for programming speed is a mystery. But, hey, it works.

At this point I throw my hands in the air. You are using a home made circuit board with questionable translation circuitry to deal with the RS232 signals. Once it started programming reliably you pronounced it usable. I have no idea what your training or capabilities are. Maybe you you do great soldering on protoyping circuits, maybe not. Maybe your components are serviceable, and maybe they aren't. Perhaps your PC is on it's last legs and the serial port is questionable. I have no knowledge about the Java program you're using to exercise your circuit. I know diddley about assembly, so can't say why "INTF = 0" slams the circuit. I can't look over your shoulder. I give up.

In the future I recommend you call
1-800-535-9161 (BasicMicro)
and press the number for support. Only they have the expertise to answer your questions at this point.
Take care.

_________________
kenjj
http://blog.basicmicro.com/
http://kjennejohn.wordpress.com/

Hi Rita,

If this is your total program, I am like Ken and wondering if it is specific to your setup. Now if you said you had other things in your program like HSERIAL enabled or HSERVO or anything else the generates/process interrupts, I could easily suspect that.

However I would not rule out issues with serin either. Since I don't have one of these chips I can not test it. If you have some form of Oscilloscope or logic analyzer I would personally try hooking it up to your IO pin and see what you are getting. Why? On an Atom Pro 28, I can not use:
serin xxx,i115200, [...] to talk to a Lynxmotion SSC-32. It has obviously not worked for a long time if ever at that baud rate as all of the programs and tutorials up on the Lynxmotion website use i38400, yet the Bap should be able to go at that speed. (I wrote my own assembly language functions which work fine at this speed) So I checked on my logic analyzer and found that the analyzer thinks the output is at the speed 125000. The developer has been notified on hopefully he can fix it.

Good Luck
Kurt

Thank you for your reply, Kurt. I analyzed the serial signal I was getting from the computer port and it looks completely normal: right baud rate and stable clock. I did not set any interrupts either.
Actually, this message was just a bug report for BasicMicro, not a call for help. At the moment I'm testing Atmel's ATTiny because I want to chose the best platform before I commit to it and so far I definitely like AVR better. I won't go into details here because it would be incorrect to advertise Atmel platform on a BasicMicro forum
I'll probably find some use to the few Nano modules I have, but it will be something simpler and not requiring any serious speed.
Have a good one,
Rita

Understood

However I will give a couple of other things you might try just in case. Also because maybe someone else will run into the same problem...

The only other things I would have suggested was to try to change stuff on the PC side.
a) Can you change the baud rate or is specific to some device.
b) Since you can receive 1 or 2 characters before it gets corrupted maybe the code is on the edge on picking up the next start bit. Can you change the comm port on the PC side to use 1.5 or 2 stop bits?

Good Luck

Kurt

P.S. - I also like Avr processors, but as you said that is a topic for a different place. I also like the Renesas H8 processors used in the Atom Pros!

I just thought that usually people use SERIN to read manual input from the terminal which is very slow. I'm not sure if anyone tried to read a string of bytes sent back to back immediately one after another. Yes, I also got impression that SERIN may have it's serial timing a bit off and when the data is coming in too fast it does not have time to adjust, so it accumulates over the first couple of bytes.

Yep that is one place I use serin, but I also use it for:

a) Talking to an SSC-32 servo control board, which I would like as fast as possible
b) Talking to an XBEE which is talking to some other xbee like control input from remote control again I am talking at something like 62500.
c) Soon maybe try the serial communications to the BM Motor controller with encoder support
D) GPS and other sensors that output in serial format.
...

As you said there could be an accumulation error, which is why I suggested the stop bit change. Likewise I have had problems if I have any of the hardware support functions enabled (HSERIAL, HSERVO...) or my own stuff that generate and process interrupts. That is why many times in my code you will see things like:
disable...
serin/serout...
enable...

Good Luck
Kurt