能将PGD/PGC引脚用作调试UART

如果你必须移动（或存储）大量的数据：16位，没有分段RAM，我会使用PIC24…否则，PIC18可以是好的，尤其是新的。时钟是可以比较的。BTW：你选择的PIC24是一个相当旧的（我用302个广泛，所有好）：也许你可以找到一个更新的（更快的），可能更小…



      以下为原文

    I'd use a PIC24 if you have to move (or store) some large quantities of data: 16bits, no segmented RAM...
 
Otherwise, the PIC18 can be as good, especially the new ones. Clocks will be comparable.
 
BTW: that PIC24 you chose is a rather old one (I am using 302 extensively, all good): maybe you can find a newer (and faster one), possibly smaller...

您好，如果PIC18LF45 K40可用于您的目的，它可能是最好的候选人，直到PIC18LF45 K42变为可用。每一个PIC都有勘误表，我认为PIC18LF45 K40的那些似乎没有太大的问题（大多数都有解决方案）。从SPI速度的观点来看，这不应该是个问题。



      以下为原文

    Hi,
If PIC18LF45K40 is usable for your purpose, it is probably the best candidate until the PIC18LF45K42 becomes available. Every PIC has errata and I think the ones from  PIC18LF45K40 do not seem to be too problematic (most have workarounds). 
From SPI speed viewpoint it should not be an issue.
Regards

5兆赫从SPI可能是征税，但这一切取决于主人正在做什么。如果主机想要接收不间断的东西，则只有200 ns才能提供新的字节。所以，你可以忘记使用MSSP的所有图片。您将需要一个PIC24与SPI模块，最好是用DMA。如果主人会停顿，情况可能会不同。如果你可以用更合理的东西来代替奴隶SPI，比如UART，大多数小图片都能做到这一点。



      以下为原文

    5 MHz Slave SPI might be taxing, but it all depends on what master is doing. If the master wants to receive something non-stop, you have only 200 ns to supply a new byte. So, you can forget all the PICs that use MSSP. You will need a PIC24 with an SPI module, and preferably with DMA. If the master makes pauses, the situation may be different.
 
If you can replace slave SPI with something more reasonable, such as UART, most small PICs will be able to do this.
 
 

谢谢你的回复。我有点担心K40从我在论坛上看到的所有问题。我知道PIC24一般比PIC18要好，但我想我在PIC18公司做过足够的PIC18工作，感觉很舒服。如果我转到一个UART接口，那么我很可能会使用PIC16。新的是非常好的。我知道这是冗长的，但这里有一个更详细的，如果你有兴趣。我们有很多设计与VixTe7或Zynq FPGAs做信号处理与非易失性IGLO FPGA做了大量的硬件接口-包括阅读ADCs和传感器，电源MON控制和排序，并控制所有的时钟发生器和RF硬件。IGLO没有内置的振荡器，所以有一个运行IGLO，而其他一切都关闭了。这些设计已经被难以置信地挤满了多达34层的板，有盲孔、受控深度钻、回程钻。一种新的设计有一半的硬件在不到一半的空间，ZYNQ将做RF硬件接口，所以我想把PIC投入电源控制，Mon。监测、测序、温度和电流传感器。Zynq（和DDR4和LPDRD4）有一组功率轨，需要对PUPUP /DOWN -0.85 V 0.9V 1.9V 1.2V 1.8V 2.5V 3.3V进行排序，并且分别有多个0.85 V和1.2V轨分别进行排序。0.85伏电源为30A（预期为2A）。计划中的下一个设计将所有这些都放在1.6x5的板上。所有传导冷却。你知道我为什么要拍摄小包装。FPGAs用30MHz的SPI控制了所有这些老产品的IGLO。基本上，它是一个32位寄存器接口，具有8B地址/32字节数据写入，以及8B ADDR/8位虚拟数据/32 B读取数据。这并不一定是很多流量，但我正在考虑最小化FPGA级别的变化。然而，对于这个新产品，没有很多数据写入PIC，只是传感器数据的数据读取。也许是一个权力下放的命令。一个UART接口可能会让PIC更清楚地显示状态信息，而FPGA只是被动地吸收它。也许软件/固件的家伙会更喜欢这个。没有真正考虑过。在SPI时序文档中有一些有趣的差异，我不确定在一些数据表中应该相信什么。注意，我在这里专门处理SPI从属操作。大多数设备在1或1.25个+2030纳秒时指定时钟高和低，所以SC。LK永远不会像指令周期的一半那么快。因为它只是一个移位寄存器，我不知道背景中发生了什么，需要这样一个缓慢的SCLK。PIC18F45 K22数据表是不同的-它只是说25ns时钟高，30ns时钟低。然而，我不相信，因为方块图与所有其他PIC18相同。PIC24F32 KA304系列也不同，它特别指出SCLK最小周期为100NS。我可以相信这一点，因为8字节FIFO意味着软件不必跟上输入数据（至少是短脉冲）。这就是为什么我特别选择KA304，即使它是旧的和更昂贵的。我看的所有其他PIC24都有XC*++Y用于SCLK高和低（或者它们需要额外的时间在字节之间），即使它们也有FIFO（在很多情况下）。Slave操作是有问题的，因为PIC软件必须解释第一个字节，如果它是一个读取，得到请求的数据并且是ST。在发送缓冲器中用第三字节来填充它。在最大SCLK速度，这不是很多指令周期。



      以下为原文

    Thanks for the replies. I was a little worried about the K40 from all the issues I've seen in the forums. I know the PIC24 in general is better than the PIC18, but I guess I've done enough PIC18 work at previous companies to feel comfortable with it. If I shift to a UART interface, then I could very likely stick with a PIC16. The new ones are really quite nice.
 
