标签: clock

我不能直接提供完整的代码，因为这取决于你的具体硬件配置和你的项目需求。但是，我可以给你一些大概的代码框架和基本步骤。 首先，你需要设置你的定时器。在8051单片机中，你可以使用Timer0或Timer1。假设我们使用Timer0。 c 复制代码 void Timer0_Init () { TMOD = 0x01 ; // 设置Timer0为模式1 (16位) TH0 = 0xFC ; // 初始值，根据你的需要来设置 TL0 = 0x18 ; // 初始值，根据你的需要来设置 ET0 = 1 ; // 使能Timer0中断 TR0 = 1 ; // 启动Timer0 } 然后，你需要实现RTCP的控制。你可以在Timer0的中断服务程序中实现这个功能。假设你有一个函数UpdateRTC()来更新RTC。 c 复制代码 void Timer0_ISR () interrupt 1 { // Timer0中断服务程序 TH0 = 0xFC ; // 重新加载初始值 TL0 = 0x18 ; // 重新加载初始值 UpdateRTC(); // 更新RTC } 然后，对于电机控制，你可能需要使用PWM。假设你有一个函数ControlMotor()来控制电机。你可能需要在主循环或者另一个定时器中断中调用这个函数。 c 复制代码 void Main () { Timer0_Init(); // 初始化Timer0 while ( 1 ) { ControlMotor(); // 控制电机 // 其他代码... } } 注意这只是一个大概的示例，具体的代码取决于你的硬件配置和项目需求。你需要对你的硬件有深入的了解，并且对8051单片机的编程有一定的经验。

要使用51单片机实现五轴联动的RTCP（Real-Time Clock and Calendar）功能，首先你需要为每一个轴设计一个独立的定时器，并且为RTCP设计一个独立的定时器。此外，你还需要使用一个实时时钟（RTC）模块来获取当前的时间和日期。以下是一个简单的步骤指南： 硬件配置 ： 51单片机（如Intel 8051或其相容的微控制器）：负责处理和控制整个系统。 五轴电机驱动器：用于驱动五轴电机。 RTC模块：如DS1307或DS3231，用于获取当前的时间和日期。你需要使用模块的I2C接口与单片机通信。 编程 ： 设置定时器 ：为每个轴设置一个独立的定时器，并为RTCP功能设置一个独立的定时器。你可以使用8051单片机的Timer0或Timer1。 实现RTCP控制 ：当RTCP定时器溢出时，更新当前的时间和日期，并通过I2C接口写入RTC模块。 实现电机控制 ：当每个轴的定时器溢出时，改变电机的旋转角度或速度。你可能需要使用PWM（脉宽调制）来控制电机的速度。 调试 ： 通过串口或其他的调试工具来检查程序是否正常运行。 确保每个轴的电机在预定的时间点按预期旋转。 确保RTCP功能正常工作，并且时间显示准确。 优化 ： 根据需要调整定时器的溢出频率以优化性能。 如果需要，为电机控制算法添加更复杂的特性，如PID（比例-积分-微分）控制。 固件更新 ： 当系统运行稳定后，你可以将最新的固件代码烧录到单片机中。 注意：对于I2C通信和定时器的使用，你需要对8051单片机的相关特性有一定的了解。此外，五轴联动的RTCP功能可能需要复杂的算法和精确的控制，所以你可能需要深入学习相关的知识和技术。

Ever since I’ve known Max, I have figured that there is no keeping up with him or even beating him -- that is until now when he challenged me to a design-off contest  over who could build the best pixel ring clock . So I thought to give it a whirl.   This is a work in progress. Comments are welcome.   Hardware I thought my clock’s display should be quite active when running, understand what I say to it, have capacitive-sense touch buttons that also would know when it was touched anywhere, and have a speech and audio playback synthesizer to complete the communication-to-human part of the beast. Lastly and obviously, no clock would be complete without a time-keeping mechanism, so a clock/calendar is included.   I ended up with the following for hardware and will give my reasoning: Arduino Leonardo . The UNO and Mega have a USB to TTL chip that connects to the hardware serial port, which ties up the hardware serial port that I want to use to talk to the voice recognition system. The alternative is using the software serial interface, which might work if changed to be interrupt driven – however, my clock is going to be too busy to have to take on this overhead. Available from SparkFun , the Leonardo has the USB built into the processor, which frees up the hardware serial port. It also makes the ‘bridge’ function to connect the PC to the voice system simple and easier to share with the debug-serial I/O console built into the compiler environment, not to mention that it also runs 115k baud with minimal overhead.   ChronoDot clock/calendar , available from Adafruit , was almost a no-brainer. It interfaces to the I2C wire bus, is very low power, and keeps outstandingly accurate time. Also it comes with the obvious other things required, such as the button-cell battery, for example.   EasyVR shield V3 , from Veear and available from Sparkfun . This little beauty is both a speech recognition engine and a sound player in one. Having extensive support and library, this board-shield offloads the Arduino from what would otherwise be an impossible task for the 16 MHz memory-limited processor. The hardware can be run in standalone PC mode, as well as ride on the Arduino, to make it easier to develop an operating environment. Its separate commander software that runs on the PC makes the job of teaching the device words (speaker dependent) and then downloading them a breeze. For Arduino code development, there are very good examples to use. Lastly, for speaker-independent additional-word supplements, a software tool can be purchased.   Groove Q-touch sensor , from EpicTinker , has the following features: Shares the I2C bus nicely, has 7 separate very noise-tolerant capacitive inputs, self calibrates, and is very small itself. For debug, three of the buttons can optionally be used already configured on the board’s underside.   The concentric, three pixel rings , which are 60 pixels for the outside-most ring, 24-pixel ring for the middle, and a 12-ring for the inside-most ring, make a tasty clock. This makes the minutes and seconds share the outside ring, the 24-ring for hours when in the 24-hour mode, and lastly the 12-ring to display the hours in 12-hour mode. Having the extra unused ring depending on the mode, allows it to be used for AM/PM indication, and status display of other clock functions such as voice, for example.   Power supply . An external power supply is required, since all-white/all-on and fully-bright pixels draw considerable amps. I chose the Recom Power RAC60-05S/OF  from Digi-key . It has room to grow at 10 amps, is relatively small, and is only about $21. One down-side note to mention however, is that whenever the supply draws more than a few amps, it ‘sings’ a bit, which could get a tad annoying if it turns out to be loud enough after mounting it inside the clock.   To get started: I hooked everything up as mentioned, and used digital pins 4, 7, and 8 for the 60-ring, 24-ring, and 12-ring respectively. I left the pullup resistors for the I2C bus installed on the Q-touch, because I changed the I2C library away from using the standard WIRE library, and the replacement didn’t enable the internal pullups. I will discuss this library replacement later.   Software At first it seemed logical to try to use everything stock and standard, as supplied by the manufacturers of each of the respective pieces, to save time and keep it simple, clean, and understandable. However, it quickly became apparent that to have a dynamic real-time display, something like an interrupt-driven task manager would make things work better. The manager would not need to be a full up pre-emptive multitasker operating system, but could be a single-level interrupting scheduler. Hunting around for exactly that on the web, I landed on something that was an outstanding multitasker  but wasn’t interrupt driven. To overcome this problem, I thought to give it a try as a quick poll in loop(), then add the interrupts as necessary. To its credit, this library is very full featured, having things like run once, run every time on a time, run a certain number of times, oscillate, pulse, stop, update, and find free event index. I found the   t.every( xMilliseconds, routineName, number-of-times)   quite useful, where it calls the routinenamed  every x milliseconds  for number-of-times and then stops.   All tasks are sampled to see if the timers are to be triggered for calls, each time the t.update() is run. As nice as this was to use, it had the down-side that PWM, millis() and other internal timer delays, as well as other timer library functions were not useable. So rather than expend energy to add interrupts, I thought to look for another solution that was already interrupt-driven, which led me to LeOS (little embedded Operating System) . While this was not as full featured, and lacked the run number-of-times item I wanted, it did have everything else, including interrupts, task restart, task change, etc. Much later on I would also discover, to my chagrin, that this scheduler was not compatible with the NeoPixel and WIRE I2C libraries, causing me to hunt/replace these with something that would work. To these ends I first found the Neopixel replacement, light_WS2812  which worked well enough, even though it was a very basic engine. Next I found the replacement for the I2C  which allowed to disable interrupts, set speed, and other nice things, but which mainly was compatible with LeOS. I did notice that this library didn’t enable the internal pullups, so I went to make sure there were external ones provided on at least one of the boards connected to the bus, rather than spend the time to find the software fix. After substituting appropriately this softI2C master to the function calls to the ChronoDot, I thought to tackle the touch controller, which I had working originally using the Wire library, prior to integrating LeOS. This was not to be.   At this point, I had a beautifully spinning and whirring display, eloquently running, voice recognition accepting a trigger-speech command, and responding with speaking the current time. However, I couldn’t get the I2C library swapped out for the WIRE library on the calls to the touch controller. It seems that the trouble lies in the compiler’s insistence that the I2C be declared in proper scope inside the touch controller’s library, where the I2C is itself a library. All the techniques I usually use to resolve such issues, such as pulling the code out of the library up to the top-level sketch, for example, have failed.   Some of you who read this, may have discovered a few OTHER quirks with the otherwise nice compiler. As an example that I ran across on this project, I had a function called serialIN(), which worked just fine as the code steadily grew, but then suddenly the compiler began complaining that serialIN was not defined in this scope. I worked for hours trying to fix this, until I accidentally renamed it to iserialIN(), which made the compiler happy! Now mind you, the serialIN was not a keyword (Serial.xxx with the capitol ‘S’ is a keyword, as it would indicate this by a change of text color). There were no constructors, classes or anything else that I could find, having been added, to cause the error. Not having much more patience to bear, I left it like this and decided to move on.   To solve this last seemingly insurmountable problem (to me) with the I2C library replacement for the touch controller, I welcome any ‘C’ guru to take a look at this and offer a suggestion/fix. I will supply the appropriate code snippets for all who brave forward.   iframe width="400" height="360" src="https://www.youtube.com/embed/Ov1ZI26uTFI?feature=player_embedded" frameborder="0" allowfullscreen/iframe   By the way, I have included a video of what I have so far, for you who are interested to drool over, or cry, as appropriate.   Thanks in advance!   Ivan Cowie

The concept of time is simple yet complex. In its simplest form, it's the counting of a regular, repeating pattern. On the opposite end, we would have to turn to Einstein. Thankfully, this story resides on the simple side. You see, before the advent of the real-time clock, electrical engineers scurried hither and yon in search of ways to calculate time accurately in their circuits. One very convenient source of a regular, repeating pattern was the 60Hz line frequency coming from the wall outlet. It was a very stable source in the US, and so long as it was stable, your machine would work fine. But if ever a crack appeared in the stability of the 60Hz source, the entire machine could be compromised. This was the case on the idle Tuesday morning our story begins. Giant pillars of white smoke soared high in the air from the large, concrete stacks that reached up into the clear blue sky. It was easy to find parking in the large lot when I arrived at the paper-making plant nestled on the outskirts of Richmond, Va. The smell of sulphur was thick, and the rumble of the large trucks carrying trees filled the air as they entered the plant. It was a short walk to the visitor's desk, where I was met by the man who had called me a few days earlier. "Damn thing doesn't work," he had said. I get that a lot. He led me to the not-working microwave solids analyser. This simple machine consists of a microwave, a balance, and an embedded computer. It heats a sample to remove all the moisture, and the computer uses the difference in weight to calculate the per cent moisture in the sample. I placed a test sample in the machine and pressed the start button. Immediately, problems were apparent. On the grey scale display, the system clock was counting down the time. The problem was it was counting way too fast. It had counted down more than two minutes, but my gut, verified by a clock on the cinderblock wall, told me less than a minute had gone by. I pressed the stop button, and another problem revealed itself. Instead of the usual single beep, I got three. It acted as if I had pressed the button a couple of times. It appeared I had debouncing as well as timing issues. It was then that I clued in on the A/C line and took a closer look. I was in for a shock.   This video and the scope screen captures above were taken directly from the 120V wall socket via a 10-to-1 stepdown wall-wart transformer using a 10x probe. As you can see, the signal is very dirty. I concluded the source of the noise was probably from one of the large paper rolling machines running elsewhere in the plant. I had identified the problem. But I still did not know how the dirty signal was causing the timing and debouncing issues and how to fix them. I had to solve a before I could even begin to approach how to fix the issues. Like any good technician, I dug into the schematic. It wasn't long until I discovered a small circuit that appeared to be converting the A/C line frequency into a 5V clock signal. The output was routed to one of the pins of the 80188 Intel processor.   I knew I had to get a scope on pin 6 of the opto-coupler (U7) to see if the noise on the A/C line was getting through.     So the noise from the A/C line was getting through the opto-coupler in the form of problematic leading and trailing edges. It was so bad that the scope had a hard time locking on to the frequency, as seen above. I did not have access to firmware, but my theory was sound. I believed that the 80188 computer was using this very signal to generate its definition of time—every 120 leading-edge counts was equal to one second in the firmware. And in this case, all the spikes on the leading edges were being counted, as well. This would cause the system's internal clock to run too fast. Also, I knew the switch debouncing was done in firmware. This code is dependent on accurate delay times. If the system clock were running too fast, that would mean the delay times would be too short, and the debouncing code would not work properly. Yessss! I had found the source of the problem, theoretically at least. Now, how to fix it. Long story short, I concluded that it would be easiest to simply replace the signal. I would remove the opto-coupler IC and use a microcontroller to generate a clean signal and route it to the processor.   Above is the schematic. (I realised I had taken the scope readings in the previous images off U6 instead of U7. U7 produces a 10 per cent duty cycle 120Hz signal, as opposed to 50 per cent.) Below is the code to generate the 10 per cent duty cycle 120Hz signal. while (true) { { output_high(PIN_A2); delay_us(833); output_low(PIN_A2); delay_us(7600); } } I made a board using toner transfer. I removed the opto-coupler, and used the empty socket to supply power to my board and route the clean signal to the processor.     I installed it in the instrument the next day, and everything worked perfectly. The timing was accurate, and no more debouncing issues. I had the board done from a board house and installed it a few weeks later. The instrument has been working well ever since.     This article was submitted by Will Sweatman, a field engineer, as part of Frankenstein's Fix, a design contest hosted by EE Times (US).

  个人觉得当入手一款新单片机时最先需要明白的是它的时钟部分，因为时钟就是单片机的心脏，不把心脏的具体过程搞明白，也就没法去正确的操作其外设部分。   Kinetis L系列的单片机时钟部分比较复杂，原因在于它有许多可选的时钟源与众多的时钟模式以及产生时钟的方式。它的时钟源和外设之间的关系主要是系统先将时钟产生好然后外设根据需要进行选择。它的主要时钟源为内部的Multipurpose Clock Generator(MCG)和System Oscillator。MCG主要由锁相环和锁频环构成通过其内部的参考时钟或外部的参考时钟产生相应的时钟，此模块产生的时钟源较多。System OSC则主要是通过XTAL和EXTAL引脚连接的外部晶振或共鸣器为MCU产生系统时钟，System OSC则主要能通过MCG对其进行控制如选择OSC的频率范围，增益控制以及外部是晶振还是外部时钟等。与时钟相关设置有较多的模块并且相互之间又具有一定的联系，主要用到的模块是MCG，SIM，OSC。MCG的主要功能是选择系统时钟源，SIM主要功能是为系统设置时钟分频数和相关外设的时钟门控选择。大部分的外设都是具有很多的可选时钟源，必须要通过SIM模块将其时钟门控选择打开，否则在不打开其时钟门控的情况下则会出现内核硬件故障错误。同样在对MCU相关时钟进行设置编程时一定要注意其数据手册上时钟输出的最大限制，一旦你超过其限值，可能出现无法预料的错误，如任何总线访问一个没有开启时钟的外设将产生一个终止错误！   下面根据数据手册对MCG模块进行简单的翻译和理解： MCG主要由两部分组成一个是PLL,另一个FLL。FLL能通过外部或内部的参考时钟控制而PLL只能通过外部的参考时钟进行配置。MCG能选择PLL或FLL输出来作为系统时钟或者是选择内部或外部的参考时钟来作为系统时钟源。MCG模块结合一个晶体振荡器运行，它允许外部晶振，陶瓷振荡器，或其它的外部时钟源来作为其本身的参考时钟。MCG具有九种工作模式分别为FEI,FEE,FBI,FBE,PBE,PEE,BLPI,BLPE,STOP，如此多的工作模式同样就加大了操作的难度，但为芯片运行于低功耗方式下也提供了更多的选择。MCG具有很多的寄存器，在对它们进行操作下需要注意所有的寄存器只有在管理模式下才能写，在用户模式下写这些寄存器会导致总线错误，读操作则能在任何模式下进行。MCG的操作在IAR中提供的启动代码里已经将其进行了正确的设置与初始化可以直接进行使用，但是如果个人想重新编写的话，确实具有一定的工作量。   下面对SIM模块进行简单的翻译和理解： SIM的功能具体要根据其寄存器进行，它的寄存器很多，但功能描述上还算清晰。它的主要特点为： 系统时钟控制 系统时钟分频值 时钟门控结构 ERCLK32K时钟选择 USB时钟选择 UART和TPM时钟选择 FLASH和系统RAM大小配置 USB稳压器配置 TPM外部时钟和输入捕获配置 UART接收/发送源选择/配置 同样SIM的寄存器也只有在管理模式下才能进行写操作，否则会导致总线错误。   下面对OSC进行简单描述： OSC是一个晶体振荡器。结合外部晶体和共鸣器，为MCU产生参考时钟。它的关键特点为： 支持32K晶振（小范围模式） 电压和频率滤波器为了保证频率的稳定性 选择外部输入时钟信号直接从EXTAL绕过 一个时钟为了MCU时钟系统 两个时钟为了芯片外设能工作在停止模式 在使用外部晶振时一定要注意其和外部器件的连接方式，否则很可能出现无法起振或振荡器不稳定的情况。同样OSC也具有多种工作模式，也主要是为了MCU的低功耗运行吧！   Kinetis L的时钟部分比较复杂，这同样也成为了它的一个特色，据说，它的时钟部分和TI的很类似，不知道是不是相互借鉴。还是有很多地方需要总结，由于个人暂时只用到了这些，目前就写这么多吧