 |
|
 |
| Parallax Forums > Public Forums > Propeller Chip > TriBladeProp PCB: Uses 3 Propeller ICs for a Single Board Computer (SBC) | Forum Quick Jump
|
      |  Cluso99 We live onboard

       Date Joined Apr 2008 Total Posts : 2276 | Posted 8/17/2009 6:33 PM (GMT -8) |   | @Kye: My apologies - there is no bug in your ReceiveNumber code (called rxnum below).
Currently lacking hardware at the moment, I was not able to see my flaw. Since I had to go through examples to prove it, I thought I would post what I did for others to see... The cyclic buffer method is used in other code such as FullDuplexSerial.
Here is an example. Lets say for simplicity, the buffer is 256 bytes in length and begins at hub $1000.
Head points to the relative position in the buffer where the next byte will be stored. Tail points to the relative position in the buffer where the last character was obtained from. When head == tail there is no data available in the buffer. Head increments each time a byte is placed into the buffer and Tail increments when a byte is taken from the buffer. Both wrap-around at the end of the buffer to the beginning of the buffer by ANDING the result with the buffer length - 1. A 256 byte buffer is ANDED with $FF. If more bytes than the buffer length are added into the buffer before they are taken, then depending on the code, either a block of bytes are lost (equal to the buffer size and the oldest) or the new bytes are lost until space is available.
When empty the head and tail point to 0 (which is $1000 + 0). Fine.
When 10 bytes have been input, the header = 10 and tail = 0. rxnum = (head - tail) & $FF = (10 - 0) & $FF = 10. So correct.
When 257 bytes have been input and 254 bytes taken, header = (0 + 257) & $FF = 01, tail = (0 + 254) & $FF = 254
So rxnum = head - tail = (1 - 254) & $FF = -253 & $FF = $FFFF_FF03 & $FF = 3. So you are correct and my apologies.
Note: 10 = $0A, 254 = $FE, 257 = $101.
@OBC: You are welcome to add this to your Tips and Traps :-) Links to other interesting threads:
| | Back to Top | | |
 |  Dr_Acula Registered Member

       Date Joined Dec 2008 Total Posts : 606 | Posted 8/17/2009 7:05 PM (GMT -8) |   | Sorry for the delay.
Good and bad news. Ok, good news is that the past post by Cluso works and I think we are now getting back to a common file between us! Even better news, the bst compiler doesn't give any warnings. (suggestion, maybe include bst.bat and bstc.exe in the package - only adds a tiny bit to the storage on the forum)
The bad news is that the carriage return/line feed is still a muddle. It went from overprinting with no line feeds to now putting in two line feeds!
I found the reason - not in the main program but in the fullduplexserial object.
' Optionally add LF after CR
if rxtx_mode &%10000 and txbyte == CR repeat until (tx_tail <> (tx_head + 1) & bufmsk) tx_buffer[tx_head] := LF tx_head := (tx_head + 1) & bufmsk
if rxtx_mode & %1000 rx
I think I can see the reason you have put it there, because CP/M outputs CRLF after each line and I think the terminal program you are using treats CR as if it is CRLF. Or something like that - I'm not sure why you are not getting double spacing either.
Anyway, I'm preferring to stay with standard terminal programs like Hyperterm and Teraterm and remote Telnet and also down the track, the PockeTerm (see attached). I wonder if the terminal you are using could be edited?
CP/M outputs 13 then 10 after each line. The bootup sends just 13, and 10 if you want to add it.
The idea I have is to leave out the ifdefs, delete all references to CR, even delete CR and LF as definitions in the main program. Just a philosophical thing too, but a uart object really should just be sending and receiving bytes, not modifying those bytes.
All the bootup lines have crlf as the next line eg
UART.str(string("ZiCog v0.009 on the TriBladeProp v0.09x")) crlf UART.str(string("8 bit, parity=None, 1 stop bit, Flow control=None")) crlf
And then you just change this line here and comment out the LF if you don't want it. So it becomes one line to change which is as simple as an ifdef. (you could even add that deletion as an ifdef if required)
PRI crlf UART.tx(13) UART.tx(10)
Attached zip of code with crlf added and a photo of it running on the PockeTerm
Addit: tried re including these lines but didn't make any difference to the speed:
'<== probably can speedup by enabling this if blockno == 0 buff[0] := $C3 'force jmp to $FF00 (faster) buff := $00 buff := $FF
Post Edited (Dr_Acula) : 8/18/2009 3:36:12 AM GMT
Image Attachment :
 PICT0150.JPG 295KB (image/jpeg)This image has been viewed 31 time(s). | | | |
