embsys may use standard SVD files made by silicon makers and recognize
internal registers from them?
What is the way to recognize if a microcontroller is a cortex-m3, m0 or
arm7 for embsys? Is it fixed in the source code or is it read by the xml
files? (I mean the core selection on the combo)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thank you for pointing me to arms svd format... I wasn't aware it existed. It
contains all information my view needs, and i find nearly all fields match
mine very closely. So it should not be a problem to ether write a converter or
support the format directly in the view.
There is no detection ...the user chooses the right architecture ... the
selection in the properties page is based on a directory structure where the
xml files are kept... see
mmanca is an abbreviation for Massimo Manca. I am an NXP development partner
and I am interested to enhance embsys to support SVD files. This because it
will become an ARM standard, you can go to ARM web site and find some of them
(the major part from Energy Micro) and I think could be very interesting
because embsys could be automatically updated just adding new SVD files
(without any effort for you). I will ask to ARM what plans they have for SVD
and if they will ask the vendors to publish them. The alternative is to make
an SVD (that is essentially an xml file) from an .h file.
I think that eclipse with gnuarm plugin embsys and a java port of OpenOCD may
be a very good toolchain especially if newlib will be changed with a better
library.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
some use .xml some .svd and another .svd.xml ...values are specified as hex
0xAFFE one vendor use 0 if its 0x0 ...other use #1 and I even encountered #1xx
...
Nevertheless I just commited SVD support to svn ...It works for all supplied
svd files...bit is work in progress
0 and 0x0 are supported, but i refuse to write workarounds for crappy values
like #1xx ...thats the work of the vendor (Freescale)
I also checked in all the svd xml files (renamed them all to .xml) into
data\TEST_SVD\TEST_SVD...
If you need help using the svn version...tell me...(that part is not well
documented, see:
I plan to contribute with other SVD files made by hands or with an SVD
converter. Seems that one .h to svd file converter exists and a silicon maker
may send to us, if it exists will help a lot to convert many existent .h files
that haven't a corresponding svd file.
I could help to the development but I need to study how eclipse plugin work,
so I will install an eclipse testing installation and I will try to build your
source code. If I will be able to build then I could contribute some
modifications, as integrating the .h importer. I think I could do something
next week.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2019-04-13
embsysregview is good plugin but is is not maintained and is not easy to install from eclipse marketplace. Here is simple workaround using svd files in eclipse -
Hi Robert,
nice plugin.
I would understand:
embsys may use standard SVD files made by silicon makers and recognize
internal registers from them?
What is the way to recognize if a microcontroller is a cortex-m3, m0 or
arm7 for embsys? Is it fixed in the source code or is it read by the xml
files? (I mean the core selection on the combo)
Hi, mmanca
thank you for pointing me to arms svd format... I wasn't aware it existed. It
contains all information my view needs, and i find nearly all fields match
mine very closely. So it should not be a problem to ether write a converter or
support the format directly in the view.
There is no detection ...the user chooses the right architecture ... the
selection in the properties page is based on a directory structure where the
xml files are kept... see
http://embsysregview.svn.sourceforge.net/viewvc/embsysregview/trunk/org.eclip
se.cdt.embsysregview/data/
-Robert
Hi Robert,
mmanca is an abbreviation for Massimo Manca. I am an NXP development partner
and I am interested to enhance embsys to support SVD files. This because it
will become an ARM standard, you can go to ARM web site and find some of them
(the major part from Energy Micro) and I think could be very interesting
because embsys could be automatically updated just adding new SVD files
(without any effort for you). I will ask to ARM what plans they have for SVD
and if they will ask the vendors to publish them. The alternative is to make
an SVD (that is essentially an xml file) from an .h file.
I think that eclipse with gnuarm plugin embsys and a java port of OpenOCD may
be a very good toolchain especially if newlib will be changed with a better
library.
Hi Massimo,
it seams a little bit strange...
some use .xml some .svd and another .svd.xml ...values are specified as hex
0xAFFE one vendor use 0 if its 0x0 ...other use #1 and I even encountered #1xx
...
Nevertheless I just commited SVD support to svn ...It works for all supplied
svd files...bit is work in progress
0 and 0x0 are supported, but i refuse to write workarounds for crappy values
like #1xx ...thats the work of the vendor (Freescale)
I also checked in all the svd xml files (renamed them all to .xml) into
data\TEST_SVD\TEST_SVD...
If you need help using the svn version...tell me...(that part is not well
documented, see:
http://embsysregview.sourceforge.net/
under Development -> Dev. Environment)
-Robert
Well done Robert,
I plan to contribute with other SVD files made by hands or with an SVD
converter. Seems that one .h to svd file converter exists and a silicon maker
may send to us, if it exists will help a lot to convert many existent .h files
that haven't a corresponding svd file.
I could help to the development but I need to study how eclipse plugin work,
so I will install an eclipse testing installation and I will try to build your
source code. If I will be able to build then I could contribute some
modifications, as integrating the .h importer. I think I could do something
next week.
embsysregview is good plugin but is is not maintained and is not easy to install from eclipse marketplace. Here is simple workaround using svd files in eclipse -
https://www.blog.neudeep.com/embedded/embsysregview-alternative-plugin-for-eclipse/349/
hope this helps