From: 谢继雷 <xj...@99...> - 2010-07-15 19:12:43
|
Hi, I've post the question to http://stackoverflow.com/questions/3258986/how-to-cat-file-in-a-specific-baud and I want to know if there is some options to control the simulated serial line's baud to S51 simulator. s51 -tC52 -S in=testdata.in,out=testdata.out commtest_m.ihx In this example, the serial input from file testdata.in is sent to S51 too fast, and many frames are lost. When the serial input from /dev/tty (user keyboard) does work well. Lenik |
From: Daniel D. <dr...@ma...> - 2010-07-15 22:21:02
|
On Fri, 16 Jul 2010, 谢继雷 wrote: > and I want to know if there is some options to control the simulated > serial line's baud to S51 simulator. Obviously there is no such option. Baud rate is controlled by SFRs of timer and uart. Simulator counts ticks and when all necessary bits are "received" it reads in one byte from the input file and makes availabe as content of UART's data register. > s51 -tC52 -S in=testdata.in,out=testdata.out commtest_m.ihx > > In this example, the serial input from file testdata.in is sent to S51 > too fast, and many frames are lost. When the serial input from /dev/tty > (user keyboard) does work well. You should check if your main is fast enough to process continous data, or check sync of main and ISRs. You can place breakpoint at serial ISR and check if it happens at expected time (check receive only case without sending). Or provide me values of SRFs (or source code of a stripped down example), and I'll try to check if there is a simulator bug. Daniel |
From: 谢继雷 <xj...@99...> - 2010-07-16 07:35:31
|
On 2010-7-16 06:04, Daniel Drotos wrote: > On Fri, 16 Jul 2010, 谢继雷 wrote: > > >> and I want to know if there is some options to control the simulated >> serial line's baud to S51 simulator. >> > > Obviously there is no such option. > > Baud rate is controlled by SFRs of timer and uart. Simulator counts > ticks and when all necessary bits are "received" it reads in one byte > from the input file and makes availabe as content of UART's data > register. > > >> s51 -tC52 -S in=testdata.in,out=testdata.out commtest_m.ihx >> >> In this example, the serial input from file testdata.in is sent to S51 >> too fast, and many frames are lost. When the serial input from /dev/tty >> (user keyboard) does work well. >> > > You should check if your main is fast enough to process continous > data, or check sync of main and ISRs. > > You can place breakpoint at serial ISR and check if it happens at > expected time (check receive only case without sending). > > Or provide me values of SRFs (or source code of a stripped down > example), and I'll try to check if there is a simulator bug. > > Daniel checkout for this, svn://svn.bodz.net/usnap/miadev/trunk (username&password: miadev, with rw permission.) The directory structure: arch/cos51: COS51 is my C framework for 51 chip and peripherals. arch/cos51/dk/hc6800.h: resource definition for my DK board (You may create new one to match your own DK board. ) test/cos51: unit test files The referred example is test/cos51/comm1test.c and comm2test.c, the two corresponding two Timer 1 driven serial port and Timer 2 driven serial port. Both tests are fine if thru TTY, but failed if by plain files. To build the example, first make arch/cos51, then make test/cos51. I'm building under Cygwin port of sdcc/ucsim, and I didn't have tested on any *NIX yet. Lenik |
From: Sébastien L. <sq...@gm...> - 2010-07-16 08:34:22
|
hi, giving away a write enabled svn access on a worldwide public mailing list is not exactly the right way to do it... at least you could make it read only! Do you realize how fast your repository could be screwed with gazillons of useless commits, eating up disk space with huge binary files? remove this access ASAP! seb |
From: 谢继雷 <xj...@99...> - 2010-07-16 10:55:31
|
On 2010-7-16 16:34, Sébastien Lorquet wrote: > hi, > > giving away a write enabled svn access on a worldwide public mailing > list is not exactly the right way to do it... > at least you could make it read only! > > Do you realize how fast your repository could be screwed with > gazillons of useless commits, eating up disk space with huge binary files? > > remove this access ASAP! > > seb Thanks, well though it's not happened, I removed the write permission. But, as I made the svn address public, there'll be someone hacks into the system all the same? Then, I should close the SVN and shutdown the server at all, and at last I can't do anything at all isn't it? Thanks for you advice. Lenik |
From: Sébastien L. <sq...@gm...> - 2010-07-16 11:39:03
|
Hi, No. Only the write access was obviously a giant breach. Giving a read access is totally normal and is what all open source projects do. When someone has something to write, he can send you a patch against a known svn revision. Then you can import the patch by yourself, and make contributors' work visible, while retaining full control on your server. Regards Sebastien On Fri, Jul 16, 2010 at 12:22 PM, 谢继雷 <xj...@99...> wrote: > On 2010-7-16 16:34, Sébastien Lorquet wrote: > > hi, > > > > giving away a write enabled svn access on a worldwide public mailing > > list is not exactly the right way to do it... > > at least you could make it read only! > > > > Do you realize how fast your repository could be screwed with > > gazillons of useless commits, eating up disk space with huge binary > files? > > > > remove this access ASAP! > > > > seb > Thanks, well though it's not happened, I removed the write permission. > > But, as I made the svn address public, there'll be someone hacks into > the system all the same? > Then, I should close the SVN and shutdown the server at all, and at last > I can't do anything at all isn't it? > > Thanks for you advice. > > Lenik > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: 谢继雷 <xj...@99...> - 2010-07-16 12:06:34
|
On 2010-7-16 19:38, Sébastien Lorquet wrote: > No. Only the write access was obviously a giant breach. Giving a read > access is totally normal and is what all open source projects do. When > someone has something to write, he can send you a patch against a > known svn revision. Then you can import the patch by yourself, and > make contributors' work visible, while retaining full control on your > server. Ok, it's done. I deem it's going far away from uCsim topic. I have copied some serial communication examples from MCS-51 course books, build them using SDCC, and simulating the same way for both plain files and /dev/tty. None works. Both tty and plain files are losing frames. The testing command line: s51 -tC52 -S in=/dev/tty1,out=/dev/tty1 rs232_example_m.ihx s51 -tC52 -S in=testdata.in,out=/dev/tty1 rs232_example_m.ihx Thanks, Lenik The example is included in the attachment. |
From: 谢继雷 <xj...@99...> - 2010-07-17 01:29:47
|
On 2010-7-17 08:10, Daniel Drotos wrote: > On Sat, 17 Jul 2010, 谢继雷 wrote: > >> This reminds me. But as main just read from it to check whether >> buffer is filled, even though it maybe changed by ISR, it's just fail >> the test but not the buffer contents. So later in the next loop, >> main() will find that recvp pointer is moved, and the filled contents >> will be read out correctly. > > You are right, my modification of using recvp is not needed, but not > bad anyway and makes it more safe. > >> I've just debugged into with s51, and set breakpoint on RI, in fact >> before main first time to start to check the ring buffer, the frame >> lost is already happened. > > Finaly I've found the problem. Your main() is in sunit.h and there you > set ES and REN to 1 before calling test function, so before setting up > uart and timer. > > Simulator (as real cpu) starts to read in input when there is clock > for uart (timer1 started) and REN=1, so for correct operation TR1=1 or > REN=1 must be the last step, when everyting is set up. See my diff > (against the original sources), it works correctly. > > See the changes about sending, which are also required to make it work. > > Daniel Yes, great mod! I've discovered this too last night. Replace TI with sending is very clear. Thanks, Lenik |