hc12mem v1.2
------------
- added support for Freescale's serial monitor (Application Note AN2548)
Using this serial monitor in target FLASH memory, hc12mem can:
- erase,read,write,protect target EEPROM
- erase,read,write target FLASH
- securing/unsecuring is not supported, due to monitor presence
So for now, hc12mem can access HCS12 MCU memory via BDM (Kevin Ross
BDM12 or PODEX), Freescale's LRAE bootloader or Freescale's serial
monitor.
http://cml.mfk.net.pl/hc12mem/
Freescale's AN2548 serial monitor port to GNU tools
---------------
Freescale published source code for this serial monitor as a companion
to the application note. Software is available as complete CodeWarrior
project. Although there are many HCS12 derivatives supported, there're
no S-record files, only project ready to be compiled. This is quite
unfortunate for those that do not use CodeWarrior environment. It was
easier for me to port this source code to GNU toolchain, than to setup
windows box with CodeWarrior. So i did that - users of GNU hc11/12
toolchain wishing to use this seral monitor can compile it on their own
(strictly speaking, only assembler is required, not C compiler).
http://cml.mfk.net.pl/an2548/
--
Michal Konieczny
mk@mk@....
hc12mem 1.2 - added support for serial monitor, and port of monitor to GNU toolchain
Started by ●November 23, 2005
Reply by ●November 27, 20052005-11-27
--- In 68HC12@68HC..., Michal Konieczny <mk@c...> wrote:
> - added support for Freescale's serial monitor (Application Note AN2548)
> http://cml.mfk.net.pl/hc12mem/
> Freescale's AN2548 serial monitor port to GNU tools
> http://cml.mfk.net.pl/an2548/
Michal,
You have great skills for low-level driver code writing. Have you
thought about creating a standard API for linux and Windows that would
support your low-level functions?
I'm working on my visual debugger and I think a standard set of
low-level drivers would be a great idea. I could use them thru a
simple translation layer, and I think gdb could use them that way
also. Other debuggers might also work with a simple translation layer,
such as Eclipse.
I think the API for the serial monitor is a good starting place for
the fuctions we need, but I'd like to make them a little more flexible
and self-describing to support different targets. I think it's be cool
if each driver had a way to specify it's capabilities. A GUI program
could send a request to the driver to say "tell me what you can do",
and the driver would respond with a struct that lists all the commands
it supports (maybe a list of booleans). That way some drivers might
not support programming flash, for example, but a GUI program could
still use it for programming RAM.
To make this work we'd need an API that is standard, but with a number
of optional functions. Any optional function that is not supported
would be indicated in the capabilities as mentioned above, but would
also return an "unsupported" error code if someone tried to execute
that function.
We'd have to pay attention to versioning the interface so it could be
enhanced in the future, but older drivers could still work because
their version number tells us how much of the API they understand.
The linkage between the driver and the GUI program could be simple - a
Win32 DLL, or a linux shared library. I could help with the Windows
side if needed.
Just some ideas...
Eric
> - added support for Freescale's serial monitor (Application Note AN2548)
> http://cml.mfk.net.pl/hc12mem/
> Freescale's AN2548 serial monitor port to GNU tools
> http://cml.mfk.net.pl/an2548/
Michal,
You have great skills for low-level driver code writing. Have you
thought about creating a standard API for linux and Windows that would
support your low-level functions?
I'm working on my visual debugger and I think a standard set of
low-level drivers would be a great idea. I could use them thru a
simple translation layer, and I think gdb could use them that way
also. Other debuggers might also work with a simple translation layer,
such as Eclipse.
I think the API for the serial monitor is a good starting place for
the fuctions we need, but I'd like to make them a little more flexible
and self-describing to support different targets. I think it's be cool
if each driver had a way to specify it's capabilities. A GUI program
could send a request to the driver to say "tell me what you can do",
and the driver would respond with a struct that lists all the commands
it supports (maybe a list of booleans). That way some drivers might
not support programming flash, for example, but a GUI program could
still use it for programming RAM.
To make this work we'd need an API that is standard, but with a number
of optional functions. Any optional function that is not supported
would be indicated in the capabilities as mentioned above, but would
also return an "unsupported" error code if someone tried to execute
that function.
We'd have to pay attention to versioning the interface so it could be
enhanced in the future, but older drivers could still work because
their version number tells us how much of the API they understand.
The linkage between the driver and the GUI program could be simple - a
Win32 DLL, or a linux shared library. I could help with the Windows
side if needed.
Just some ideas...
Eric
Reply by ●December 1, 20052005-12-01
> Michal,
>
> You have great skills for low-level driver code writing. Have you
> thought about creating a standard API for linux and Windows that would
> support your low-level functions?
Yes, I'm thinking about it. I'd like to turn my code into something like
external library to gdb, requiring only small static interface within gdb, and
all further work - support for different chips, bdm pods, serial monitors, etc
- to be moved to external "plugin". If we'll design the interface to satisfy
various needs, we can turn it into something more universal.
If you can describe your requirements in somewhat more detail, we can try to
specify something.
Best regards,
--
Michal Konieczny
mk@mk@....
>
> You have great skills for low-level driver code writing. Have you
> thought about creating a standard API for linux and Windows that would
> support your low-level functions?
Yes, I'm thinking about it. I'd like to turn my code into something like
external library to gdb, requiring only small static interface within gdb, and
all further work - support for different chips, bdm pods, serial monitors, etc
- to be moved to external "plugin". If we'll design the interface to satisfy
various needs, we can turn it into something more universal.
If you can describe your requirements in somewhat more detail, we can try to
specify something.
Best regards,
--
Michal Konieczny
mk@mk@....
Reply by ●December 2, 20052005-12-02
--- In 68HC12@68HC..., Michal Konieczny <mk@c...> wrote:
> If you can describe your requirements in somewhat more detail, we
can try to
> specify something.
I am currently only involved with the Windows side, so I'd be looking
for a DLL.
However, it would be great if we could define a code base that would
also work on linux, with the obvious platform differences restricted
to a small number of files (things like COM port I/O, and DLL vs .so).
I'm not good enough with low-level details on linux to offer any help
on the linux side, but I like linux and I hope someone more familiar
with it can step up and help with this.
I can use anything you do for gdb if you keep it isolated from gdb
itself. I would like a portable driver spec, and then each particular
debugger could have it's own unique wrapper to let it use the
generalized driver model.
I assume you've been reading my messages here about what I want to do:
an open source visual debugger written in C#. I can interface with any
Win32 DLLs, so the driver code can be written in any language (C being
an obvious choice).
I've been delayed in my project because of a year-end crunch at work,
but I'll try to get some screenshots out soon, and the first beta may
come in late Jan or early Feb. I'll keep the initial features limited
to those things the serial monitor can support for my first release,
and I want to add d-bug12 and BDM support later.
One of my biggest problems is that I don't have many boards to test
with, and I only have hands-on experience with a small number of them.
If we could develop some kind of standard driver model, that would
make it easier for me to support boards that I don't know much about.
My first release will use some driver code I adapted from the
Technological Arts uBug12 serial monitor debugger. Their debugger has
a similar interface to d-bug12, which itself can't work with the
serial monitor. But uBug12 is a text oriented debugger and I wanted to
make it more visually-friendly by making it look like the commercial
visual debuggers.
Eric
> If you can describe your requirements in somewhat more detail, we
can try to
> specify something.
I am currently only involved with the Windows side, so I'd be looking
for a DLL.
However, it would be great if we could define a code base that would
also work on linux, with the obvious platform differences restricted
to a small number of files (things like COM port I/O, and DLL vs .so).
I'm not good enough with low-level details on linux to offer any help
on the linux side, but I like linux and I hope someone more familiar
with it can step up and help with this.
I can use anything you do for gdb if you keep it isolated from gdb
itself. I would like a portable driver spec, and then each particular
debugger could have it's own unique wrapper to let it use the
generalized driver model.
I assume you've been reading my messages here about what I want to do:
an open source visual debugger written in C#. I can interface with any
Win32 DLLs, so the driver code can be written in any language (C being
an obvious choice).
I've been delayed in my project because of a year-end crunch at work,
but I'll try to get some screenshots out soon, and the first beta may
come in late Jan or early Feb. I'll keep the initial features limited
to those things the serial monitor can support for my first release,
and I want to add d-bug12 and BDM support later.
One of my biggest problems is that I don't have many boards to test
with, and I only have hands-on experience with a small number of them.
If we could develop some kind of standard driver model, that would
make it easier for me to support boards that I don't know much about.
My first release will use some driver code I adapted from the
Technological Arts uBug12 serial monitor debugger. Their debugger has
a similar interface to d-bug12, which itself can't work with the
serial monitor. But uBug12 is a text oriented debugger and I wanted to
make it more visually-friendly by making it look like the commercial
visual debuggers.
Eric
