Перейти к содержанию
    

luben111

Участник
  • Постов

    83
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о luben111

  • Звание
    Частый гость
    Частый гость
  • День рождения 19.01.1959

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array
  1. Форум Electronix - ето не место для чата. Нет.
  2. Я согласен с цель DXF импорта - он для контура. То что предложили используется в Gerber файлы. Проблема в том что формы очень сложные и потом в Алтиуме нужно часто их легко редактировать.
  3. Здраствуйте, У меня проблема мучить уже несколько лет - как в Алтиуме импортировать полигонов которые потом можно сделать copper pour. Представьте у вас много фигур сложной формы в DXF файле. Мне нужно чтобы все фигуры были заполнены (copper pour). После импортирование DXF файла в Алтиуме все фигуры будут выглядит как tracks. Чтобы сделать формы плотные мне надо выбрать все траки одной формы и использовать Tools/ Convert/Create Polygon from selected primitives. Если фигуры довольно сложные процесс очень медленный. То же самое очень просто в ORCAD - при импорте все формы правильно держаться (при выборе одного трака вся формя селектируеться) и конверсия в copper pours проходить мигновенно. Попробовал тоже с использование plane в DXF файле - plane конвертируются в region в Алтиуме, проблема в том что plane имеет только 3 - 4 вершины. Буду очень благодарен если кто нибудь подскажет как можно сразу импортировать polygons в Алтиуме, речь идет об множество сложных форм (емкостные слайдеры или скрины).
  4. К сожалению TASM не подходит к мою 16 bit архитектуру команд - в таблице нужно указать все возможные команды (например ADD R0, R0; ADD R1, R0; ADD R2, R0.... ADD R15, R0.... ADD R15,R15 - 256 команды только для ADD). ИМНО лучше пользоваться SWITCH (где в коде каждая команда имеет программная секция).
  5. Спасибо всем, Я тоже нашел что то - http://www.drdobbs.com/embedded/222600279 Конечно универсального ассемблера не может существовать, я был рад иметь что то довольно близкое к конечному продукту.
  6. Здравствуйте, У меня такая задача - написать на C++. C# или Delphi макроассемблер для нестандартного микроконтроллера (который еще не в продаже). Контроллер имеет ~90 комманд и 16 бит архитектуры. Конечно самый легкий путь - взять кокой то универсальный ассемблер и написать только таблицы инструкции. Буду благодарен для идеи.
  7. Конечно - решение проблемы точно как вы уже писали! Большое спасибо за идею! Я прочитал все что написали и только добавил почему надо так сделать. Всегда лучше знать почему что то происходить.
  8. К сожалению проблема хуже чем вам кажется. Я говорил с гуру в области Atmel и теперь все понятно как это происходить и как можно обмануть: 1. Tiny88 может принимать SLA в Power sleep моде но не может принимать и посылать данные в Power sleep моде !! Причина об этом очень долго объяснить но находиться в внутренний state machine. 2. Так если SLA уже принять не надо входить в Power sleep в никаком случае - это может сломать коммуникации. Можно использовать только Idle Sleep 3. Проблема можно увидеть в практически каждом камне Atmel !!!! То что Power Down Sleep не используется так часто и то что обычно в Power Down sleep принимается SLA в 99.9% делает эту проблему трудной для отыскания. Решение - следить за SLA и если он принять идти в Idle sleep. Нужно сделать хорошая state machine в TWI прерывание. Я сделал все это и проблема ушла навсегда!
  9. Я забыл сказать что проблема не в просыпания! Просто модуль перестает работать - как бы SCL отключен от модуля. Но буду попробавать ваши идеи! Спасибо за идеи!
  10. Осциллограммы показывают что TWI Tiny88 при введение в sleep моде просто перестает действовать (если SLA уже принять). Так если Tiny88 посылает данные и SDA находится в 0 в момент введения в sleep моде то SDA застрянет в 0 и не будет меняться из за SCL. После окончания sleep SDA линия будет навсегда в 0 и только reset TWI может восстанавить коммуникации. Решение (если можно называть это решение) - если SLA уже принять не идти в sleep. Я ну буду удивлен если проблема находится не только в Tiny88 но и в другие контроллеры is Tiny или AtMega.
  11. ATiny88 - проблема с TWI in slave mode

    Здраствуйте, Я нашел что Tiny88 держится непослушно в TWI slave mode и тянет линия SDA к GND на неопределенное время после просыпание. Сценарий возникновение проблемы такой: 1. Tiny88 в TWI slave моде, имеет адрес SLA и прерывание только на TWI. Чип работает на внутренним осцилляторе 8MHz. 2. Host посылает SLA+R и чип успешно принимает SLA+R в прерывание. Host начинает читать следующий байт. 3. В то время когда чтения байта происходить (после выполнения прерывании для SLA+R) Tiny88 разрешает прерывание из WDT и уходит в deep sleep mode - все модули с исключение TWI отключенный из питания из PRR. Просыпание возможно только из TWI или WDT. 4. Когда последний бит уже послан Tiny88 находиться в deep sleep моде. 5. Здесь происходить что то неладное (я в процесс уточнения что конкретно происходить )- чип просыпается но держит линия SDA к GND. Только установка и сброс TWSTO или забрана/разрешения TWEN может восстановить SDA. Вопрос - кто то встречал уже такое поведение Tiny88? Как можно обманут процессора и избежать задержка SDA?
  12. У меня проблема такая возникла с компилятором IAR 5.3 для AVR, камень Tiny88 - оптимизатор не 'видит' что переменная можно менять в прерывание. В результате код не правильно оптимизирован - MoreCode() удален так как while (flagWasI2C != 1) всегда true. Код на уровне main() в MainCode.c модуле: extern uint8_t flagWasI2C; void main(void) { ....... Protect(); flagWasI2C = 0; UnProtect(); do // wait for I2C communication { __watchdog_reset(); } while (flagWasI2C != 1); MoreCode(); // this section is not compiled } Protect() - CLI, UnProtect - SEI и в перерывание для TWI (находиться в I2C.c модуле): uint8_t flagWasI2C; #pragma vector=TWI_vect __interrupt void TWI_ISR( void ) { DoSomething(); flagWasI2C = 1; } При компиляции с максимальной оптимизации можно увидеть что MoreCode() просто удален - переменная flagWasI2C установлена в нуль и в main() не видно что она можно меняться в TWI ISR. Как можно обмануть компилятор чтобы он не удалял MoreCode()? Нашел что если поставит операция с регистрами и как то оптимизатор начинает правилно 'смотреть' и код работает: extern uint8_t flagWasI2C; void main(void) { ....... Protect(); flagWasI2C = 0; UnProtect(); DDRA = 12; // и MoreCode() уже присуствует!!! do // wait for I2C communication { __watchdog_reset(); } while (flagWasI2C != 1); MoreCode(); // this section is not compiled }
  13. Программа сейчас работает, но возникла вот такая проблема поддержки и структурной чистотой - адрес установлен в линкере и он не виден из компилятора. Если хочу использовать то же значение 0200 для установки других параметров мне надо заново установит в файле параметр (например #define SIZE_AREA 0x200). Поддержка кода усложнена и возможность сделать ошибки больше потому что надо менять данные на 2 места . Я попробовал #define SIZE_AREA 0x200 ..... ((void (*)())SIZE_AREA)(); Все работает прекрасно но нахожу в дизассемблере LDI R30, 00 LDI R31, 02 IJMP В итоге 4 байта больше! Подскажите как вернут добрый RJMP на месте и вместе с тем установить адрес SIZE_AREA внутри С файла - т.е. был доступен внутри С файла для дополнительные операции как __root __flash uint16_t MARKER @ (SIZE_AREA-2) = 0x434C;
×
×
  • Создать...