I know this is wordy but here's a little more detail if you're interested.
 
We have a lot of designs with Virtex7 or Zynq FPGAs doing signal processing with a non-volatile Igloo FPGA doing a lot of hardware interfacing - Including reading ADCs and sensors, power monitoring and sequencing, and controlling all the clock generators and RF hardware. And the Igloo doesn't have a built in oscillator so there's one of those to run the Igloo while everything else is off. These designs are already incredibly packed with up to 34layer boards with blind vias, controlled depth drills, backdrilling.
 
A new design has half the hardware in less than half the space and the Zynq is going to do the RF hardware interfacing, so I want to put a PIC in to do the power control, monitoring, sequencing, temp and current sensors. The Zynq (and DDR4 and LPDDR4) has a bunch of power rails that need to be sequenced for powerup/down - 0.85V 0.9V 1.1V 1.2V 1.8V 2.5V 3.3V, and there are multiple 0.85V and 1.2V rails that are sequenced separately. And the 0.85V supply is 30A (23A expected). And the next design in planning puts all that on a 1.6x5" board. All conduction cooled. You see why I'm shooting for small packages.
 
The FPGAs have controlled the Igloo using SPI at 30MHz for all these older products. Basically it's a 32bit register interface with 8b address/32b data writes, and 8b addr/8bit dummy data/ 32b read data. It's not necessarily a lot of traffic, but I was figuring to minimize the changes at the FPGA level.
 
For this new product, however, there's not a lot of data writes to the PIC, just data reads of sensor data. Maybe a command to power down. A UART interface may make more sense with the PIC just spewing status information and the FPGA just passively absorbing it. Perhaps the software /firmware guys will like that better. Hadn't really thought about that.
 
There are some interesting discrepancies in the SPI timing documentation, and I'm not sure what to believe in some of the datasheets.
 
Note I'm specifically dealing with SPI Slave operation here.
Most devices specify clock high and low at 1 or 1.25 Tcy + 20-30ns, so SCLK can never be as fast as half the instruction cycle. Since it's just a shift register I'm not sure what's going on in the background to require such a slow SCLK. The PIC18F45K22 datasheet is different - it just says 25ns clock high, 30ns clock low. I don't believe it, however, as the block diagram is identical to all the other pic18's.
 