File Attachment : 20090817Dr_ac.zip 193KB (application/zip)This file has been downloaded 15 time(s). | | Back to Top | | |
    |  Dr_Acula Registered Member

       Date Joined Dec 2008 Total Posts : 606 | Posted 8/18/2009 5:42 AM (GMT -8) |   | That works. Looking at a common file we can work on, can you pls re-release that with the baud rate at 115k, and try the LF commented out.
I'll change those two things on my working file (and hopefully remember to change them if I upload a new package).
Then you can use the terminal you are using. (my inability to go above 38k baud speed is due to the long serial cable. 38k is more than fast enough for me!)
I must say that is is amazing watching xmodem work. Also, I know I said those 4 lines
'<== probably can speedup by enabling this if blockno == 0 buff[0] := $C3 'force jmp to $FF00 (faster) buff := $00 buff := $FF
didn't make a difference to the boot speed. They don't, but something has dramatically increased the speed of file writes when doing an xmodem file transfer.
All looking good!
So - on to the next phase. I've pondered all sorts of ways to get the bigger disk images, but keep coming back to heater's comment that it is best to keep this as a simh simulation. Use the simh standards. I was tempted at one stage earlier today to get into the cbios settings and make the floppy drives bigger, but I think heater is right. Keep the first 8 drives as 1mb, and then the next 4 as 8mb. Down the track, maybe we can get a link to the zicog on the simh site (as the N8VEM managed to do once it was stable).
Heater, I spent 4 months procrastinating building a triblade. Cluso was very patient, and he even sent me a freebie sd socket at one stage. So I know the board can be a bit daunting, but are you stuck with one particular part missing, or is the build a bit confusing? I know this might be a bit odd to hassle you like this, but I feel like a smoker who has just quit and now has gone all evangelical about it. The triblade is great!!! If you need a ram chip or something, pls let me know so I can send you one.
Was there a thought at one stage of using faster sd access code? Is this possible (it would be great if it is!) | | Back to Top | | |
        |  dMajo Italy 72

       Date Joined Apr 2008 Total Posts : 329 | Posted 8/18/2009 7:20 AM (GMT -8) |   |
Dr_Acula said...That works. Looking at a common file we can work on, can you pls re-release that with the baud rate at 115k, and try the LF commented out. I'll change those two things on my working file (and hopefully remember to change them if I upload a new package). Then you can use the terminal you are using. (my inability to go above 38k baud speed is due to the long serial cable. 38k is more than fast enough for me!) I must say that is is amazing watching xmodem work. Also, I know I said those 4 lines
'<== probably can speedup by enabling this if blockno == 0 buff[0] := $C3 'force jmp to $FF00 (faster) buff := $00 buff := $FF
didn't make a difference to the boot speed. They don't, but something has dramatically increased the speed of file writes when doing an xmodem file transfer. All looking good! So - on to the next phase. I've pondered all sorts of ways to get the bigger disk images, but keep coming back to heater's comment that it is best to keep this as a simh simulation. Use the simh standards. I was tempted at one stage earlier today to get into the cbios settings and make the floppy drives bigger, but I think heater is right. Keep the first 8 drives as 1mb, and then the next 4 as 8mb. Down the track, maybe we can get a link to the zicog on the simh site (as the N8VEM managed to do once it was stable). Heater, I spent 4 months procrastinating building a triblade. Cluso was very patient, and he even sent me a freebie sd socket at one stage. So I know the board can be a bit daunting, but are you stuck with one particular part missing, or is the build a bit confusing? I know this might be a bit odd to hassle you like this, but I feel like a smoker who has just quit and now has gone all evangelical about it. The triblade is great!!! If you need a ram chip or something, pls let me know so I can send you one. Was there a thought at one stage of using faster sd access code? Is this possible (it would be great if it is!) Try CAT5/6 ethernet cable with db9 serial connectors at the end. I have run ~75m long serial at 115k. Sometimes could be a problem with some laptops (because of the power management some models have 3/5V levels on serial port) but should always work with desktops (+12/-12V levels (in the averege))
chers | | Back to Top | | |
    |  Dr_Acula Registered Member

       Date Joined Dec 2008 Total Posts : 606 | Posted 8/18/2009 3:43 PM (GMT -8) |   | Amazing - I go to sleep for 8 hours and look at what has happened. Does the sun never set on the Zicog project?
