|
Hi,
I hope someone can provide some initial bootstrap advice. I am running MLAB X with the C compiler environment. Cloned the github repository and created the project. Imported the header files and the c files and to my understanding it should be possible to compile using those files. However it seems some files are missing or at least some references are not available. I am very rusty on C programming and perhaps it is just me not understanding. However it could also be that the github repository is not complete?
Thanks for advice and regards, Onno
|
Hi,?
MikroE, MikroC Pro for PIC.
|
Ok understood. So the code relies on embedded functions as offered by the microc compiler environment. Unfortunately this makes the code difficult to use with other compilers.?
I will check if I can write similar functions such as button debouncing and using the i2c interface. Most is provided by microchip ide too but I need to search and learn first.?
Or i strip of all the button and display stuff since I am going to use it for remote tuning only.? Simplifying the code for it's purpose.
I am grateful this tuner got developed and code has been provided through GitHub. It gives a good start to learn.?
Thanks and regards, Onno pa1ap Op ma 15 nov. 2021 05:44 schreef David Fainitski < rolin791@...>:
Hi,?
MikroE, MikroC Pro for PIC.
|
Hi.
You have to change some specific built in functions like Button , ADC, Conversion.?
Also pic configuration and ports settings.
Nothing difficult but it can take a time.
Better use MicroC IDE.
|
Hi David,
I understand it's easier to use microc ide because that's the environment used for the original program.?
Unfortunately the cost associated is high. Combined with a pic 4 programmer I would arrive at around $350 and that's a lot for a small hobby project.?
I have used pickit 2 in the past and wrote assembly to program pic controllers. At the time I also looked at microc and learned it only worked on windows which for me was another showstopper. I don't have windows.?
Best regards Onno Op di 16 nov. 2021 18:30 schreef David Fainitski < rolin791@...>:
Hi.
You have to change some specific built in functions like Button , ADC, Conversion.?
Also pic configuration and ports settings.
Nothing difficult but it can take a time.
Better use MicroC IDE.
|
Onno, I'd be very glad to help.? I am a software developer and write in C and C++ all day long, for embedded processors.? I've just pulled down the source code for version 3.2.? ? My PICkit 3 should arrive today, and I downloaded the MPE X LAB IDE and the XC compilers.??
I agree with David F that we will have to replace the library functions.??
Question for David F:? Would you be interested if we did this in a way that allowed the sources to be built under EITHER tool chain?? And then we could avoid forking the source tree (based upon the tool chain)???
While I agree the MikroC version would work 'as-is', it costs $250 just for the assembler/compiler/linker.
Onno, I'm not a frequent user of github, so I'm not sure how easy it would be for us to co-develop this feature.? If you are already well into it, I could just let you go 'first'.??
Dave
WA1RCT
|
Onno, Dave & David F.,
I was thinking of implementing the code for STM32 and Arduino. Especially?STM32 is close to my heart but Arduino would give a very easy development with no programmer needed. Arduino framework is also available for STM32 cpu's.
So would it be beneficial to try to port the code to plain C that would compile in many environments with some preprocessor magic?
Antti OH5KB
Onno, I'd be very glad to help.? I am a software developer and write in C and C++ all day long, for embedded processors.? I've just pulled down the source code for version 3.2.? ? My PICkit 3 should arrive today, and I downloaded the MPE X LAB IDE and the XC compilers.??
I agree with David F that we will have to replace the library functions.??
Question for David F:? Would you be interested if we did this in a way that allowed the sources to be built under EITHER tool chain?? And then we could avoid forking the source tree (based upon the tool chain)???
While I agree the MikroC version would work 'as-is', it costs $250 just for the assembler/compiler/linker.
Onno, I'm not a frequent user of github, so I'm not sure how easy it would be for us to co-develop this feature.? If you are already well into it, I could just let you go 'first'.??
Dave
WA1RCT
|
Hi Dave!
This sounds great and I really look forward to this project!
------ The approach really depends on one very important thing. Approval from the repository owner who wrote the software. I assume it is David F. but I am not sure about it. ------
I have experience with assembly and pic controllers. GitHub I am using almost daily for my work developing java backend applications. Programming with C is not a normal environment for me but I expect it will come back pretty quickly.?
I have a pickit 4 and I installed the ide and ice application. Both work well on Linux. Also installed the MCC plugin which is a great help to built a C template for config and pin assignment.?
Regarding git we could clone / fork the project or create a new branch from master to another branch with a name representing the work. Latter permission is needed as far as I remember using a public repository.?
I just want to make sure we have the approval from the owner of the original code first.?
Best regards Onno
Onno, I'd be very glad to help.? I am a software developer and write in C and C++ all day long, for embedded processors.? I've just pulled down the source code for version 3.2.? ? My PICkit 3 should arrive today, and I downloaded the MPE X LAB IDE and the XC compilers.??
I agree with David F that we will have to replace the library functions.??
Question for David F:? Would you be interested if we did this in a way that allowed the sources to be built under EITHER tool chain?? And then we could avoid forking the source tree (based upon the tool chain)???
While I agree the MikroC version would work 'as-is', it costs $250 just for the assembler/compiler/linker.
Onno, I'm not a frequent user of github, so I'm not sure how easy it would be for us to co-develop this feature.? If you are already well into it, I could just let you go 'first'.??
Dave
WA1RCT
|
Hi, All
I am not a professional programmer and I don't use GitHub in a right way. Oftenly the code changes with no version changing.?
Please use the sources as is and as you want.
|
I will creat a new GitHub repository and clone the existing one. The main page will obviously cover all the credits towards David and that atu-100 environment / concept.?
After the clone we can start working on the branches and perhaps even use the branches to develop the modules as needed. This is how I manage code and feature development. Each feature has its own branch and with a pull request it can be merged to the main branch. When a feature has to be changed one can pick the feature branch, apply the changes and merge it again to the main branch. This makes it easier to understand and manage the development process.
I will creat and confirm this week. Looking forward!?
Regards Onno
|
Hi Onno,
? ?Sounds like a good plan.??
? ?I've been looking into compiling this under the MPLAB, and found a few things that should help.? My original goal was to try to use the pre-processor and a single additional include file to try to not change any of the code, but I don't see a way this can work.? I found a few areas where the code syntax just needs to change.? (clearly we want NO changes in the functionality of the code, just syntax).
? ?Please note that my findings below are NOT criticisms.? The task here is simply to change compilers while keeping the operation of the code identical.
1) The MikroC compiler identifiers are NOT case-dependent.? So you will find variables like? "my_SW" and "my_sw" and they are identical.? This makes it a little harder to find things, but not impossible.? Just have some good search tools.? And then change them to all have the same case.
2) the assembler constructs are different.? MikroC uses? "asm CLRWDT"? ? and the MPLAB wants to see? 'asm ("CLRWDT").? ?So I'd suggest a global replace.? This seems to be the only assembly statement throughout the code.
3) The manipulation of register bits is different.? The MIkroC compiler has defined 'sbit' and lets you manipulate register labeled bits individually.? For the MPLab compiler, I created a union structure that lets me access the registers as either a byte, or a group of 8 individual bits.? This does force the code that manipulates the bits to change a bit.??
4) I'm now seeing warnings by the compiler about operator precedence.? I think the solution here is to simply add parentheses where needed.? I think we should try to end up with code that has zero warnings.
5) There are some built in libraries that will have to have replacements created.? They should not be hard, but will need to be invented. Things like software I2C bit banging, delay routines, EEPROM access, etc.
6) Lastly, I don't yet understand the details of the 'BUTTON' function.? I'll have to look it up to understand what it does, but I suspect it is a built in library that we will have to replicate.
All for now.? Hope this helps,
Dave
|
Hi Dave?& all,
?
2) Maybe a macro definition?would be good for the?asm instructions. Or if that is the only asm instruction it would be good to define an inline?function for that. And that could be defined differently for various compilers and processor families.?
?
6) This might help a bit. Button library function is documented here:?
?
I hope that helps. I'm interested in this porting job also and I would like to port the code to ATMEGA328 and STM32 family processors also. I have no experience in PIC's though.
Actually also the softI2C is documented here:?http://download.mikroe.com/documents/compilers/mikroc/pic/mikroc-pic-manual-v101.pdf
?
Antti
Hi Onno,
? ?Sounds like a good plan.??
? ?I've been looking into compiling this under the MPLAB, and found a few things that should help.? My original goal was to try to use the pre-processor and a single additional include file to try to not change any of the code, but I don't see a way this can work.? I found a few areas where the code syntax just needs to change.? (clearly we want NO changes in the functionality of the code, just syntax).
? ?Please note that my findings below are NOT criticisms.? The task here is simply to change compilers while keeping the operation of the code identical.
1) The MikroC compiler identifiers are NOT case-dependent.? So you will find variables like? "my_SW" and "my_sw" and they are identical.? This makes it a little harder to find things, but not impossible.? Just have some good search tools.? And then change them to all have the same case.
2) the assembler constructs are different.? MikroC uses? "asm CLRWDT"? ? and the MPLAB wants to see? 'asm ("CLRWDT").? ?So I'd suggest a global replace.? This seems to be the only assembly statement throughout the code.
3) The manipulation of register bits is different.? The MIkroC compiler has defined 'sbit' and lets you manipulate register labeled bits individually.? For the MPLab compiler, I created a union structure that lets me access the registers as either a byte, or a group of 8 individual bits.? This does force the code that manipulates the bits to change a bit.??
4) I'm now seeing warnings by the compiler about operator precedence.? I think the solution here is to simply add parentheses where needed.? I think we should try to end up with code that has zero warnings.
5) There are some built in libraries that will have to have replacements created.? They should not be hard, but will need to be invented. Things like software I2C bit banging, delay routines, EEPROM access, etc.
6) Lastly, I don't yet understand the details of the 'BUTTON' function.? I'll have to look it up to understand what it does, but I suspect it is a built in library that we will have to replicate.
All for now.? Hope this helps,
Dave
?
?
?
--
ana
|
Hi Antti,
? Thanks for the links they will be helpful.? Changing to another processor is a much bigger step than simply changing compilers, but there is no reason it cannot be done.
? ?What we need to be cautious about is to ensure that any changes we make, are made in a way that when David F (the original author) adds any new features, they can be carried over with not much work.??
? ?So I think it breaks down into a few steps.? ?First, we make changes to make the code compiler independent.? Doing this, often means that separating compiler-specific and? processor-specific code out from the core algorithms.? That way the 'smarts' of the algorithms become totally reusable, and the unique parts have to be customized for the CPU/HW/compiler, with the goal of keeping the unique parts as small as possible.
? ?We do need to decide whether to break up the files into smaller chunks.?
? ?Right now I'm torn between trying to minimize the changes in the code, to minimize the disruption (and therefore keep it closer to the original, for support reasons), and reorganizing things heading to the end result looking completely different.? I'm leaning more towards the former as I don't want to end up supporting this permanently.
Dave
?
|
I have created a github repository and started using the microchip cross compiler. I have first commit to github to share the code and happy that first step works. I can now compile the c code which covers a simple relay test.? One thing I am still figuring out is how the Netbeans IDE is working (or not) with settings and how to synchronize this with github.? Right now I broke the settings and need to recover it.?
I am still struggling with how to approach the code. On one hand I would like to preserve the original code but I honestly don't know how to do that correctly.
Best regards Onno pa1ap
|
Hi Onno,
Could you please share the repo. I might?have some ideas for the structure?
Kind regards, Antti oh5kb ke 1. jouluk. 2021 klo 11.45 Onno PA1AP ( pa1ap68@...) kirjoitti:
I have created a github repository and started using the microchip cross compiler. I have first commit to github to share the code and happy that first step works. I can now compile the c code which covers a simple relay test.? One thing I am still figuring out is how the Netbeans IDE is working (or not) with settings and how to synchronize this with github.? Right now I broke the settings and need to recover it.?
I am still struggling with how to approach the code. On one hand I would like to preserve the original code but I honestly don't know how to do that correctly.
Best regards Onno pa1ap
|
Yes, please let us know where the repo is located.
I have been working hard on the code.? It compiles and links (locally) just fine under MPLAB X.? I have run it on the simulator, but not yet on hardware.? I am now trying to make it more readable and 'clean'.? ?I have one set of hardware here to try it on, but will need volunteers to test out all the features.? I have shrunk the code slightly with some of the cleanup.? Within a week I should have it in pretty readable shape.? Also, I have put the compiler-specific changes within #ifdef, so that it should still build find under MikroC.
Dave WA1RCT
|
I guess it is this repo Onno means:
https://github.com/pa1ap/atu-1000
|
Hi Bjorn,
Yes that is correct. I can provide access to co-develop / manage the code. Just share your github user and I will add it.?
Right now all the code provides is the MCC template and I have used the header files to provide test classes , although plain C is challenging to make it OOP.? I have not found a way to include I2C header yet.?
Perhaps David WA1RCT can share his code and I can push it into the git repository?
One thought I had as well is to provide ready to use hex files for each display type etc. Using the Netbeans builder that would be easy. This way nobody has to hack around in the eeprom.?
Best regards Onno
|
Hi Bjorn,
? ?That looks to be the high-power version (atu-1000).
? ?I think what I'll do is put up my MPLAB version as a BRANCH (fork) off of David F's ATU-100 github sources.? I'll label them as MPLAB, and they are based upon Version 3.2??
? ?I will need help from others to try running it on their hardware.? There are a number of Display variants, and I only have one version here.
? ?I'm still working to make it more readable (it compiles, links, and runs on the MPLAB simulator fine), but should have a version to put up next week.??
? ?My goal is to have zero changes in functionality compared to version 3.2, but the code will look very different.? The functions are all the same, but I've run it through a 'c beautifier', and renamed many of the variables, and added constants.
|
Is there any software differences betwern ATU-100 and ATU-1000? I don't think it is. Only different windings on the SWR bridge and more heavy duty toroids and perhaps relays. At least that is how I understand it.
Bj?rn
|
Onno PA1AP