Jump to content

EugenOS

Members
  • Content Count

    27
  • Joined

  • Last visited

Community Reputation

-1 Плохой

About EugenOS

  • Rank
    Новенький
  • Birthday 04/07/1981

Информация

  • Пол
    Мужчина
  • Интересы
    Программирование, Микроконтроллеры, Космическая техника.<br />Люблю читать.
  • Город
    Казахстан, Караганда
  1. Знатоки NEC подскажите в чем проблема. Имею такую проблему. Портировал в ИАР нековский пример эмулятора еепром на uPD78F9234. Если загружаю программу в контроллер из под ИАРа(тогда загружается код дебагера), все работает. Если же беру HEX (.a26) и заливаю его в контррллер, то блок данных записывает, но функция записи возвращает false (0) как будто запись не удалась. Просматриваю память - данные на месте (записаны без ошибок). Вот здесь в tst без кода отладчика появляется 0. eeBuffer.ee_data.id = rxBuffer.sub_cmd; eeBuffer.ee_data.delimiter = 0; cpy64( eeBuffer.ee_data.data, rxBuffer.data ); tst = eeprom_write( &eeBuffer.ee_data ); то же самое (дизасм): ; eeBuffer.ee_data.id = rxBuffer.sub_cmd; 1335 255E MOV A, S:rxBuffer+1 ; (0xFE5E) 1337 E568 MOV S:eeBuffer, A ; (0xFE68) ; eeBuffer.ee_data.delimiter = 0; 1339 F05FFE MOVW AX, #rxBuffer+2 ; (0xFE5F) 133C F57100 MOV S:0xFE71, #0x00 ; cpy64( eeBuffer.ee_data.data, rxBuffer.data ); 133F E4 MOVW BC, AX 1340 F069FE MOVW AX, #eeBuffer+1 ; (0xFE69) 1343 225116 CALL cpy64 ; (0x1651) ; tst = eeprom_write( &eeBuffer.ee_data ); 1346 F068FE MOVW AX, #eeBuffer ; (0xFE68) 1349 220202 CALL eeprom_write ; (0x0202) 134C 0AE5 MOV C, A ; в других вариантах вместо tst (оптимизировало в регистр С)был сразу if, но результат был тот же. работает так, будто там false вот исходный код eeprom_write (слегка модифицированный код из примеров NEC, просто там они использовали тип bit, которого нет в IAR): ;------------------------------------------------------------------- ; Function name: __eeprom_write (user access function) ; Input: AX = Structure pointer ; Return value: CY = 0(Normal completion) or CY = 1 (abnormal completion) ; Summary: Writes data with specified number from the storage address to EEPROM. ; 1. Searches for blocks being used as EEPROM. ; 2. If there are no valid blocks, the first specified block is set as valid. ; 3. Searches for addresses to enable writing to valid block. ; 4. If the valid blocks are full and cannot be written to, the operation moves to the next block. ; 5. Creates write data. ; 6. Writes to valid blocks. ;------------------------------------------------------------------- ;bit _eeprom_write(struct_eeprom_data *) eeprom_write: PUSH HL PUSH DE PUSH BC CALL getpara ; Decomposes parameter from argument CALL SelfFlashModeOn ; Sets flash mode CALL EEPROMUseBlockSearch ; Searches block currently used as EEPROM BNC EP_WRITE_WTS ; Branches if currently used blocks are found ; ; Starts using new block because no currently used blocks are found ; CALL EEPROMBlockInit ; If no currently used blocks are found, sets block with ; smallest number specified as EEPROM as valid block BC EP_WRITE_FL ; Branches and completes if securing has failed EP_WRITE_2: MOVW AX,#EEPROM_BLOCK*100H+DATATOP MOV CurentB_No,A ; Determines block number to be used ; ; Data write processing ; EP_WRITE_SELF: MOVW DE,AX ; Sets current write address to DE MOVW AX,RWPointer ; Reads structure address XCHW AX,DE ; Sets structure address to DE MOV C,#LENG CALL FlashEEPROMWrite ; Writes data to EEPROM BZ EP_WRITE_TR EP_WRITE_FL: CALL SelfFlashModeOff ; Releases flash mode MOV A,0 ; Return value = Abnormal completion (FALSE) BR EP_WRITE_E ; ; If current block is valid ; EP_WRITE_WTS: CALL EEPROMWriteTopSearch ; Searches writable area BNC EP_WRITE_SELF ; Goes to data writing because area was found ; ; Moves to next block because there is no free space in area ; CALL EEPROMUseBlockChange ; Changes used block BC EP_WRITE_FL ; Exits with abnormal completion EP_WRITE_TR: CALL SelfFlashModeOff ; Releases flash mode MOV A,1 ; Return value = Normal completion (TRUE) EP_WRITE_E: POP BC POP DE POP HL RET ;------------------------------------------------------------------- getpara: MOVW HL,AX ; Sets Structure pointer to HL MOVW RWPointer,AX ; Copies to work area MOV A,[HL] ; Reads data number MOV RQDATA_No,A ; Copies to work area INCW HL ; Sets data address to HL RET ;------------------------------------------------------------------- ; Function name: FlashEEPROMWrite ; Input: DE = Write start address ; C = Number of data blocks to be written ; AX = Write data storage address ; Output: Z(ZeroFlag) = Normal completion (1) or abnormal completion (0) ; Registers used: D, E ; Summary: Writes data to EEPROM and internally verifies the data. ;------------------------------------------------------------------- FlashEEPROMWrite: PUSH HL PUSH AX PUSH BC MOVW HL,AX ; AX = Write data storage address MOV FLCMD,#CMD_BYTE_WRITE ; Sets flash control command (byte write) FL_WR_W1: MOVW AX,HL MOV FLAPH,A XCH A,X MOV FLAPL,A ; Sets write/verify address MOV A,[DE] MOV FLW,A ; Sets write data CALL SubFlashSelfPrg BZ FL_WR_W2 ; Exits if normal completion POP BC BR FL_WR_E FL_WR_W2: INCW DE ; Read address + 1 INCW HL ; Write address + 1 DBNZ C,FL_WR_W1 ; Loops for specified number of bytes POP BC ; C = Number of data blocks to be written POP AX ; Loads write data storage address ; AX = Write data storage address PUSH AX ; Saves write data storage address MOV FLCMD,#CMD_INTERNAL_VERIFY2 ; Sets flash control command (internal verify) MOV FLAPH,A XCH A,X MOV FLAPL,A ; Sets verify start address DEC C ADD A,C XCH A,X ADDC A,#0 MOV FLAPHC,A XCH A,X MOV FLAPLC,A ; Sets verify end address CALL SubFlashSelfPrg FL_WR_E: POP AX POP HL RET ;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Код не весь, смысла весь приводить не вижу. раз данные записываются, значит попадаем в функцию FlashEEPROMWrite. Пробовал из нее убрать ту часть где производится верификация данных. Результат неизменен. вот все различия в данных записываемых в контроллер (ну плюс еще 300 байт отладчика в конце памяти). Как видим это вектор ресета, вектор INTP3 которым порльзуется дебагер и одна ячейка таблицы CALLT которой так же пользуется дебагер. По-видимому отличия в инициализации сказываются на работе с флешь памятью. Вот моя процедура инициализации (вызываю в main в самом начале): void hwinit(void) { asm("DI"); unsigned char ucCnt200us; PCC = 0; // fxp (= fx/4 = 2 MHz) LSRCM = 1; /* Stop the oscillation of the low-speed internal oscillator */ if (!(RESF & 0x01)) { /* Omit subsequent LVI-related processing during LVI reset */ LVIS = 0x0; /* Set the low-voltage detection level (VLVI) to 4.3 V +-0.2 V */ LVION = 1; /* Enable the low-voltage detector operation */ for (ucCnt200us = 0; ucCnt200us < 9; ucCnt200us++) { /* Wait of about 200 us */ asm("NOP"); } while (LVIF){ /* Wait for VDD >= VLVI */ asm("NOP"); } LVIMD = 1; /* Set so that an internal reset signal is generated when VDD < VLVI */ } PPCC = 0x0; // The clock supplied to the peripheral hardware (fxp) = fx (= 8 MHz) P0 = 0x0; PM0 = 0xF0; P2 = 0x00; PM2 = 0xF0; P3 = 0x00; PM3 = 0xF0; P4 = 0x38; PM4 = 0x10; P12 = 0x0F; PM12 = 0xF1; P13 = 0x00; MK0 = 0xFF; // all Intr disabled MK1 = 0xFF; // all Intr disabled setupTimerT80( tcl80_DIV64, 126 ); enableT80Interrupt(); uartSetup( fXPdiv2, 208, noParity | use8DataBits ); ASICL6_bit.no0 = 1; // inverted TxD; uartEnableRxInt(); uartEnableErrInt(); //initWdt( wcsIntOsc | wtv262144 ); initWdt( wcsStop );// пока отключил WDT clrWdt(); IF0 = 0x00; asm("EI"); } Сижу читаю (до дыр) даташиты...
  2. Для информации. ИДА не корректно дизассемблирует некоторые инструкции контроллеров 78K0S.От туда и такие проблемы. вот например: 1)то что дала ИДА: ROM:0E60 main: ; CODE XREF: ROM:loc_DDp ROM:0E60 call !hwInit ROM:0E63 call !swInit ROM:0E66 call !readState ROM:0E69 movw HL,#0FE0Ch ROM:0E6C set1 off_0.0 ; RESET 2) то что было в исходном коде: ; hwinit() 0D83 22D10D CALL hwinit ; (0x0DD1) ; swinit(); 0D86 22560E CALL swinit ; (0x0E56) ; readEslState(); 0D89 22F30F CALL readState ; (0x0FF3) ; uartFlags.uartWaitPilotTone = 1; 0D8C FC0CFE MOVW HL, #uartFlags ; (0xFE0C) 0D8F 0A0E SET1 [HL].0 P.S. Взято с разных версий программы. но этот код там остался неизменным, просто адреса сместились...потому адреса в дизасме и лист файле разные.
  3. Тишина...а вдоль дороги мертвые с косами стоять...
  4. Ну вот, и инклюд тоже пропал из видимости. Просто нажал Build All. Как раз с последней компиляции появилась функция main() та что на картинке с комментарием о заплатке. теперь, даже если ее удалить, инклюд больше не увидит, пока не перепишу в локальную папку проекта. Что за бред. И главное, плагин сами иары пишут. С одной стороны купить у них воркбенч и обратиться в саппорт, а с другой плагин особо не меняли еще с 4-й версии бенча. Где гарантия, что они пошевелятся? Жалко денег в пустую отдавать...рычать хочется.....
  5. Устал от отсутствия в иаре элементарных удобств (хи..хи..посмотреть на PM+ нековский/ренесасовский...так ИАР раем покажется) решил поставить это счастье. Отладка для 78K не реализована, так хоть разработка удобная будет...хм..по началу обрадовался, все так как хотелось. Подсветка нормально работает, подсказки/подстановки предлагает. В общем практически современный RAD...не долго счастье длилось. Что-то там не так реализовано или надо как-то правильно конфигурировать. Короче говоря, имею две проблемы. 1) с #include жесткие проблемы. Регулярно перестает распознавать файлы девайсов из IAR Workbench. т.е. #include <io78F9234.h> через некоторое непродолжительное время (после некоторой правки исходников) начинает подсвечиваться ошибкой. Говорит что файл не найден. Этот момент, в принципе решаем. Копируем файл в папку проекта. И заменяем #include <io78F9234.h> на #include "io78F9234.h". И все работает, но все же не правильно это как-то. 2) Вот это уже не удобно совсем. Не смотря на то, что иаровский компилятор способен совершенно спокойно усваивать не именованные объединения, которые и используются активно в девайс файлах, для описания аппаратуры. При использовании плагина во-первых они упорно не "подсвечиваются" для автоподстановки, и при компиляции постоянно на них ругаеццо что типа нет такого определения. #ifndef __78K_BIT_STRUCTURE__ #define __78K_BIT_STRUCTURE__ typedef struct { unsigned char no0:1; unsigned char no1:1; unsigned char no2:1; unsigned char no3:1; unsigned char no4:1; unsigned char no5:1; unsigned char no6:1; unsigned char no7:1; } __BITS8; #endif // ... ... ... __saddr __no_init volatile union { unsigned char P0; __BITS8 P0_bit; } @ 0xFF00; __saddr __no_init volatile union { unsigned char P2; __BITS8 P2_bit; } @ 0xFF02; __saddr __no_init volatile union { unsigned char P3; __BITS8 P3_bit; } @ 0xFF03; __saddr __no_init volatile union { unsigned char P4; __BITS8 P4_bit; } @ 0xFF04; // ... ... ... т.е. открываем сам файлик. в просмотрщике иерархии появляется куча анонимных union, но когда в основном файле пишем P0 или P0_bit.no0 - ругается что такого определения нет. Пытался включить разные опции, в частности IAR Extended Embeded C++ Syntax. В опциях командной строки он появляется, но упорно не желает видеть не именованные юнионы. Казалось нашел решение. Создаю пустой проект. И в нем сразу не С/C++ Source, а С++ Class. Все начинает работать, все видит. Подключаем девайс файл. В подсказке появляются порты и биты. При компиляции на них не ругается (вообще ругается только линкер, сто нет метода main, ну так мы его еще не создавали. Вот оно счастье. А фигушки. Добавление любого метода к классу, равно как и создание внешней функции main.Снова отрубает у редактора и компилятора способность понимать не именованные юнионы. Что делать с этим уродством???!!!! Кто-нибудь сталкивался? Решение находили? Для того чтоб понятнее было. Выкладываю картинки: Первая, где видно что редактор подчеркивает P0, а компилятор (в низу) на него ругается. А вторая, где видно что оно его вроде как понимает, просто игнорит, т.к. оно не именованное : P.S. Манипуляции с созданием класса, связаны с тем что С99 спецификация не предполагает использование не именованных объединений. Такое по стандарту возможно только в С++. Попытался насильно сделать гарантированный "плюс плюс". Не понятно почему эффект столь мимолетен...
  6. Ну я как бы показал уже решение. На СИ: long __saddr eax, ebx, ecx, edx; extern "C"{ void myFunc(void) } void main(void) { eax = 12345; myFunc() // ну и так далее.... } На асме: SADDR ; на всякий случай, может и не надо extern eax extern ebx extern ecx extern edx RSEG CODE PUBLIC myFunc myFunc: movw AX, #eax mov HL, AX mov A,[HL] ; ну и так далее все здесь написанное лишь для примера. eax в си присваивается значение для иллюстрации, у меня в проекте это внутренние переменные функции написанной на асме, а самой функции передается указатель на буфер...но это уже совсем другая история
  7. Короче сделал проще. объявил переменные в главном модуле на С++: long __saddr eax, ebx, ecx, edx; а на асме объявил их как внешние. extern eax extern ebx extern ecx extern edx Костыль конечно, но т.к. все равно главный модуль на сях, то и фиг с ним. Главное - работает.
  8. Я такое пробовал уже. Добавляет еще ошибку " Error[428]: Address operand must be even" По-идее сегмент релоцируемый и кроме того перед объявлением стоит привязка к четным адресам. Как я понял эти самые \1 ...\2 и т.п. это ссылки на параметры макроса...в реальности он туда пихает 0x10...0x13 для eax 0x14..0x17 для ebx и т.п. проблема в том что адреса эти адреса как бы отданы уже под MUL, DIV и другие SFR PM Plus не катит...во-первых под 7 не работает нормально, во-вторых софтового отладчика нет P.S. я и пытаюсь переложить из под PM+. Кстати именно по этому не один параметр 32-х битной константы, а два двухбайтных. В отличии от IAR, PM+ не подддерживает 32-х битные интегеры в параметрах макроса. пришлось разбивать, когда пытался в ПМ+ работать. А тут еще не исправил на 32-х битные В иаре, почему-то нет SADDRP
  9. Доброго дня всем. Имею непонятки с асмом IAR. ;------------------------------------------------------------------------------ load_const_32 macro freg,c_hi,c_lo movw AX, #(c_lo) movw freg, AX movw AX, #(c_hi) movw freg+2, AX endm ;----------------------------------------------------------------------------- SADDR EVEN ; Задаем сегмент данных с короткой адресацией, при этом с привязкой к четным адресам (чтобы адресация слов работала верно) PUBLIC eax PUBLIC ebx PUBLIC ecx PUBLIC edx m0: DS 4 m1: DS 4 eax: DS 4 ebx: DS 4 ecx: DS 4 edx: DS 4 ;----------------------------------------------------------------------------- RSEG CODE ; сегмент кода, релоцируемый load_const_32 eax, 4503H,114FH movw AX, #(0x114F) ; то же самое что делает макрос movw S:eax, AX ; только я попробовал явно указать короткую адреацию movw AX, #(0x4503) movw S:eax+2, AX так вот. ругается (варнингом) на все строки содержащие movw eax,AX ; mov eax, A и т.п. (т.е. где учавствует любая переменная из объявленных выше). Warning[400]: Number out of range .... На рисунке то что в list файле, сверху в рамку выделен развернувшийся макрос, снизу первый из двух варнингов после макроса. Как бы отличий не вижу...и не пойму чего ему надо. Как я предполагаю, он хочет чтоб я ему указал что переменные находятся в saddr, но где ему этого не хватает в объявлении переменных, в написании операндов или может еще где? Кто с иаром дружит - подскажите.
  10. На самом деле у 702, есть одна большая проблема. температура фена задается кнопками...очень не удобно. модификация 852+FAN имеет удобный фен с турбиной, и все регуляторы "крутилки". А 898 точно такая же(с точки зрения пользования), но выполнена в более компактном корпусе. Потому, мне кажется 898 наиболее удачным вариантом.
  11. Не могу. Не имею кода. Есть описание библиотеки, с заголовками функций. Есть ТЗ на программу. И есть несколько последних рабочих версий прошивки. Во всех этот участок такой же (ну только адреса разнятся) Софтовый отладчик SM78K0S. Скачать не могу. Посылают пешим сексуальным маршрутом.
  12. На счет метки мой косяк. метку переименовал, а в команде перехода нет. Описание системы комманд есть...но там ничего отличного от работы таких комманд в других процах не видно. Может быть есть какие-то отличия связанные именно со смещением 00+HL или еще чего-то...но в доступных мне документах об этом ни слова. Потому и спрашиваю...может есть кто-то, кто работал, например с uPD78F9116 P.S. Документация по NEC это вообще долгая и трудная песня...особенно по дискаунтед представителям... P.P.S. Если у вас есть ДШ по данным прцам поделитесь пожалуйста...то что у меня есть зачитано до дыр в мониторе, но не объясняет данного феномена. Что этим хотел сказать компилятор не понятно...
  13. да из дизасма...исходники на си, это кусок скомпилированного кода... С интеловским и Z80 сам знаком, вот потому и вопрос. по логике должно было менять байтики (и оно их меняет) а по коду на асме выходит что все скидывается в ячейки FE00..FE03, причем перетирая ранее записаное...потому и возник этот вопрос. может команды еще и рег. L модифицируют? т.е. непонятки как раз там где [HL+0] P.S. Ошибки нет. программа работает. но вот разобраться с этим куском кода на асме не выходит. т.е. понять не могу что куда заносится при модификации. в исходном коде используются четыре массива по 8 байт. и над ними производится ряд операций. (хеширование). код в библиотеке. нужно кое-что поменять, для этого дизасмится.
  14. ну вот...как всегда в рунете, никакой информации...лишь бы первонах оставить...
×
×
  • Create New...