Форум РадиоКот • Просмотр темы — Часики на AT89C2051
Сообщения без ответов | Активные темы
| ПРЯМО СЕЙЧАС: |
| Автор | Сообщение | ||
|---|---|---|---|
|
|
Заголовок сообщения: Часики на AT89C2051
|
||
Зарегистрирован: Пн май 27, 2019 07:28:50 Рейтинг сообщения: 0
|
Дарова!Вот приобрел часики на AT89C2051 : https://www.aliexpress.com/snapshot/0.h … 2733223555 |
||
| Вернуться наверх |
Профиль
|
||
 |
Добавлено: Вс фев 23, 2020 10:08:10 
| Реклама | |
|
|
|
|
|
otest |
Заголовок сообщения: Re: Часики на AT89C2051
|
|
Карма: 27 Рейтинг сообщения: 0
|
Добавить в цепь кварца подстроечный конденсатор |
| Вернуться наверх | |
|
| Реклама | |
|
|
|
|
|
BOB51 |
Заголовок сообщения: Re: Часики на AT89C2051
|
||
Карма: 93 Рейтинг сообщения: 0
|
Не слишком удачная конструкция. |
||
| Вернуться наверх | |||
|
|
remontitor |
Заголовок сообщения: Re: Часики на AT89C2051
|
||
Зарегистрирован: Пн май 27, 2019 07:28:50 Рейтинг сообщения: 0
|
Не слишком удачная конструкция. Ну я сомневаюсь,что такие дешевые конструкции и Китайские удачные,Славо богу работают и ладно,лиж-бы покупали |
||
| Вернуться наверх | |||
|
Прошивка то-ж ни о чем.| Реклама | |
|
|
|
|
|
BOB51 |
Заголовок сообщения: Re: Часики на AT89C2051
|
||
Карма: 93 Рейтинг сообщения: 0
|
Дешево и просто вполне можно сделать. |
||
| Вернуться наверх | |||
|
| Реклама | |
|
|
|
|
|
remontitor |
Заголовок сообщения: Re: Часики на AT89C2051
|
||
Зарегистрирован: Пн май 27, 2019 07:28:50 Рейтинг сообщения: 0
|
Модно,не модно,но ночью видно.Я собственно и купил из-за этого,что-б ночью проснулся и узнал сколько время.Только цвет зеленый или желтый желательно.Какой индикатор воткнуть? |
||
| Вернуться наверх | |||
|
|
АлександрЛ |
Заголовок сообщения: Re: Часики на AT89C2051
|
||
Карма: 186 Рейтинг сообщения: 0
|
Вот приобрел часики на AT89C2051 Смотря на сколько «забегают».. otest писал(а): Добавить в цепь кварца подстроечный конденсатор либо пробовать подобрать постоянный конденсатор — припаивая параллельно одному из конденсаторов «вокруг кварца», ну, например, конденсатор в 10~15 пФ, и потом смотреть на сколько изменился «уход».. |
||
| Вернуться наверх | |||
|
|
remontitor |
Заголовок сообщения: Re: Часики на AT89C2051
|
||
Зарегистрирован: Пн май 27, 2019 07:28:50 Рейтинг сообщения: 0
|
Так-то можно попробовать воткнуть параллеьно с каким нить кондером у кварца подстроечник.Забегает прилично,за неделю примерно 5 мин. Последний раз редактировалось remontitor Вс фев 23, 2020 16:21:32, всего редактировалось 1 раз. |
||
| Вернуться наверх | |||
|
|
АлександрЛ |
Заголовок сообщения: Re: Часики на AT89C2051
|
||
Карма: 186 Рейтинг сообщения: 0
|
Только цвет зеленый или желтый желательно.Какой индикатор воткнуть? А какой индикатор там стоит? указаны разные цоколёвки индикаторов |
||
| Вернуться наверх | |||
|
|
remontitor |
Заголовок сообщения: Re: Часики на AT89C2051
|
||
Зарегистрирован: Пн май 27, 2019 07:28:50 Рейтинг сообщения: 0
|
Я не запомнил,а разбирать не охота,слепил не разборно.В подкассетник и залепил все тонировочной пленкой.Получилось прикольно,но видимо все равно придется расклеивать или надрезать аккуратно. |
||
| Вернуться наверх | |||
|
|
1en2 |
Заголовок сообщения: Re: Часики на AT89C2051
|
|
Карма: 14 Рейтинг сообщения: 0
|
По плате похоже, что индикатор по нижней схеме, где разряды — 1,6,11,12. |
| Вернуться наверх | |
|
|
remontitor |
Заголовок сообщения: Re: Часики на AT89C2051
|
||
Зарегистрирован: Пн май 27, 2019 07:28:50 Рейтинг сообщения: 0
|
Где нарыть прошивку, «швейная машинка» есть. |
||
| Вернуться наверх | |||
|
|
BOB51 |
Заголовок сообщения: Re: Часики на AT89C2051
|
||
Карма: 93 Рейтинг сообщения: 0
|
У АТ89С2051 требуется параллельный программатор… |
||
| Вернуться наверх | |||
|
|
remontitor |
Заголовок сообщения: Re: Часики на AT89C2051
|
||
Зарегистрирован: Пн май 27, 2019 07:28:50 Рейтинг сообщения: 0
|
|||
| Вернуться наверх | |||
|
|
musor |
Заголовок сообщения: Re: Часики на AT89C2051
|
||
Карма: 115 Рейтинг сообщения: 0
|
так он для пик и епром тока….видимо тока |
||
| Вернуться наверх | |||
|
|
remontitor |
Заголовок сообщения: Re: Часики на AT89C2051
|
||
Зарегистрирован: Пн май 27, 2019 07:28:50 Рейтинг сообщения: 0
|
Нэ пойдет? |
||
| Вернуться наверх | |||
|
|
OKF |
Заголовок сообщения: Re: Часики на AT89C2051
|
|
Карма: 10 Рейтинг сообщения: 0
|
У АТ89С2051 требуется параллельный программатор… Это да. Но программатор 1:1 на 2313 решает все проблемы.) И я бы поставил часовой кварц для точности. Ну и коррекция хода не помешала бы. |
| Вернуться наверх | |
|
|
АлександрЛ |
Заголовок сообщения: Re: Часики на AT89C2051
|
||
Карма: 186 Рейтинг сообщения: 0
|
Конечно, не пойдёт.. У вас «швейная машинка» для микроконтроллеров PIC, а вам нужно для AVR.. Мало того, AT89C2051 можно шить только «параллельным» программатором, самым доступным из которых является, вроде как «TL866» программатор — https://aliexpress.ru/item/32666449085. … web201603_ зы.. И кто вам прошивку переписывать будет? |
||
| Вернуться наверх | |||
|
ардуину, модуль часов и индикатор- и сами напишите то, что вам надо.. 
|
BOB51 |
Заголовок сообщения: Re: Часики на AT89C2051
|
||
Карма: 93 Рейтинг сообщения: 0
|
Ёсть и «любительский вариант» Последний раз редактировалось BOB51 Пн фев 24, 2020 12:48:30, всего редактировалось 1 раз. |
||
| Вернуться наверх | |||
|
|
otest |
Заголовок сообщения: Re: Часики на AT89C2051
|
|
Карма: 27 Рейтинг сообщения: 0
|
Цитата: И я бы поставил часовой кварц для точности. С чего он вдруг точнее ? |
| Вернуться наверх | |
|
Кто сейчас на форуме |
|
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 9 |
| Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения |
Для того, чтобы иметь возможность управлять часами достаточно одной кнопки и варьируя количество нажатий, длительность нажатий можно реализовать любые функции. Однако такой способ даёт неочевидный интерфейс. Поэтому я решил пойти по более простому пути и добавить ещё две кнопки получив таким образом простоту управления. Назначение кнопок предполагаю такое:
1. Переключение настроек по порядку по кругу в таком порядке — десятки часов, единицы часов, десятки минут, единицы минут, десятки секунд, единицы секунд, отображение времени.
2. Увеличение значения текущей настройки кроме режима отображения времени.
3. Уменьшение значения текущей настройки кроме режима отображения времени.
При таком построении управления часами можно легко добавить новые настройки в первый пункт. Это может быть например включение или выключение нагрузки по времени или что-то ещё. Можете предлагать свои варианты.)))
А вот изменённая схема с дополнительными кнопками.
Пока пусть будет такая схема. Далее возможны изменения.
Пишите свои пожелания, предложения, критику. Если ваше предложение мне понравится, то добавлю в проект, или сделаю новый.
Позже выложу в этот пост программу и видео работы. Следите за обновлениями!
UPD. 18 января 2021г. ПН. Дописал программу для данной схемы. Часы работают с указанным выше функционалом кроме настройки секунд, которую не стал делать, поскольку я их не отображаю.
Схема в формате PCAD2006, прошивка и исходник на Си в архиве pr_89c2051_v3.zip Видео демонстрация работы здесь.
Главный недостаток данной схемы в том, что при выключении питания часы сбиваются и при возобновлении питания стартуют с полудня. Дабы устранить данный недостаток я решил в очередной
раз дополнить схему теперь уже дополнительной микросхемой реального времени с интерфейсом SPI или I2C снабжённую батарейкой. Смотрите продолжение в моём блоге.
Using the AT89C2051 Microcontroller
as a Virtual Machine
It is often cited that what differentiates an embedded microcontroller from other general purpose computing devices is its integration into a larger electrical or elec- tro-mechanical system. While this is generally true, the fact remains that processors of widely differing capability and architecture are employed in this regard.
Unfortunately, this broad explanation defines nothing; we are still left to contend with everything from full-blown embedded PCs to the smallest self-con- tained single-chip microcontrollers. Within this expansive realm, conventional wisdom may lead to the conclusion that the smallest microcontrollers are only appropriate for driving smallscale applications with very limited processing requirements. While this is unquestionably the case in many instances, a class of applications exists that mandates a relatively high level of program complexity within severely constrained space limitations. Faced with such a seeming paradox, engineers often feel they have no choice but to adopt a less than optimal design strategy using a larger microcontroller than originally intended.
The problem, of course, is one of limited resources. Functional complexity implies a non-trivial program, and the greater the functional complexity the larger the program. Even as the capability of small single-chip microcontrollers continuously inches upwards, application requirements seem to grow at a commensurate rate. Trying to hit such a moving target is difficult at best.
The economy of using a microcontroller with just enough processing power for a given application is a potent incentive to find just the right fit. Of course, this only
works when the system requirements are thoroughly understood and clearly defined. Since such a design normally has little reserve capacity, it is usually hard pressed to handle features beyond those originally specified. Should additional capabilities eventually become a necessity, the result could be a system that runs out of steam and an engineer that runs out of options. Such are the perils of designing on the edge.
Atmel’s AT89C2051 offers capabilities that far exceed those of competing devices of similar size. This opens up potential design opportunities that were simply unattainable with previously available parts. Housed in a 20-pin package, Atmel’s miniature microcontroller retains all the major features of the 8051 architecture. Furthermore, the AT89C2051 includes all of the 8051’s “special” pins including the external interrupts, UART transmit and receive lines, and the external timer controls. Even though the AT89C2051 significantly ups the processing ante, it would seem that there are limits to what you can accomplish with any single-chip microcontroller.
This dilemma is nothing new. The traditional way of dealing with such limitations has been to operate the microcontroller in external memory mode. Common sense would indicate the hopelessness of applying such an approach to th e A T 8 9C 2 05 1 . A f t er a l l , th e AT89C2051 is truly a single-chip design that does not even possess an external bus structure. It turns out that the situation is not hopeless at all.
|
AT89C2051 |
|
Flash |
|
Microcontroller |
|
Application |
|
Note |
|
w |
|
5-47 |
Processor Simulation
The concept of microprocessor simulation is widely used and well understood. Simulation is often used for development
purposes where a PC program models a specific processor’s architecture and interprets and executes its binary instruction set. Using this technique enables one to develop, test, and debug algorithms that will ultimately be combined into a larger program. Such a program will eventually run on a standalone microprocessor or microcontroller. Using simulation early in the design cycle is attractive because it allows you to start developing code long before the actual target hardware is available.
Processor simulation has also been applied to simulate entire computing systems. In this context, existing application programs, in their native binary format, have been coerced to run on various computers powered by completely different processors. For obvious reasons, the performance resulting from such an approach often proves to be disappointing. This does not necessarily have to be the case if the implementation is designed for a specific purpose. Factors effecting performance efficiency include the host processor’s strengths and limitations, the specific types of operations that are to be simulated, and, to an extent, the language the original program is written in.
Virtual Processor Simulation
Many developmental simulators have been produced that emulate the functions of popular processors and microcontrollers using standard desktop computers. The same principles can be utilized at the other end of the spectrum; there are cases where running a simulation on a small microcontroller can be put to an advantage. In this case, however, the benefit is not derived from simulating a known processor, but one that offers inherent advantages tailored to solving the specific problem at hand. The implication, of course, points to the design of a virtual processor. The idea is based on the premise of using a real processor to implement a virtual device specifically designed to suit the special needs of a particular application. In other words, designing the tool set for a particular job.
The fact is that adopting such a methodology can ultimately result in an architecture that can be pressed to serve as an efficient vehicle for a number of specialized tasks. Details including the fundamental architecture, instruction set, and memory model can be approached with total freedom. But, can such an approach provide the level of performance demanded by embedded applications?
Efficiency and Overhead
To illustrate that efficiency is a subjective matter, consider what happens when a typical C program is compiled to run on an 8051 processor. It’s inconceivable that, on such an architecture, any C statement will effectively compile down to any corresponding 8051 instruction. A single C statement invariably results in the execution of multiple instruction steps. It follows that, given an efficient simulated instruction set, the simulation overhead might account for a very small percentage of the overall execution time.
The key behind making this premise work is to devise an instruction set and processor architecture that’s conducive to performing the types of operations that a C compiler naturally generates. In such an implementation, the contrived instruction set essentially amounts to an intermediate language. The op codes merely serve as a vehicle for succinctly conveying the compiler’s directives to the target processor for execution.
The target processor, while performing the functions of a simulator, interprets the intermediate instructions to perform the functions specified in the original high level language source statements. The resulting efficiency can be quite tolerable since the bulk of the instructions would execute regardless of whether they were emitted directly by the compiler or invoked by the simulation kernel.
It turns out the performance penalty of such an approach is, to a great extent, dependent on the way the program memory itself is implemented. Since the AT89C2051 has no external bus structure it makes sense to use a serial bus to access the program memory. Using I2C for this purpose provides the required flexibility along with reasonable throughput.
Selecting I2C as a memory bus presents the potential of choosing from a wide variety of EEPROM memory devices. The most favorable configuration is Atmel’s AT24C64 that offers 8K bytes of storage in an 8-pin package. Utilizing extended 16-bit addressing, the AT24C64 provides linear access to the entire internal memory array. And although a lot of functionality can be crammed into a single chip, additional devices can easily be added in 8K increments to handle very complex applications. Up to eight AT24C64s can simultaneously reside on the I2C bus providing a full 64K of storage while using just two wires.
Of course, serial memory access does come at a cost. In this case the expense comes in the form of access time. To an extent, this is moderated by the fact that the AT24C64 can operate at a 400 kHz clock rate (standard I2C is specified at a maximum of 100 kHz). Remember however, that I2C can exact a significant performance penalty because a substantial percentage of its bandwidth can be consumed for control functions.
5-48 Microcontroller 
The greatest overhead burden that I2C imposes involves the transfer of addressing information. For every random read or write, a 16-bit address must be transmitted along with the extra overhead necessary to coordinate bus control for both the addressing phase and the data manipulation phase. Under such conditions, actual data movement could be swamped by the requisite overhead resulting in unacceptable performance degradation. Fortunately, I2C provides a means of eliminating much of this wasteful activity.
The AT24C64, like all other I2C memory devices, contains an internal auto-increment address generator. Using this feature, once addressability is established, data can be continually streamed in a sequential fashion. As each byte is read and acknowledged the internal address generator increments in preparation for the next byte transfer. The AT24C64 sets the maximum speed limit at 400 kHz but I2C does not impose a lower limit. Effectively, the minimum frequency can drop all the way to DC. As a result, it’s acceptable to suspend a sequential transfer for as long as necessary.
Utilizing these features, communications can be sped up considerably. The ramifications are particularly significant when the memory is used to store an executable program. For example, once an address is written into the AT24C64, data can be fetched in a continual stream until the program branches or, if multiple AT24C64’s are used, until it becomes necessary to cross into the next chip. At these points it’s necessary to explicitly reload the internal address generator. Normally, however, the majority of the accesses will be sequential, resulting in greatly reduced overhead.
Processor Simulators and Language
Interpreters
It’s important to note the distinction between language specific interpreters that implement a defined language such as BASIC, and a processor simulator that interprets a low level binary instruction set. A tokenized BASIC interpreter, while quite efficient in executing the commands that are explicitly implemented as part of the language, is strictly confined to what the language supports. The inherent efficiency of an interpreted language comes at the expense of flexibility.
In contrast, a processor simulator, that deals with a true binary instruction set, enjoys total freedom in combining these basic op codes into larger functional entities in almost limitless permutations. Just like a real processor, a simulated processor can utilize its instruction set for standard and custom C library functions, floating point libraries, device drivers, etc.
Microcontroller
The Virtual Machine — An Imaginary
Processor
The processor to be described is imaginary in the sense that its architecture and instruction set are original and unique. Realize, however, that this is not just a toy or an intellectual diversion—from an implementation standpoint it is quite real. The fundamental concept has been successfully ported to a variety of processor architectures. A version exists that runs on a personal computer that is suitable for demonstration and development purposes. The most promising small-system port has been to the AT89C2051 due to the microcontroller’s standard processing core and integrated peripheral set. The basic 8K Virtual Machine is schematically depicted in Figure 1. The circuit’s simplicity reveals that this is primarily a software implementation— the definitive soft machine.
This imaginary processor, the product of Dunfield Development Systems, has served in various applications providing reliable solutions to real world problems where a standard configuration was not necessary, optimal, or practical. That this Virtual Machine also goes by the name “C-FLEA” affirms its optimization for efficiently rendering the output of a C language code generator.
The prime currency of a processor is time. Viewed in this context, the expense of complexity can prove unacceptably burdensome. Taking this into consideration, the Virtual Machine, based on a simple 16-bit architecture that incorporates only four registers, is the epitome of simplicity. This register set comprises an accumulator, index register, stack pointer, and program counter. Appendix A provides detailed information about the Virtual Machine architecture and instruction set. Refer to Table 1 for a description of the fundamental resource set.
Although the Virtual Machine performs all operations to 16bit precision, the needs of many embedded systems resolve to 8 bits. To facilitate working with this common denominator, the Virtual Machine stores data in little endian format (low byte first) which facilitates the use of a given variable’s base address to refer to either an 8-bit or 16-bit quantity. Interestingly, the architecture provides no user accessible flags. When invoking a compare instruction, internal flags persist only long enough to accommodate the ensuing branch instruction or the intervening compare modifiers (which are described later).
This spartan register set is made workable by the inclusion of a variety of addressing modes that excel at the types of stack manipulations that are central to the canonical C implementation. The Virtual Machine’s memory access instructions, detailed in Table 2, include the following addressing modes: immediate (8 or 16 bit), direct, indirect through index register (with or without offset), indirect through stack with offset, top of stack, and indirect through top of stack (remove or leave value on stack).
5-49
The bulk of the virtual instruction set is presented in Table 3. These instructions include memory access instructions, arithmetic instruction, and logical instructions. In keeping with the previously established proposition, most can return either bytes or words.
Since the compare instructions are designed to only determine equality, the instruction set is augmented by a set of special compare modifiers. Using these, nuances of relative (signed and unsigned) magnitude can be coerced from the basic compare instructions. These modifiers are described in Table 4.
Program branching is supported using the relatively conventional set of conditional and unconditional jump instructions shown in Table 5. Versions are provided for both near and far destination targets to enhance code efficiency. Note the inclusion of the SWITCH instruction which proves especially useful since the “normal” compare instructions destroy the contents of the accumulator when returning the result of the compare operation.
Table 6 presents the stack manipulation set. Included are common functions such as CALL, RETurn, and PUSH. Conspicuously absent is an explicit POP instruction. The corresponding functionality is provided by the various addressing modes that, by default, manipulate the top of the stack. For instance, POP A is synonymous with LD S+. Additional instructions are included to facilitate stack frame creation and destruction that is a necessary function of the C language implementation.
Finally, the virtual instruction set is rounded with a number of miscellaneous instructions shown in Table 7. For the most part, these perform standard functions that should be self explanatory. The input/output instructions are special in that they offer an implementation specific avenue for establishing certain peripheral functions as instructions. Remember that, even though, the virtual instruction set offers the programmer total freedom to construct any kind of computational sequence, all I/O operations are dependent on the support coded into the Virtual Machine kernel. Essentially, the simulation kernel is the software embodiment of a microprocessor architecture. Naturally, the goal is to provide a general purpose engine capable of serving in a wide variety of real embedded systems.
A significant number of op codes remain unassigned and are available for future use.
Initial Program Loader
While not actually part of the Virtual Machine, the simulation kernel contains a built-in program loader utility. This operates serially and is invoked following a system reset by a sequence of special commands from a utility program running on the host computer. In addition to transferring the load image to the Virtual Processor, the PC program provides a number of features which include a simulator (that can hook into the target’s logical and physical I/O subsystem) and a console window for performing user I/O to the target system. Since the Virtual Machine’s code generator emits a standard Intel HEX file format, the use of the PC utility program is optional.
In principle, there is no reason why an AT24C64 cannot be programmed externally using a standard device programmer just as you would program an EPROM for a use in a typical embedded computer. Although workable, this approach would, at the least, prove cumbersome throughout the development cycle. The difficulty of this approach would be exacerbated in a system using multiple memory chips. Obviously, it would be completely unworkable in the event a Virtual Machine computer was rendered as a surface mount assembly.
5-50 Microcontroller 
Loading…