The PIC24F32KA304 family is also different in that it specifically says SCLK minimum period is 100ns. I can believe this because the 8 byte fifo means that software doesn't have to keep up with incoming data (at least for short bursts).
 
This is why I specifically picked out the KA304 even though it is older and more expensive. All the other PIC24's I looked at had the X*Tcy+Y for SCLK high and low (or they require extra time in between bytes), even though they also have fifos (in many cases).
 
Slave operation is problematic as PIC software has to interpret the first byte and if it's a read, get the requested data and be stuffing it in the transmit buffer by the third byte. At max SCLK speed that's not many instruction cycles.

当然，速度对Zynq来说不是问题，所以如果你想要SPI，最好让PIC成为一个主，而Zynq是一个奴隶。PIC在做其他工作时，可以以相对较慢的速率运行SPI。如果有紧急情况，你可以放弃所有其他任务，最大限度地提高SPI速度，并将紧急信息发送给Zynq。如果你全力以赴，PIC16F1可以做8兆赫。PIC18可以做16兆赫软件明智。K40指定SPI在10 ns（25 ns最大）时的上升/下降时间，因此16 MHz应该是确定的，当然在FPGA上接收不是问题。当然，在这样的速度下，除了SPI，你不能做任何其他事情，所以只有短的爆发才会起作用。



      以下为原文

    Certainly speed is not a problem for Zynq, so if you want SPI it's better to make PIC a master and Zynq a slave. While the PIC is doing other work, you can run your SPI at a relatively slow rate. If there's an emergency, you can abandon all other tasks, increase SPI speed to the maximum and send the emergency info to Zynq. If you go all out, PIC16F1 can do 8 MHz. PIC18 can do 16 MHz software-wise. K40 specifies rise/fall times for SPI at 10 ns (25 ns max), so 16 MHz should be Ok, certainly not a problem if the receiving is done on FPGA. Of course, at such speeds you cannot do anything else except SPI, so only short bursts will work.

谢谢。我试图让软件和系统工程在一个接口上达成一致，然后我可以向前迈进。在设计中，如图中目前所捕获的（尚未开始布局），PIC将对所有ZYNQ和时钟电源进行排序并释放复位。如果检测到故障，它会反转过程。Zynq没有什么可以告诉它做的——可能关机或检索事件日志。所以大多数PIC都会发送传感器和状态数据，ZYNQ对于SPI大师来说没有多大意义。UART对我来说会更好，但它需要更多的FPGA逻辑（ZYNQ PS UART已经用完）。然而，让一群工程师谈论接口，它成为一个永无休止的哲学讨论。我认为我倾向于一个更新的PIC24（PIC24FJ64 GA705？）因为它看起来像12B ADC的性能优于除K42以外的所有8位部件。当我问销售时，K42的部分被列为“未来产品”预计将成为可用的，我被告知“在未来”D'OH



      以下为原文

    Thanks. I'm trying to get software and system engineering to agree on an interface and then I can move forward. In the design as currently captured in schematic (haven't started layout yet), the PIC will sequence all the Zynq and clock supplies and release reset. If a fault is detected, it reverses the process. There's not much the Zynq can tell it to do - maybe shutdown or retrieve an event log. So mostly the PIC sends sensor and status data, and it doesn't make much sense for the Zynq to be a SPI master for that. UART would be better to me, but it does take more FPGA logic (Zynq PS uarts are used up).
 
However, get a bunch of engineers talking about an interface and it becomes a never ending philosophical discussion.
 
I think I'm leaning toward a newer Pic24 (PIC24FJ64GA705 ?) because it looks like the 12b ADC performance is better than all 8 bit parts except the K42. When I asked sales when the K42 parts listed as "future product" were projected to become available, I was told "in the future" D'oh

只有几片，有些K42已经发行了。我已经测试过了。



      以下为原文

   
 
It's just few slices.
 



Some of K42 are already released. I have tested them.