Ok, heater, heading over to that other thread now to check out the code.
Re disk images, they are 32mb so maybe a bit impractical to post. But Cluso has a vb6 program to create them. I had to modify it a bit so it makes the files in the current directory, not the specific directory he was using (which was on drive D and my computer doesn't have a drive D). But simple enough to do.
Re "What are you guys using for terminals? Don't tell me another Prop..."
Well, yes, I guess the PockeTerm is another prop. Also Teraterm/Hyperterminal. I prefer Teraterm because it boots up slightly faster. None of these give the double line problem. Re ^C, they just go down the line as the correct ascii code eg 03. No traps or special modifications for any control characters - they just go straight through. That was one of the mods for xmodem as xmodem does not treat any bytes as special. A few months ago we had some N8VEM boards online and people were logging in from overseas using Telnet. We are probably getting close to doing that with a Zicog too. Also, all these 'standard' terminal programs have xmodem built in.
Can't wait to test out the hard disk code!
And re cat5/6 cable for serial, I'll check it out.
Addit: heater, can you pls bump the zicog thread - it has been lost in the mists of time...Post Edited (Dr_Acula) : 8/18/2009 11:59:31 PM GMT | | Back to Top | | |
 |  Cluso99 We live onboard

       Date Joined Apr 2008 Total Posts : 2276 | Posted 8/18/2009 5:09 PM (GMT -8) |   | |
Heater: Great news
Yes, please post the hard disk image. It should zip down pretty well. Is it 512Bytes per SD sector and no extra bytes (like the 137 in floppy)?
Anyway, the blank disks already done for floppies can just be copied. Nice to keep them all 32MB so that we might expand them later??? Suggest we call them HDRIVE_I.DSK, HDRIVE_J.DSK, HDRIVE_K.DSK, HDRIVE_L.DSK
Terminals. I am using (was) PropTerminal. To remove the extra LF's you should just comment out the UART.tx(10) in the crlf routine in ZiCog_demo
James: No sleep for the wicked !!! re my VB6 program - you should have seen it before I posted it (full of old crap and kludged code)
PS. Now a direct link to ZiCog & MoCog in my signature.
Links to other interesting threads:
Post Edited (Cluso99) : 8/19/2009 1:34:17 AM GMT | | Back to Top | | |
 | 848 posts in this thread. Viewing Page : | | Forum Information | Currently it is Friday, November 20, 2009 10:46 PM (GMT -8) There are a total of 393,734 posts in 55,521 threads. In the last 3 days there were 82 new threads and 700 reply posts. View Active Threads
| | Who's Online | This forum has 17687 registered members. Please welcome our newest member, mark09. 48 Guest(s), 1 Registered Member(s) are currently online. Details Rick Brooks |
Forum powered by dotNetBB v2.42EC SP2.02 dotNetBB © 2000-2009 |
|
|