 |
|
 |
| Parallax Forums > Public Forums > Propeller Chip > TriBladeProp PCB: Uses 3 Propeller ICs for a Single Board Computer (SBC) | Forum Quick Jump
|
 | 
Dr_Acula
Registered Member
      
Date Joined Dec 2008
Total Posts : 606
| Posted 8/12/2009 5:56 PM (GMT -8) |   | Yes, Cluso, it is data going from an external device to the propeller.
Baud rate does not matter. In vb.net you can send out a continuous stream of data and that fails. But if you send out the bytes individually it works (miniscule delays between each byte).
In a terminal program, it doesn't work with one stop bit but does with two.
Re Kye's post, when you say it samples the first 9 bits, what does it then do? Is it triggered by a high to low transition and then sampling at the half way point for each bit? Or is it using the tranistions to work out the bits?
I'm thinking of the waveforms if you sample 9 rather than 10 bits. What does it do after the 9th bit? Does it then wait one more bit period and assume that should be high as it should then be in the middle of a stop bit and then wait for the high to low transition to start the next byte? Or does it wait longer than one bit period?
I'd answer that question myself looking at the code but I'm still trying to learn PASM? Thnkx for being patient with these questions! | | Back to Top | | |
|
Dr_Acula
Registered Member
Date Joined Dec 2008
Total Posts : 606
| Posted 8/12/2009 7:01 PM (GMT -8) | | Yes, sorry, two threads and conflicting comments. My mistake.
Data going out of the propeller works perfectly. Receiving data works perfectly with your code IF you put in two stop bits instead of 1, OR IF you put a slight delay between the bytes coming in.
But it won't work on a continuous data stream of bytes, with no pauses and only 1 stop bit.
I guess I'm being a bit of a perfectionist here. But on the other hand, a continuous stream of data with 1 stop bit is quite a common format for RS232.
I think it is something to do with the way you resynchronise at the beginning of the byte (or not, as the case may be). See the other post for the technical question and the code. | | Back to Top | | |
|
Dr_Acula
Registered Member
Date Joined Dec 2008
Total Posts : 606
| Posted 8/14/2009 7:07 AM (GMT -8) | | No never tried decreasing the voltage. Though I almost always derate the clock on a Z80 - usually to about 3.6Mhz, as it saves power and games run better (cheating? , moi?). You know, a week ago I'd have been very interested in interfacing a Z80 and Propeller. But now, with the entire thing working in an emulation, it somehow doesn't seem so important.
As an aside, today I also soldered up an old-school Z80 board with a real Z80, eprom etc. The Zicog still isn't quite there yet - next little issue to sort out is the speed of the sd card access, which is about 1/10th of the speed of talking to a ram disk on the N8VEM. I've got used to MBASIC booting instantly. But this will come. Meanwhile,
Working things are:
The triblade running a Z80/CPM emulation using just 5 chips.
SD card with multiple disk drive emulations
Xmodem file transfers from any terminal program
Wordstar working
MBASIC working
SBASIC working
BDS C working
Assembly compiler working
Things I'd really like:
More serial ports
VGA and keyboard and the zicog on one propeller (even if it sacrifices a little speed)
Battery backed ram disk like on the N8VEM for faster file access on drive A
An expansion bus with 8 digital lines, 3 address lines and /WR and /RD for talking to external latches/input chips (373 and 240)
A 20x4 LCD display like on the N8VEM for a portable solution (running as well as the vga terminal, like on the N8VEM)
The N8VEM forum has brainstormed hybrid Propeller and real Z80 systems. I think soon we are entering a very exciting time when it can all be done inside an emulation. Or at worst, two propeller chip emulations.
See humanoido's thread for a photo and text printout of some programming on the triblade/zicog.
Running a Z80 at 3.3V? Thinking about that more, I wonder if that would work? | | Back to Top | | |
|
Cluso99
We live onboard
Date Joined Apr 2008
Total Posts : 2276
| Posted 8/14/2009 9:55 PM (GMT -8) | | James:
Can you try the attached modified FullDuplexSerial in place of Kye's SerialEngine ?
I have added rxavail which returns true (-1) if there is a character available. If this still loses characters with 1 stop bit then I will fix it (make it 2 cogs) for now.
So...
UART.TransmitCharacter --> UART.tx
UART.TransmitCharacters --> UART.str
UART.ReceiveCharacter --> UART.rx
UART.ReceiveNumber --> UART.rxavail (BUT IT RETURNS TRUE=-1 IF CHARACTER AVAILABLE)
Links to other interesting threads: | | Back to Top | | |
|
Dr_Acula
Registered Member
Date Joined Dec 2008
Total Posts : 606
| Posted 8/15/2009 5:09 AM (GMT -8) | | Hi Cluso, studying the code now.
I spent several hours changing the code over to Kye's object, and I know it will take just as long to change it to this new code.
So before I embark on that, can I ask -
Is this already working with the usb/serial chip?
Returning -1 if no byte - yes need to go through each line and check that.
I need to get my head around the PASM code. I find this code so hard to understand as there are some basic concepts I need to grasp. eg, in the Rx bit it has an instruction jmpret rxcode txcode
I don't understand this instruction. Where does it jump to? A label rxcode, but this does not exist. To 'res 1', but what does that do? To another jmpret instruction that also references rxcode? To the 'chunk of transmit code', but that code starts with 'transmit' and the first instruction is to jmpret back to receive. So I can't follow any of the program flow, and thus it is hard to work out exactly what it is doing.
The fundamental problem is to sample the start bit finely enough that you can capture the negative transition fairly soon after it happens, and then put the sample point in the middle of the bit, and then ensure it samples in the middle for the rest of the bits. But also, that puts the last sample point in the middle of the stop bit. Then you need to start sampling finely again to pick the next transition. But how do you then synchronise with sending the bits in the tx? Kye synchronised both together, but it only works because the Rx has one extra stop bit so the Tx ended slightly sooner. What I am trying to work out is the maths of fitting in proper stop bit lengths for the final stop bit on a Tx when the Rx already has shortened that slightly by the slight delay introduced by the time slice delay on the initial start bit.
It is very complicated to work out a formula to do that if you only have one stop bit and there is a continuous stream of Rx bytes and you want to fit in Tx at the same time. The Tx code gradually gets out of synch - and the bigger the time slice on the Rx at the beginning the faster it is out of synch - eg 1/8th of a bit gets out of synch in as little as 8 bytes.
Unless the code can cope with Tx and Rx having their start/stop bits out of synch. That, I think, is the key, but it involves some extra counters to keep track of where it is up to and I can't see those counters in this object.
Unless you accept slightly short stop bits on the Tx. But that is a fudge and assumes the device at the other end can handle that, which assumes the device at the other end is doing things properly like sampling in the middle of the bit. Or you accept slower baud rates. But what if the device at the other end is another propeller?
Someone mentioned on another thread an object that can handle 4 uarts on one cog? I wonder how that would work, and whether the above complexities have been considered?
Also, this is such a complicated thing to explain that it almost needs a drawing at the beginning of the code to explain the waveforms and where the sampling happens and how it shifts back and forth between Tx and Rx.
It is sooo much simpler just to add two stop bits. Which is what Kye said. But I would like to get to understand the pasm code a bit better in order to work out the timing works. And, sorry for the long post!
Addit: Cluso, some time back there was mention of the drives being 32mb ie 8mb drives but only 1mb is available. I think the simh has drives I onwards as 8Mb. I tried putting a blank drive I image on the sd card and then adding the drive in the code
FindDriveBase(8, string("DRIVE__I.DSK")) 'set the SD card drive base(s) 8MB HARD DRIVE
But it gives a whole lot of errors when trying to access the drive. Did you ever get this working by any chance?Post Edited (Dr_Acula) : 8/15/2009 2:22:27 PM GMT | | Back to Top | | |
|
Dr_Acula
Registered Member
Date Joined Dec 2008
Total Posts : 606
| Posted 8/15/2009 4:36 PM (GMT -8) | | Sorry for the long delays - working all this weekend. They do give me internet access at work though.
Lots of things could give you a continuous stream of RS232 data but maybe this hasn't come up because most people are using the USB to serial chips and those chips are putting in longer stop bits? A dedicated cog ought to be able to produce the right waveform though - just make it a Tx only so as not to confuse things. This is a very complex problem to solve though - and it isn't quite a cut and paste job going back and forth in the code between different serial objects, eg Kye's code doesn't have a hex output print, so you have to put that in the main code instead. Maybe all input output could go through just a few subroutines in the main program first - I might look at that (also would solve the 13,10 vs 10 issue). Otherwise it might be heading towards ifdef hell. At least the 2 stop bits is a practical solution.
Cluso, did you say at one stage you had dropped characters in CP/M3? If so, then maybe you have seen this problem too?
Oh, and testing it, you can replicate it on xmodem but can't see the problem in action. Better to do it by running wordstar, open a document and then send some text into that document as a continuous serial stream. Then you can see it dropping characters with one stop bit but not with two.
I was pondering a cog to do 4 asynchronous inputs, and another cog to do 4 outputs. At least it might be easier to understand. jmpret makes sense now, but it is still very hard to trace out the exact timing.
I think this problem is going to be harder to solve than some of the other problems that still need looking at. Is it possible to look at getting the 8mb hard drives working, and also dropping in the faster sd card routines?Post Edited (Dr_Acula) : 8/16/2009 1:05:17 AM GMT | | Back to Top | | |
|
Dr_Acula
Registered Member
Date Joined Dec 2008
Total Posts : 606
| Posted 8/15/2009 5:57 PM (GMT -8) | | | Brilliant - can't wait to give it a try. And I agree re the hex thing - otherwise the objects end up with too much 'bloatware'. Will the new code be available in the next 24h? | | Back to Top | | |
|
Dr_Acula
Registered Member
Date Joined Dec 2008
Total Posts : 606
| Posted 8/15/2009 9:23 PM (GMT -8) | | | Ok, will do when I get home. (I'm busy suturing lacerations at the moment). I'd also looking forward to testing that half duplex code. And then Kye's new code as well. | | Back to Top | | |
| 849 posts in this thread.
Viewing Page : |
| Forum Information | Currently it is Friday, November 20, 2009 10:59 PM (GMT -8)
There are a total of 393,737 posts in 55,521 threads.
In the last 3 days there were 82 new threads and 702 reply posts. View Active Threads
| | Who's Online | This forum has 17687 registered members. Please welcome our newest member, mark09.
58 Guest(s), 6 Registered Member(s) are currently online. Details
Peter Verkaik, BradC, Harley, Chris Savage (Parallax), Rich_W8VK, potatohead |
Forum powered by dotNetBB v2.42EC SP2.02
dotNetBB © 2000-2009 |
|
|