我已经阅读了数据表的28针K42，它看起来很好，但不幸的是，我需要更多的引脚，更大的部分只是纸。在我们开始布局之前还有一段时间，所以如果在接下来的3或4周内，47 K42或57 K42会出现，我会在心跳中转换，即使布局已经开始，这个设计也会持续很长时间。我喜欢的57 K42是在48引脚6x6mm封装，但不浪费许多引脚上那些讨厌的电源和接地和N/C - 10更多的IO引脚比48引脚PIC24S。



      以下为原文

    I've read through the datasheet for the 28pin K42 and it looks great, but unfortunately I need a few more pins and the bigger parts are just paper. There's still a little time before we start layout on this, so if the 47K42 or 57K42 comes out in the next 3 or 4 weeks I'll switch over in a heartbeat, even if layout has started this design will take along time. I like that the 57K42 is in the 48pin 6x6mm package, but doesn't waste many pins on those pesky power and ground and n/c - 10 more IO pins than the 48pin PIC24s.

PIC18F46K42（40引脚）和PIC18F56K42（48引脚）现在正在生产中（64K闪光灯）。SPI是一种不同于您所习惯的野兽，但运行速度比旧部件快得多。我相信它的16MHz SPI时钟，但不引用我，检查数据表。http://www. McCHIP.COM/WWW产品/En/PIC18F46K42http://www. McCHIP.COM/WWW产品/En/PIC18F56K42MIKE



      以下为原文

     
The PIC18F46K42 (40 pin)  and PIC18F56K42 (48 pin) are now in Production (64K Flash)
 
The SPI is a different beast to what you are used to but does run much faster than older parts. I believe its up to 16MHz SPI clock, but do not quote me on that, check the data sheet.
 
http://www.microchip.com/wwwproducts/en/PIC18F46K42
 
http://www.microchip.com/wwwproducts/en/PIC18F56K42
 
 
Mike
 
 
 

好消息。我是通过参数表，而不是总是看个别的产品页，所以我错过了。谢谢更新。



      以下为原文

    Great news. I was going by the parametric table and not always looking at the individual product pages, so I missed this.
 
Thanks for the update.

不过，要小心新照片。K42家族只有初步的数据表，没有勘误表。在市场引入后几个月甚至几年都会增加对勘误表的认真录入，有时硅问题可能会显示特定应用程序的停止。将新发布的部分应用到PCB和固件RISIN成本高的项目中（您的项目肯定是）我的看法很冒险。



      以下为原文

    Be careful about new PICs, though. K42 family has only preliminary datasheet and no errata sheet avaiable. Serious entries into errata list are added even few months or year after market introduction and sometimes the silicon issues could be show stopper for specific application.
Using freshly released part into project where cost of PCB and firmware respin is high (which your project definitely is) is in my humble opinion risky.

我要和PIC24一起去。用18F，你必须购买编译器，因为免费版本是脑死亡。成熟与新的部分？你将帮助Microchip找到新部件的所有勘误表。）24F可以使用免费编译器，24F系列的调试效果更好。



      以下为原文

    I would go with the PIC24.  With the 18F you will have to buy the compiler because the free version is brain dead.
Mature vs new part?  You will be helping Microchip find all the errata of a new part.  :)
The 24F can use the free compiler.
Debugging is better on 24F series.
 

但数据表是这样的。…性感听到你的新的和未曾尝试过的。我们在我们的董事会有很多这样的问题，而且没有被频繁的咬过，但是已经发现了一些制造商的错误。当有太多的替代品时，PIC似乎不是冒险的地方。



      以下为原文

    But the data sheet is so . . . sexy
 
I hear you about new and untried. We've got a lot of that on our boards and haven't been bitten too often, but have found a few bugs for some manufacturers. It doesn't seem like a PIC is the place to take risks when there are so many alternatives.

您好，如果您想试试PIC18LF45 K42的一些样品，请PM您的地址，我们可以给您发送一些单位进行评估。请告诉我们你更喜欢哪个包裹。谢谢，McppRyRay.



      以下为原文

   


Hi mbrowning,
 
If you would like to try some samples of the PIC18LF45K42's please PM me your address and we can send you some units for your evaluation.  Please let us know which package you prefer.
 
Thanks,
 
MCHP_Ryan