Do you have a question? Post it now! No Registration Necessary
Threaded View
Subject
- Oleksandr Redchuk
July 29, 2004, 3:16 pm
Reply
Save
Hi, All!
Может, $(SUBJ). Может, что-то не так сделано до него (там замешан ещё
какой-то 1.raw, а я в иаровских путях не разбираюсь).
Короче, вот итог очередной моей переписки.
28-Jul-04 10:03 avreal user wrote:
s>>> при использовании Вашего avreal возникла интерезная загвоздка.
s>>> размер проекта превысил 64К, при этом выходной файл, создаваемый
s>>> IAR'овским postlink (я вынужден им пользоваться, т.к. у меня в
s>>> проекте используется инициализированный EEPROM) перестал шиться с
s>>> сообщением "memory overlapping", причем в области старших адресов(!).
s>>> после проведенного эксперимента выяснилось, что extended-hex,
s>>> создаваемый линкером напрямую, шьется без проблем. оказалось, что
s>>> они по-разному обозначают расширенные сегменты памяти (>64K, а
s>>> именно xlink - директивами 02, а postlink - 04. очевидно, avreal
s>>> как-то не так понимает оную директиву? процессор - mega128, IAR
s>>> 3.10C, тестовый проект могу выслать при необходимости
OR>> Вышлите hex-файлы обеих вариантов, я посмотрю как они сделаны.
s> все три в прицепленном файле. исходник такой
s> #include <iom128.h>
s> __flash char foo1[0xff00] = {0, };
s> __farflash char foo2[0xff00] = {0, };
s> __eeprom char foo3 = 0;
s> void main()
s> {
s> unsigned int i;
s> for (i = 0; i < 0xff00; ++i)
s> {
s> foo3 = foo1[i] + foo2[i] + foo3;
s> }
s> }
[...]
s> win32. вот батник, который все делает
s> @echo off
s> postlink.exe -intel-extended -code -data -idata -bit -const -untyped
s> 1.raw 1.hex
s> postlink.exe -intel-extended -xdata 1.raw 1e.hex
s> avreal32 -p1 +mega128 -! -ewp 1.hex 1e.hex
s> avreal32 -p1 +mega128 -! -ewp 1.a90 1e.hex
s> exit
OR>> p.s.2 есть "независимый" способ проверки, надо каким-то
OR>> конвертором hex-bin конвертнуть оба файла, из-под xlink и из-под
OR>> postlink и сравнить бинарники.
s> я специально нулевые файлы скомпилял, по совету Harry Zhurov, для
s> проверки. с виду файлы в обоих случаях вполне корректные. кстати,
s> напоминаю, что до момента пересечения границы 64К все работало
При внимательном рассмотрении файлов оказалось, что постлинковский
файл не такой белый и пушистый, как прикидывается.
А совет Журова правильный, так как в "боевом" файле будет каша из
секций и вручную сравнивать тяжело.
Мой же совет про конвертацию в bin и сравнивание бинарников тоже надо
было использовать :-)
[...]
28-Jul-04 12:14 avreal user wrote:
s> все, я разобрался (надо было раньше подумать). прочел avreal'ом
s> прошивку в hex (а он ведь в 4-м формате сохраняет!), прочитанная
Это методологически неправильно. Если ищется бага в avreal, желательно
сделать проверку хотя бы в одном из направлений другой программой.
Мало ли, может у меня там две ошибки :-)
s> прошивка шьется нормально. сравнил - отличаются файлы только
s> наличием у postlinkовского в самом начале записи
Не только.
s> :020000040000FA
s> отсюда и мораль басни - баг в авриле в разборе записи 04 с нулевым
s> адресом
Мораль другая. Или как-то не правильно сформирован 1.raw, или
неправильно вызван постлинк, или "Платное - не значет без
багов" :-)
Итак имеем присланные:
1.a90 = файл из-под xlinka
1.hex = из-под постлинка, сделан из какого-то 1.raw
hex2bin 1.a90 1-a90.bin
hex2bin 1.hex 1-hex.bin
fc/b 1-a90.bin 1-hex.bin
Сравнение файлов 1-A90.BIN и 1-HEX.BIN
00000004: 18 00
00000005: 95 00
[... куча адресов подряд поскипаны]
0000008A: 18 00
0000008B: 95 00
00010004: E0 18
00010005: 9A 95
[...]
0001008A: 00 18
0001008B: 00 95
Мда... В принципе, после этого можно послать за дальнейшими ответами к
IAR-овцам :-)
Но ведь интересно же, где они умудрились наколотся?
Продолжение в следующем письме...
wbr,
Может, $(SUBJ). Может, что-то не так сделано до него (там замешан ещё
какой-то 1.raw, а я в иаровских путях не разбираюсь).
Короче, вот итог очередной моей переписки.
28-Jul-04 10:03 avreal user wrote:
s>>> при использовании Вашего avreal возникла интерезная загвоздка.
s>>> размер проекта превысил 64К, при этом выходной файл, создаваемый
s>>> IAR'овским postlink (я вынужден им пользоваться, т.к. у меня в
s>>> проекте используется инициализированный EEPROM) перестал шиться с
s>>> сообщением "memory overlapping", причем в области старших адресов(!).
s>>> после проведенного эксперимента выяснилось, что extended-hex,
s>>> создаваемый линкером напрямую, шьется без проблем. оказалось, что
s>>> они по-разному обозначают расширенные сегменты памяти (>64K, а
s>>> именно xlink - директивами 02, а postlink - 04. очевидно, avreal
s>>> как-то не так понимает оную директиву? процессор - mega128, IAR
s>>> 3.10C, тестовый проект могу выслать при необходимости
OR>> Вышлите hex-файлы обеих вариантов, я посмотрю как они сделаны.
s> все три в прицепленном файле. исходник такой
s> #include <iom128.h>
s> __flash char foo1[0xff00] = {0, };
s> __farflash char foo2[0xff00] = {0, };
s> __eeprom char foo3 = 0;
s> void main()
s> {
s> unsigned int i;
s> for (i = 0; i < 0xff00; ++i)
s> {
s> foo3 = foo1[i] + foo2[i] + foo3;
s> }
s> }
[...]
s> win32. вот батник, который все делает
s> @echo off
s> postlink.exe -intel-extended -code -data -idata -bit -const -untyped
s> 1.raw 1.hex
s> postlink.exe -intel-extended -xdata 1.raw 1e.hex
s> avreal32 -p1 +mega128 -! -ewp 1.hex 1e.hex
s> avreal32 -p1 +mega128 -! -ewp 1.a90 1e.hex
s> exit
OR>> p.s.2 есть "независимый" способ проверки, надо каким-то
OR>> конвертором hex-bin конвертнуть оба файла, из-под xlink и из-под
OR>> postlink и сравнить бинарники.
s> я специально нулевые файлы скомпилял, по совету Harry Zhurov, для
s> проверки. с виду файлы в обоих случаях вполне корректные. кстати,
s> напоминаю, что до момента пересечения границы 64К все работало
При внимательном рассмотрении файлов оказалось, что постлинковский
файл не такой белый и пушистый, как прикидывается.
А совет Журова правильный, так как в "боевом" файле будет каша из
секций и вручную сравнивать тяжело.
Мой же совет про конвертацию в bin и сравнивание бинарников тоже надо
было использовать :-)
[...]
28-Jul-04 12:14 avreal user wrote:
s> все, я разобрался (надо было раньше подумать). прочел avreal'ом
s> прошивку в hex (а он ведь в 4-м формате сохраняет!), прочитанная
Это методологически неправильно. Если ищется бага в avreal, желательно
сделать проверку хотя бы в одном из направлений другой программой.
Мало ли, может у меня там две ошибки :-)
s> прошивка шьется нормально. сравнил - отличаются файлы только
s> наличием у postlinkовского в самом начале записи
Не только.
s> :020000040000FA
s> отсюда и мораль басни - баг в авриле в разборе записи 04 с нулевым
s> адресом
Мораль другая. Или как-то не правильно сформирован 1.raw, или
неправильно вызван постлинк, или "Платное - не значет без
багов" :-)
Итак имеем присланные:
1.a90 = файл из-под xlinka
1.hex = из-под постлинка, сделан из какого-то 1.raw
hex2bin 1.a90 1-a90.bin
hex2bin 1.hex 1-hex.bin
fc/b 1-a90.bin 1-hex.bin
Сравнение файлов 1-A90.BIN и 1-HEX.BIN
00000004: 18 00
00000005: 95 00
[... куча адресов подряд поскипаны]
0000008A: 18 00
0000008B: 95 00
00010004: E0 18
00010005: 9A 95
[...]
0001008A: 00 18
0001008B: 00 95
Мда... В принципе, после этого можно послать за дальнейшими ответами к
IAR-овцам :-)
Но ведь интересно же, где они умудрились наколотся?
Продолжение в следующем письме...
wbr,
--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua */
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua */
[2/2] Внимание! баг в IAR-овском postlink?
Hi, All!
Продолжаем.
Но ведь интересно же, где они умудрились наколотся?
"Закат солнца вручную", смотрим на 1.a90 и 1.hex
========= 1.a90
:020000020000FC
Стартовый адрес сегмента 0, за ним явно таблица векторов.
:100000000C94EC7F189518951895189518951895D7
:100010001895189518951895189518951895189578
:100020001895189518951895189518951895189568
:100030001895189518951895189518951895189558
:100040001895189518951895189518951895189548
:100050001895189518951895189518951895189538
:100060001895189518951895189518951895189528
:100070001895189518951895189518951895189518
:100080001895189518951895189518950000000062
:100090000000000000000000000000000000000060
это пошёл foo1[]
:10FF70000000000000000000000000000000000081
За ним - стартап и main()
:10FF8000000000000000000000000000792F682F32
:10FF900080E090E01AC021E030E0A9010E940480D6
:10FFA000102FECE8F0E0E80FF91F2491E2E3F0E015
:10FFB00031E0E80FF91F3BBF0691020F010F21E06E
:10FFC00030E0A9010E941080019680300FEF900769
:10FFD00010F3862F972F08950FE30DBF01E00EBF9A
:10FFE000C0E2D1E00E9414800E94C67F0E94168069
:10FFF0000C941680E199FECF08954F5F5F4FFADFB2
немного не влезли в первые 64К, переваливаем
:020000021000EC
сегментный адрес 1000, это к последующим адресам добавлять
0x00010000
:100000004EBB5FBBE09A0895FADF0DB308954F5FD2
:100010005F4F4EBB5FBBF894E29AE19A0FBE089522
:100020000FB6E8DF0DBBF5CF01E00895000088951D
:10003000FECF0000000000000000000000000000F3
:1000400000000000000000000000000000000000B0
foo2[]
:10FF100000000000000000000000000000000000E1
:10FF200000000000000000000000000000000000D1
:02FF30000000CF
:00000001FF
Всё, конец. Никаких претензий. Теперь берём постлиноквский.
========= 1.hex
:020000040000FA
Стартовый линейный адрес 0x00000000
:040000000C94EC7FF1
Это был jmp на запускалку
А где же вектора? Впрочем, в hex-файле записи не обязаны быть
отсортированными.
:10008C000000000000000000000000000000000064
foo1[]
:10FF7C000000000000000000000000000000000075
запускалка и код
:10FF8C00792F682F80E090E01AC021E030E0A901C1
:10FF9C000E940480102FECE8F0E0E80FF91F249188
:10FFAC00E2E3F0E031E0E80FF91F3BBF0691020FEE
:10FFBC00010F21E030E0A9010E94108001968030F1
:10FFCC000FEF900710F3862F972F08950FE30DBFB7
:10FFDC0001E00EBFC0E2D1E00E9414800E94C67FF7
:10FFEC000E9416800C941680E199FECF08954F5F05
:04FFFC005F4FFADF7A
Аналогично, не влезло
:020000040001F9
Внимание! К адресам ВСЕХ записей после этого приписывается
старшие 16 бит как 0x0001 (т.е. добавляется 0x00010000).
:100000004EBB5FBBE09A0895FADF0DB308954F5FD2
:100010005F4F4EBB5FBBF894E29AE19A0FBE089522
:100020000FB6E8DF0DBBF5CF01E00895000088951D
:02003000FECF01
:020000040001F9
Опять то же самое, не нужно, но и не мешает. Так было удобно,
перед началом новой секции просто поставить запись её стартового
адреса (я только за такие байторасточительные подходы :-)
:1000320000000000000000000000000000000000BE
:1000420000000000000000000000000000000000AE
foo2[]
:10FF020000000000000000000000000000000000EF
:10FF120000000000000000000000000000000000DF
:10FF220000000000000000000000000000000000CF
Опаньки! Пошла таблица векторов, но БЕЗ именно ЕЁ стартового
адреса. Итого вместо адресов 0x00000004 и далее она легла в
0x00010004 и далее! Именно это показал fc/b с бинарниками и на
это выругался avreal.
:100004001895189518951895189518951895189584
:100014001895189518951895189518951895189574
:100024001895189518951895189518951895189564
:100034001895189518951895189518951895189554
:100044001895189518951895189518951895189544
:100054001895189518951895189518951895189534
:100064001895189518951895189518951895189524
:100074001895189518951895189518951895189514
:080084001895189518951895C0
:00000001FF
Перед векторами очень нехватает записи ":020000040000FA", но её
там нет.
Остаётся накатать баг-репорт и отправить в IAR.
Atmel winavr тоже (как минимум был) любитель не там, где надо
поставить запись расширенной адресации в hex, подобное длинное
письмо было от меня пару лет назад.
wbr,
p.s.
http://www.abi-usa.com/downloads/UTILS/BIN2HEX.zip
http://www.abi-usa.com/downloads/UTILS/BIN2MOT.zip
http://www.abi-usa.com/downloads/UTILS/HEX2BIN.zip
http://www.abi-usa.com/downloads/UTILS/MOT2BIN.zip
Продолжаем.
Но ведь интересно же, где они умудрились наколотся?
"Закат солнца вручную", смотрим на 1.a90 и 1.hex
========= 1.a90
:020000020000FC
Стартовый адрес сегмента 0, за ним явно таблица векторов.
:100000000C94EC7F189518951895189518951895D7
:100010001895189518951895189518951895189578
:100020001895189518951895189518951895189568
:100030001895189518951895189518951895189558
:100040001895189518951895189518951895189548
:100050001895189518951895189518951895189538
:100060001895189518951895189518951895189528
:100070001895189518951895189518951895189518
:100080001895189518951895189518950000000062
:100090000000000000000000000000000000000060
это пошёл foo1[]
:10FF70000000000000000000000000000000000081
За ним - стартап и main()
:10FF8000000000000000000000000000792F682F32
:10FF900080E090E01AC021E030E0A9010E940480D6
:10FFA000102FECE8F0E0E80FF91F2491E2E3F0E015
:10FFB00031E0E80FF91F3BBF0691020F010F21E06E
:10FFC00030E0A9010E941080019680300FEF900769
:10FFD00010F3862F972F08950FE30DBF01E00EBF9A
:10FFE000C0E2D1E00E9414800E94C67F0E94168069
:10FFF0000C941680E199FECF08954F5F5F4FFADFB2
немного не влезли в первые 64К, переваливаем
:020000021000EC
сегментный адрес 1000, это к последующим адресам добавлять
0x00010000
:100000004EBB5FBBE09A0895FADF0DB308954F5FD2
:100010005F4F4EBB5FBBF894E29AE19A0FBE089522
:100020000FB6E8DF0DBBF5CF01E00895000088951D
:10003000FECF0000000000000000000000000000F3
:1000400000000000000000000000000000000000B0
foo2[]
:10FF100000000000000000000000000000000000E1
:10FF200000000000000000000000000000000000D1
:02FF30000000CF
:00000001FF
Всё, конец. Никаких претензий. Теперь берём постлиноквский.
========= 1.hex
:020000040000FA
Стартовый линейный адрес 0x00000000
:040000000C94EC7FF1
Это был jmp на запускалку
А где же вектора? Впрочем, в hex-файле записи не обязаны быть
отсортированными.
:10008C000000000000000000000000000000000064
foo1[]
:10FF7C000000000000000000000000000000000075
запускалка и код
:10FF8C00792F682F80E090E01AC021E030E0A901C1
:10FF9C000E940480102FECE8F0E0E80FF91F249188
:10FFAC00E2E3F0E031E0E80FF91F3BBF0691020FEE
:10FFBC00010F21E030E0A9010E94108001968030F1
:10FFCC000FEF900710F3862F972F08950FE30DBFB7
:10FFDC0001E00EBFC0E2D1E00E9414800E94C67FF7
:10FFEC000E9416800C941680E199FECF08954F5F05
:04FFFC005F4FFADF7A
Аналогично, не влезло
:020000040001F9
Внимание! К адресам ВСЕХ записей после этого приписывается
старшие 16 бит как 0x0001 (т.е. добавляется 0x00010000).
:100000004EBB5FBBE09A0895FADF0DB308954F5FD2
:100010005F4F4EBB5FBBF894E29AE19A0FBE089522
:100020000FB6E8DF0DBBF5CF01E00895000088951D
:02003000FECF01
:020000040001F9
Опять то же самое, не нужно, но и не мешает. Так было удобно,
перед началом новой секции просто поставить запись её стартового
адреса (я только за такие байторасточительные подходы :-)
:1000320000000000000000000000000000000000BE
:1000420000000000000000000000000000000000AE
foo2[]
:10FF020000000000000000000000000000000000EF
:10FF120000000000000000000000000000000000DF
:10FF220000000000000000000000000000000000CF
Опаньки! Пошла таблица векторов, но БЕЗ именно ЕЁ стартового
адреса. Итого вместо адресов 0x00000004 и далее она легла в
0x00010004 и далее! Именно это показал fc/b с бинарниками и на
это выругался avreal.
:100004001895189518951895189518951895189584
:100014001895189518951895189518951895189574
:100024001895189518951895189518951895189564
:100034001895189518951895189518951895189554
:100044001895189518951895189518951895189544
:100054001895189518951895189518951895189534
:100064001895189518951895189518951895189524
:100074001895189518951895189518951895189514
:080084001895189518951895C0
:00000001FF
Перед векторами очень нехватает записи ":020000040000FA", но её
там нет.
Остаётся накатать баг-репорт и отправить в IAR.
Atmel winavr тоже (как минимум был) любитель не там, где надо
поставить запись расширенной адресации в hex, подобное длинное
письмо было от меня пару лет назад.
wbr,
p.s.
http://www.abi-usa.com/downloads/UTILS/BIN2HEX.zip
http://www.abi-usa.com/downloads/UTILS/BIN2MOT.zip
http://www.abi-usa.com/downloads/UTILS/HEX2BIN.zip
http://www.abi-usa.com/downloads/UTILS/MOT2BIN.zip
--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua */
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua */
Re: [2/2] Внимание! баг в IAR-овском postlink?
Hello Oleksandr.
29 Jul 04 18:17, you wrote to all:
OR> Atmel winavr тоже (как минимум был) любитель не там, где надо
OR> поставить запись расширенной адресации в hex, подобное длинное
OR> письмо было от меня пару лет назад.
Hда. А objcopy не проверял? Как он работает?
Кстати, а что этот postlink.exe делает?
Alexey
29 Jul 04 18:17, you wrote to all:
OR> Atmel winavr тоже (как минимум был) любитель не там, где надо
OR> поставить запись расширенной адресации в hex, подобное длинное
OR> письмо было от меня пару лет назад.
Hда. А objcopy не проверял? Как он работает?
Кстати, а что этот postlink.exe делает?
Alexey
Re: [2/2] Внимание! баг в IAR-овском postlink?
29-Jul-04 16:56 Alexey Boyko wrote to Oleksandr Redchuk:
OR>> Atmel winavr тоже (как минимум был) любитель не там, где надо
OR>> поставить запись расширенной адресации в hex, подобное длинное
OR>> письмо было от меня пару лет назад.
AB> Hда. А objcopy не проверял? Как он работает?
Я когда мерял скорость записи в мегу128, генерил дутый файл,
несколько пустых массивов. Выходило под 110кб, avreal не обижался.
AB> Кстати, а что этот postlink.exe делает?
А это такой ихний objcopy, разваливает на hex-ы для flash и eeprom.
wbr,
OR>> Atmel winavr тоже (как минимум был) любитель не там, где надо
OR>> поставить запись расширенной адресации в hex, подобное длинное
OR>> письмо было от меня пару лет назад.
AB> Hда. А objcopy не проверял? Как он работает?
Я когда мерял скорость записи в мегу128, генерил дутый файл,
несколько пустых массивов. Выходило под 110кб, avreal не обижался.
AB> Кстати, а что этот postlink.exe делает?
А это такой ихний objcopy, разваливает на hex-ы для flash и eeprom.
wbr,
--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua */
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua */
[2/2] Внимание! баг в IAR-овском postlink?
Hello Oleksandr.
30 Jul 04 06:19, you wrote to me:
AB>> Кстати, а что этот postlink.exe делает?
OR> А это такой ихний objcopy, разваливает на hex-ы для flash и eeprom.
Вот бы было хорошо, если бы avreal elf'ы кушал. Хотя, можно написать
скриптик, который разбивает elf в два временных хекса, скармливает их
avreal'у, а потом удаляет.
Alexey
30 Jul 04 06:19, you wrote to me:
AB>> Кстати, а что этот postlink.exe делает?
OR> А это такой ихний objcopy, разваливает на hex-ы для flash и eeprom.
Вот бы было хорошо, если бы avreal elf'ы кушал. Хотя, можно написать
скриптик, который разбивает elf в два временных хекса, скармливает их
avreal'у, а потом удаляет.
Alexey
Re: [2/2] Внимание! баг в IAR-овском postlink?
9-Aug-04 08:10 Alexey Boyko wrote to Oleksandr Redchuk:
AB>>> Кстати, а что этот postlink.exe делает?
OR>> А это такой ихний objcopy, разваливает на hex-ы для flash и eeprom.
AB> Вот бы было хорошо, если бы avreal elf'ы кушал.
Мммм.... Была уже мысля... Заодно с секцией .fuses...
Но как-то всё за пределы "была мысля" не выходит.
AB> Хотя, можно написать
AB> скриптик, который разбивает elf в два временных хекса, скармливает их
AB> avreal'у, а потом удаляет.
У меня не вызывает неудобств болтание рядом с .elf-ом уже выкорчёванных из
него .hex и .eep.
wbr,
AB>>> Кстати, а что этот postlink.exe делает?
OR>> А это такой ихний objcopy, разваливает на hex-ы для flash и eeprom.
AB> Вот бы было хорошо, если бы avreal elf'ы кушал.
Мммм.... Была уже мысля... Заодно с секцией .fuses...
Но как-то всё за пределы "была мысля" не выходит.
AB> Хотя, можно написать
AB> скриптик, который разбивает elf в два временных хекса, скармливает их
AB> avreal'у, а потом удаляет.
У меня не вызывает неудобств болтание рядом с .elf-ом уже выкорчёванных из
него .hex и .eep.
wbr,
--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua */
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua */
Re: аналог SIM8252 для AVR
В письме отSat, 24 Jul 2004 12:14:16 +0400, Dmitry Ponyatov
Работает, причем довольно неплохо.
WMLAB пробовал ? http://www.amtools.net/vmlab310.zip
Есть еще ProjectAVR (www.phyton.ru) наиболее прост для освоения т.к. есть
хелп и русский он.
Но я не смог заставить его входить в процедуры обработки прерываний. Хотя
поддержка прерываний заявлена.
IAR ??? ой ну называть его полноценным эмулятором я бы не стал :)
AVRStudio и встроенный хелп.
Или фитон если систему команд уже знаешь.
Работает, причем довольно неплохо.
WMLAB пробовал ? http://www.amtools.net/vmlab310.zip
Есть еще ProjectAVR (www.phyton.ru) наиболее прост для освоения т.к. есть
хелп и русский он.
Но я не смог заставить его входить в процедуры обработки прерываний. Хотя
поддержка прерываний заявлена.
IAR ??? ой ну называть его полноценным эмулятором я бы не стал :)
AVRStudio и встроенный хелп.
Или фитон если систему команд уже знаешь.
--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
аналог SIM8252 для AVR
Wed, 4 Aug 2004 21:30:38 +0000 (UTC) Pawel Roghkov wrote to Dmitry Ponyatov:
[...]
PR> IAR ??? ой ну называть его полноценным эмулятором я бы не стал :)
Во-первых, начиная с версий 3.хх IAR'овский C-SPY может работать с именно
эмуляторами - Atmel'овский JTAG-ICE, например. Причем сам он (спай) как
отладчик на голову выше студии (и по удобству, и по прямоте (отсутствию
кривизны), и по безглючности).
Во-вторых, и как симулятор он полезнее. Да, он симулирует только ядро, без
периферии, но симуляция периферии в МК - достаточно спорная вещь: периферия
работает с _внешним_ окружением, а его смоделировать, порой, крайне сложно. И
на практике оказывается гораздо удобнее, быстрее и эффективнее моделировать
окружение программы с помощью системы макросов, которую поддерживает спай... Я
тоже поначалу (лет 6 назад, когда оно только появилось) морду кривил на тему
спая и все пытался в студии моделировать. Но постепенно понял, в чем она -
сермяжная правда! Критичные (по производительности и ответственности) куски
кода на симуляторе отлаживаются вполне удобно - даже удобнее, чем на эмуляторе,
а если требуется какое-то участие со стороны периферии, то с помощью макросов
можно легко организовать и входной поток данных (через UART или хоть с портов
ввода-вывода), работу Input Capture, запись выходного потока в файл и т.д.
Причем не надо париться с тем, чтобы создать условия, при которых честная
симуляция (как в студии) периферии будет выдавать нужную ситуацию - эту
ситуацию легко смоделировать, задав конкретные времена срабатывания макросов.
[...]
PR> IAR ??? ой ну называть его полноценным эмулятором я бы не стал :)
Во-первых, начиная с версий 3.хх IAR'овский C-SPY может работать с именно
эмуляторами - Atmel'овский JTAG-ICE, например. Причем сам он (спай) как
отладчик на голову выше студии (и по удобству, и по прямоте (отсутствию
кривизны), и по безглючности).
Во-вторых, и как симулятор он полезнее. Да, он симулирует только ядро, без
периферии, но симуляция периферии в МК - достаточно спорная вещь: периферия
работает с _внешним_ окружением, а его смоделировать, порой, крайне сложно. И
на практике оказывается гораздо удобнее, быстрее и эффективнее моделировать
окружение программы с помощью системы макросов, которую поддерживает спай... Я
тоже поначалу (лет 6 назад, когда оно только появилось) морду кривил на тему
спая и все пытался в студии моделировать. Но постепенно понял, в чем она -
сермяжная правда! Критичные (по производительности и ответственности) куски
кода на симуляторе отлаживаются вполне удобно - даже удобнее, чем на эмуляторе,
а если требуется какое-то участие со стороны периферии, то с помощью макросов
можно легко организовать и входной поток данных (через UART или хоть с портов
ввода-вывода), работу Input Capture, запись выходного потока в файл и т.д.
Причем не надо париться с тем, чтобы создать условия, при которых честная
симуляция (как в студии) периферии будет выдавать нужную ситуацию - эту
ситуацию легко смоделировать, задав конкретные времена срабатывания макросов.
--
H.Z.
harry.zhurov<antispam::at>ngs<antispam::period>ru
H.Z.
harry.zhurov<antispam::at>ngs<antispam::period>ru
We've slightly trimmed the long signature. Click to see the full one.
Re: аналог SIM8252 для AVR
В письме отThu, 5 Aug 2004 04:54:48 +0000 (UTC), Harry Zhurov
Ну у студии есть конечно свои странности но меньше чем у альтернатив.
На мой взгляд лучше всего - VMLAB
Все хорошо... Главный вопрос: Где ты возьмешь на халяву C-SPY ? За него
дерут и много, что для
освоения ну никак не годится :)
Ну у студии есть конечно свои странности но меньше чем у альтернатив.
На мой взгляд лучше всего - VMLAB
Все хорошо... Главный вопрос: Где ты возьмешь на халяву C-SPY ? За него
дерут и много, что для
освоения ну никак не годится :)
--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
аналог SIM8252 для AVR
Thu, 5 Aug 2004 16:08:16 +0000 (UTC) Pawel Roghkov wrote to Harry Zhurov:
[...]
PR> Все хорошо... Главный вопрос: Где ты возьмешь на халяву C-SPY ? За него
PR> дерут и много, что для
PR> освоения ну никак не годится :)
Спай входит в пакет, отдельно его брать не надо. Где берется пакет, уже
давно все знают.
[...]
PR> Все хорошо... Главный вопрос: Где ты возьмешь на халяву C-SPY ? За него
PR> дерут и много, что для
PR> освоения ну никак не годится :)
Спай входит в пакет, отдельно его брать не надо. Где берется пакет, уже
давно все знают.
--
H.Z.
harry.zhurov<antispam::at>ngs<antispam::period>ru
H.Z.
harry.zhurov<antispam::at>ngs<antispam::period>ru
We've slightly trimmed the long signature. Click to see the full one.
Site Timeline
- » Mega162
- — Next thread in » Microcontrollers (Russian)
-
- » GSM модем и NETMONITIR
- — Previous thread in » Microcontrollers (Russian)
-
- » По моему это гениально
- — Newest thread in » Microcontrollers (Russian)
-
- » (PDF) Behavioral Neuroscience of Orexin, Hypocretin by Andrew J Lawrence
- — The site's Newest Thread. Posted in » Electronics (Polish)
-
XML Sitemap