User forums > Embedded development
Codeblocks MCU / OpenOCD plugin
oBFusCATed:
In fact the code for this plugin seems to be moved in https://github.com/martind574/cbmcu
@martind: Do you still use this plugin?
martind:
Hello All,
Apologies - I have not used (or worked on this) for a few years now. I did put the code up on GitHub a while back, however over the next few days I will see if it still builds.
Martin.
RRomano001:
Hi just a question about embedded OCD:
I browsed source code, I seen at least support STM32, this is well supported on ST IDE and lack of STM32CUBE can be slowing development so I am not really interested port code to C::B nor fiddle with shades of STM devices.
Is this also supporting 8 bit ATMEL AVR I see integrated on C::B?
Again can be feasible to integrate an ICE Z80 and/or MC68HC11 Hardware debugger (FPGA IP Core + Old ICE) ?
Regards
Roberto
oBFusCATed:
I'm not really sure what you're asking.
Can you please try to clarify?
Are you talking about debugger support or compiler support?
You're talking about three/four totally different architectures.
Which exactly does interest you the most?
Again compiler or debugger support doesn't fulfil your needs.
RRomano001:
Hi Obfuscated, yes it need be more specific, sorry is not a simple task but as you can read on and suggested by you I decided avoid this way:
Actual project I am working in from a long time is a simulator and emulator of machine from the past (near 40 Yr old).
This work is related to legacy mcu and Z80 processors.
HC11 mcu code was written in assembly then I ported my code to C and compiled on modern MCU, this process never suffered problem of the past.
Z80 code was written by original manufacturer actually closed activity.
So I am working two way:
CodeBlock hosted supported simulator (my own source) both emulated processor with debugger (also in source). This is fine and deeply integrated to a mechanical software simulator running atop. This part is shared over a lot of module spreading across real hardware too.
Compiler from switches select if code has to be run by simulator (Linux) or real hardware machinery as is on multiple MCU.
When run as software all is on control, no hardware machinery was present and software can stop anywhere and restart pain free. Not same for motor and timing on real one so mus be driven by hardware CPU, this return a lot of feedback to simulator.
When run on FPGA legacy processor both processor are free running out of control and sometimes I feel the desire to analyze what happen on HW processor. (I don't own legacy source code)
When legacy processor run on IPCore FPGA feel integrate some sort of debugger.
Here is the plot of question:
-- Can be a good idea integrate some core of the past into C::B to debug external processor to get benefit of profiling and code analyzer tools?
vs
-- extend software debugger I wrote more than 10 Yr ago. It was not designed with hardware in mind do support real mechanical machinery.
After reading low level part of project opted to extend my old simulator code to integrate some sort of Hardware+Sw break point into IPCore and peripheral MCU firmware.
Actual implementation has original emergency stop integrated by new software layer security supervisor. It is not a big challenge to integrate a "break when is safe" but this is not really necessary when I evaluated all is around.
Actual Hardware can run much faster but need respect timing, this was done by Hardware synced single stepping reducing processor duty to near 2-5%. Core implementation leave a lot of time to collect trace code on fabric (cpu register and MCU's flags too) then transmit back by Ethernet leaving system running real time avoid crashing nor introduce error on mechanics.
Actual software debugger can easily be tailored to process stream data instead of software emulated processor.
From this and your writing too, discourage integrate these on C::B. Both processor still are used as teaching platform but my time is too much limited and I no more use C::B as teaching platform nowadays.
Thank a lot for hint and support.
Roberto
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version