PhiPi, potatohead, it is this fact too that came into fruition, because the prop IO isn't hardware defined, I just used the demo board, as we didn't have a board already done, and used P0-P6 for 7 serial RX ports which were all linked in from P7 which was a temporary TX port writing data, to all ports, at same time to show/test full load levels.
so the board layour was just a demo board with wires, that was it, to fully test 5+ cogs, until Coley built the board, otherwise it would have been writing blindly, until the board was made, again showing the versitility of the prop.
I've just been told, by Coley, that he tested it in the office today, and it worked! so it's going to be fitted on site tomorrow! happy days for the prop!
To be honest it's a bit rough n ready but it's use is only temporary until we find the problems with the DVR Hardware
So the circuit you see is a Prop coupled with 5 ST232CN RS232 Driver IC's some LED's for Debug (So I can see what's happening) and bottom left is an FTDI UB232 PCB that I had in my parts box. Whole thing will be contained in a Polycarb enclosure, I should add that the US232 Board can also provide power as well as the host PC interface. We do also have 5V input and RS232 Level TX output if required.
@Bill, the issues I had with Tim's quad port driver code from the obex were getting multiple copies to work, once I had that sorted and working I ran into the real problem, 64 byte buffer..... I needed a lot more, when these DVR's start up the Linux kernel transmits a lot of data that the original code just couldn't keep up with. Once I'd talked it through with Baggers we decided it was easier and probably a lot faster to write a bespoke driver.
What can I say other than it just works!
And if it helps me find the issues with the DVR's it will save me a lot of work and heartache.......
evanh, you'd be surprised. I have a 16-port card on my work box and I don't think I could function without it. Right now I'm using about six of them for one project, and that doesn't count the propeller board which is on a propplug. Two are bridged with a null modem because I have a PC program that expects to talk to another device which I don't have, so it's talking to another PC program emulating that device. When developing something like an unattended truck scale which has multiple terminals and all sorts of sensors and I/O devices the usage can add up fast.
So Leon, if the other woman is so good... did I say that out loud?
The other chip.
Why waste your time kicking up dust with a bunch of Propeller Heads?
Both of them are interesting devices with unique features. As with any MCU, one selects the best device for a particular application. I've even got a little system which uses both chips, but I'm not sure if it is all that useful.
What a great project! 1K buffers on a microcontroller is really aggressive. I'm glad to hear that the problem with the 4-port serial object by Tim was uncertainty about instatiating multiple copies. I've plans to use Tim's 4 port object in an upcoming prototype.
Here is a pic of a board I designed in 1990. It can have up to 16 serial ports on a pcb and was designed to plug into the bus of an ICL System 25. One of my customers had 10 of my pcbs in his S25 allowing for a total of 140 remote terminals (PC's as video emulators and Dec LA120 printers) to be connected via leased lines and Citec Statistical Multiplexers at any one time supporting over 300 users throughout Australia.
The pcb uses a Xilinx FPGA for the main interface to the ICL bus which I programmed. It has 2 processor chips, both Zilog Z8 (Z8681 Romless). The first Z8 interfaces to the FPGA and the second Z8 controls the 16 serial (RS232) ports using 8 Zilog SCCs (dual serial controllers in async mode). The Z8s communicate via a high speed dual port FIFO. You can see the row of 1488s and 1489s. An RJ45 was used to connect to the Scitec Stat Muxes.
As I did not have a full bus spec, I programmed the FPGA to snoop the bus, then reprogrammed it to emulate a standard I/O pcb. This was the first and only rev of the pcb and there were 2 track cuts and 2 wires required. Of course that was the advantage of an FPGA. ICL did not have an async serial pcb.
If I were to design it today I would use an FPGA, 2 props and RS232 Drivers and Receivers (probably MAX232s).
This could also be done by using 6 copies of the FullDuplexSerial object (my modified version for various buffer sizes up to 256 bytes) and the 7th cog could do the processing.
What a great project! 1K buffers on a microcontroller is really aggressive. I'm glad to hear that the problem with the 4-port serial object by Tim was uncertainty about instatiating multiple copies. I've plans to use Tim's 4 port object in an upcoming prototype.
The most I have tested was 3 copies of the object, 1 copy running 1 port and 3 copies running 3 ports each. But I dont see a reason that more ports can't be used.
Hi All, just to give you an update, the 10 to 1 serial port merger was installed on site, and worked, and has even helped find the issue that was causing the fault
The cure isn't done yet, but at least now they have sufficient info to know what and where it is.
... and then they brush you off cos it's a chip design flaw with no fix other than reboot, and due to lack of demand there is no revision. Although they never actually admit any of that and keep selling the product anyway.
Comments
And the proto hardware can be done using simple breadboard type stuff, because all the nasty signals are in the chip.
Bet Graham (Coley) could get his PCB done in a day.
so the board layour was just a demo board with wires, that was it, to fully test 5+ cogs, until Coley built the board, otherwise it would have been writing blindly, until the board was made, again showing the versitility of the prop.
I've just been told, by Coley, that he tested it in the office today, and it worked! so it's going to be fitted on site tomorrow! happy days for the prop!
To be honest it's a bit rough n ready but it's use is only temporary until we find the problems with the DVR Hardware
So the circuit you see is a Prop coupled with 5 ST232CN RS232 Driver IC's some LED's for Debug (So I can see what's happening) and bottom left is an FTDI UB232 PCB that I had in my parts box. Whole thing will be contained in a Polycarb enclosure, I should add that the US232 Board can also provide power as well as the host PC interface. We do also have 5V input and RS232 Level TX output if required.
@Bill, the issues I had with Tim's quad port driver code from the obex were getting multiple copies to work, once I had that sorted and working I ran into the real problem, 64 byte buffer..... I needed a lot more, when these DVR's start up the Linux kernel transmits a lot of data that the original code just couldn't keep up with. Once I'd talked it through with Baggers we decided it was easier and probably a lot faster to write a bespoke driver.
What can I say other than it just works!
And if it helps me find the issues with the DVR's it will save me a lot of work and heartache.......
Regards,
Coley
Would you post the bottom?
Massimo
Regards,
Coley
The other chip.
Why waste your time kicking up dust with a bunch of Propeller Heads?
The board is impressive. Thanks for showing how it should be done and the possibilities of a humble perf board in skilled hands..
The project is a masterpiece, both software and hardware.
Massimo
It's not jusat about how versatile the Propeller is and also how the design cycle is shortened by using it but also it was a pleasure to work with.
Lets leave the discussions about that please.....
I'd be interested to hear of other multi port serial concentrators like the one localroger mentioned.
Regards,
Coley
It was a labour of love lol
The code needs tidying up a bit so I'll have a chat with Baggers today about it.
Regards,
Coley
The pcb uses a Xilinx FPGA for the main interface to the ICL bus which I programmed. It has 2 processor chips, both Zilog Z8 (Z8681 Romless). The first Z8 interfaces to the FPGA and the second Z8 controls the 16 serial (RS232) ports using 8 Zilog SCCs (dual serial controllers in async mode). The Z8s communicate via a high speed dual port FIFO. You can see the row of 1488s and 1489s. An RJ45 was used to connect to the Scitec Stat Muxes.
As I did not have a full bus spec, I programmed the FPGA to snoop the bus, then reprogrammed it to emulate a standard I/O pcb. This was the first and only rev of the pcb and there were 2 track cuts and 2 wires required. Of course that was the advantage of an FPGA. ICL did not have an async serial pcb.
If I were to design it today I would use an FPGA, 2 props and RS232 Drivers and Receivers (probably MAX232s).
Of course, your method is better :smilewinkgrin:
The most I have tested was 3 copies of the object, 1 copy running 1 port and 3 copies running 3 ports each. But I dont see a reason that more ports can't be used.
The cure isn't done yet, but at least now they have sufficient info to know what and where it is.
BTW I posted the pic to the above thread.
It's certainly given me enough information to go back to the manufacturer and say 'I'd have a look there if I were you....'
Regards,
Coley