1、普通串口卡的限制
	一般的串口卡可以提供8个以下的串口在一片卡上面，当我们需要扩充串口数时，只要添加额外的卡即可。然而我们每添加一块卡就需要一个PCI插槽及一个IRQ需求。如果PCI插槽数不足时，我们就无法顺利添加端口，如果IRQ与别人冲突，则可能造成我们工作有问题（因为PCI的IRQ*是由主板的BIOS*，虽然我们的串口卡可以共享IRQ，但是有些卡却不能共享IRQ。有时主板BIOS就是*给串口卡的IRQ与不能共享IRQ的卡相同IRQ）。所以我们必须思考一个更简单而方便的解决方案。
	2、可扩充式串口卡
	针对普通串口卡的限制，我们希望在一个PCI插槽上可以达到串口扩充的目的，如此则可以不受PCI插槽数的限制也没有IRQ与别人冲突的问题。
	首先，我们利用一片PCI卡插在PCI插槽上与PC的主CPU进行沟通，然后我们利用串口扩展盒与此卡连接，任何时刻我们需要增加串口时，只要添加扩展盒即可。于是我们在增加串口后，PC的主CPU并未发觉任何硬件上的改变，亦即PCI卡数未增加IRQ的指派未改变。所以不会有硬件上的冲突会发生，而在软件上面，我们的驱动程序将会发现这些新出现的串口（当扩展盒添加上去后的*次运转时）而给予适当的处理。
	3、需要CPU吗
	当我们利用扩充盒来添加串口时，我们发现一个IRQ所需要服务的串口增加了，如果每一个串口的中断要求增加。则PC的主CPU将频繁的被中途要求中断正常工作，于是主CPU的工作效率将急速恶化。根据中断服务程序结构不同，我们可能采用向量方式，来指到产生IRQ需求的串口，完成其工作然后离开，可是，如果有多人排队提出IRQ并等着IRQ服务，则这种向量式服务，将不断进出IRQ服务程序，效率相当差。（因为进出IRQ服务程序有一定的流程要进行，而此负担就由此串口所负责）。
	另外，我们可以使用轮询方式，当进入IRQ服务程序时，就逐一询问每一端口有否需要IRQ服务，如果有，则执行之。如果没有，则询问下一个串口，直到所有串口都被询问完毕，我们才离开IRQ服务程序。我们发现此方式，主要时间是浪费在未提出IRQ需求的串口上面。亦即向量式IRQ处理，一定可以为真正提出IRQ的人服务，但是进出IRQ服务程序的负担，就全部由此串口负责，而在轮询方式，则由所有提出IRQ的串口，来共同分担进出IRQ的负担，但我们却必须承担询问到未提出IRQ需求之串口的白工。基本上无论是向量式或轮询式IRQ处理方式，对于由串口的UART直接提出IRQ方式，我们都无法预估其中断提出时间，所以无法确定主CPU的工作效率。特别是串口数愈来愈多的情况下,主CPU的工作效率愈来愈恶化而不可预期,因此,我们必须另外想办法解决，对于内建本地CPU的串口卡而言，所有串口卡的数据送收工作都由本地CPU负责，于是PC的主CPU并不需要受到串口卡的IRQ影响（亦即串口卡并不需要IRQ在 PCI插槽上）。通常我们会采用系统时钟，定时通知主CPU对于串口卡的双口内存，进行数据交换工作，于是主CPU的效率是可预期的，因为时钟中断的周期我们可知道，而每次中断所要进行服务程序之时间是可推估的。可是，这个方法有一个缺点在于实时性，由于主CPU是利用系统时钟进行数据交换，所以，真正串口的数据送收动作，都必须等到固定时钟中断产生时才能进行交换，所以如果要求实时性高的工作，就不适合采用内建本地CPU的卡。
	例如我们的串口卡如果采用100Hz（或10ms周期）系统时钟来进行数据交换，对于UART所产生的状态变化，以前会立刻产生IRQ来通知主CPU进行处理，可以达到实时性反应。现在则是通知本地CPU，再反映到双口内存（dual port RAM）上，于是要等到主CPU来进行交换时（平均等待一半的周期时间约5ms）才可以发现此状态变化而进行反应。
	4、结论
	由以上我们可以发现,不带本地CPU的串口卡，适合需要实时反应的应用，而带本地CPU的串口卡，适合系统效率高且可预测的应用，可是当串口数多的时候，不带本地CPU的卡，对于系统影响效率影响*大。如果我们可以设计一系统令需要实时反应的工作，由本地CPU立即反应，而一般的数据送收，则由主CPU定期进行双口内存数据交换工作。于是我们可以兼顾效率及实时反应的需求，可是每个人对于实时反应的需求并不一定，因此我们无法拥有一标准化的产品来满足上述需求。
	于是，我们推出一款IOP3927U卡，可供使用者自行来开发软件。任何一个系统集成商，可以根据其特殊的应用环境需求，进行软件编程来满足其需求，采用IOP3927U卡，一方面只要一个PCI插槽，就可以随时扩充到64个串口，而且不必使用PCI的IRQ资源，拥有133MHz CPU，可程序空间高达512K byte，本地内存高达16M byte，软件编程可以发挥的空间相当大。