Author Topic: MPLAB X a PIC inhibitor! Alternatives ?  (Read 76678 times)

0 Members and 1 Guest are viewing this topic.

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #225 on: December 08, 2017, 08:40:33 am »
westfw, you are indeed correct. I didn't express myself too well. Of course, there is no point in recreating libc or software floating point standard libraries in most cases, even though sometimes even that makes sense.

But my point is, when someone is praising the ease of doing a project "with libraries" and reusing other's code, they are never talking about libc. Because almost everyone uses libc in almost every project, it's there "by default", many people don't even know what it is.

Yes, I was talking mostly about embedded-specific libraries, typically hardware abstraction. They are often pure shit. For a few good reasons: typically, a library is not needed, so few people want to develop them -> no good developers to make good library design. Second, in embedded, everything is too case-by-case specific and special. Very difficult to make a universally working library. The same goes with application notes that provide example code: they are too specifically designed, just to provide that single example. So they are not very useful in the actual customer application as is; they need to be redesigned so much that the amount of code that can be reused is often near zero.

At the same time, I was also talking about very "high-level" unnecessary libraries increasing complexity and being used just because they are trendy. I don't know if Boost is the best example, but something like that. I mean stuff that requires a significant learning curve to be useful at all, and even then of questionable value.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #226 on: December 08, 2017, 02:14:19 pm »
The libraries came to the embedded world from generic software development. Say, in Windows, your program may run on many different computers (who knows what) and it must display things correctly. So, a library is needed to interface your hardware-oblivious code to the specific graphics hardware. Hence you have GDI and also graphic drivers. There's no other way.

In the embedded world you don't want to be hardware-oblivious - your goal is to control hardware. You have a choice of the hardware. When you choose your hardware it is partly because you want it to work a certain way. You want to access specific features. Why would you use a library which tries to treats your carefully-chosen hardware in some generic way?

The very existence of such libraries is the result of applying programming principles developed for "big computers" to the embedded works. It is done without thinking, does not have any merit and is rather an impediment on embedded programmer's way.

 
The following users thanked this post: hans, Siwastaja, Karel, JPortici, fourtytwo42

Offline picdev

  • Contributor
  • Posts: 14
  • Country: gr
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #227 on: December 11, 2017, 07:48:42 pm »
As I see that there are a lot of good engineers in this topic , I have one question about arm.
I write c on 8 and 16 bit mcus , I don't have the need to go to arm , also there are 8bit mcus with pll and run at 64mhz .
So most  engineers say that arm have ethernet USB and are cheap.
So you chose stm32 207 with Ethernet , you pay 10 Euros for this MCU, and you must add  an ic for phy. Layer , so you pay extra  5 Euros .
And now you have a scary physical layer library and TCP /IP stack in your software , maybe you must add an rtos .
 Also stm give you a phycal library for a specific ic .
Why I have to chose this complex model?
I see that I can use a cheap  MCU with no Ethernet and one wiznet ic with intergrated tcp IP stack ?

I am sorry for my English


Sent from my Redmi 4 using Tapatalk
« Last Edit: December 11, 2017, 07:50:37 pm by picdev »
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13694
  • Country: gb
    • Mike's Electric Stuff
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #228 on: December 11, 2017, 09:06:35 pm »
As I see that there are a lot of good engineers in this topic , I have one question about arm.
I write c on 8 and 16 bit mcus , I don't have the need to go to arm , also there are 8bit mcus with pll and run at 64mhz .
So most  engineers say that arm have ethernet USB and are cheap.
So you chose stm32 207 with Ethernet , you pay 10 Euros for this MCU, and you must add  an ic for phy. Layer , so you pay extra  5 Euros .
And now you have a scary physical layer library and TCP /IP stack in your software , maybe you must add an rtos .
 Also stm give you a phycal library for a specific ic .
Why I have to chose this complex model?
I see that I can use a cheap  MCU with no Ethernet and one wiznet ic with intergrated tcp IP stack ?
I've used the Wiznet W5500 chip on a PIC32MZ that has an ethernet peripheral - the cost was similar to a PHY, and I didn't need to deal with Microchip's Harmony library BS.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline mrpackethead

  • Super Contributor
  • ***
  • Posts: 2845
  • Country: nz
  • D Size Cell
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #229 on: December 12, 2017, 02:59:08 am »
I've gone nearly full circle on harmony.   Its a scary learning curve its poorly docoumetned, and the examples are crap.  BUT once you get past that,  ( only took me 18 months ) I actually now can turn out working applications that are resoanbly complex in veryh short time frames.   I use the MZ and various phys.

On a quest to find increasingly complicated ways to blink things
 

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1662
  • Country: us
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #230 on: December 13, 2017, 01:32:47 am »
There are certain libraries that I think most everyone uses. Who here writes their own floating point code to implement the basic math operations or things like printf? Most people just use what the compiler vendor provides, and that works well enough for 99% of the people using it.

Peripheral libraries are another thing entirely and these range from mediocre to just plain shit. Since this is a PIC thread, does anyone actually use Harmony? On a scale of 0 being shit and 10 being great, Harmony is probably a -5.
Complexity is the number-one enemy of high-quality code.
 

Offline mrpackethead

  • Super Contributor
  • ***
  • Posts: 2845
  • Country: nz
  • D Size Cell
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #231 on: December 13, 2017, 05:20:06 am »
There are certain libraries that I think most everyone uses. Who here writes their own floating point code to implement the basic math operations or things like printf? Most people just use what the compiler vendor provides, and that works well enough for 99% of the people using it.

Peripheral libraries are another thing entirely and these range from mediocre to just plain shit. Since this is a PIC thread, does anyone actually use Harmony? On a scale of 0 being shit and 10 being great, Harmony is probably a -5.

Yes, and deployed solutions based on it sucessfully.    It was a steep learning curve, but now i'm actulaly able to get it to do things quickly and profitably.
On a quest to find increasingly complicated ways to blink things
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #232 on: December 13, 2017, 05:41:18 am »
Just going back a bit because it’s something I recently checked,
Microchip’s image decoder library contains free code for JPEG decompression that once packaged into their own library,
Microchip say you can’t modify that either if I understand correctly (like GCC).

Code: [Select]
* jidctint.c
 *
 * Copyright (C) 1991-1998, Thomas G. Lane.
 * This file is part of the Independent JPEG Group's software.
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #233 on: December 13, 2017, 11:04:04 am »
Just going back a bit because it’s something I recently checked,
Microchip’s image decoder library contains free code for JPEG decompression that once packaged into their own library,
Microchip say you can’t modify that either if I understand correctly (like GCC).

Code: [Select]
* jidctint.c
 *
 * Copyright (C) 1991-1998, Thomas G. Lane.
 * This file is part of the Independent JPEG Group's software.
That thing is libjpeg, which comes under BSD-like license, so Microchip technically can restrict the use of their version, although since it is libjpeg after all you can prevent the Microchip version from being linked it and substitute your own fork of it.
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #234 on: January 22, 2018, 02:54:50 pm »
Hi :D I was waiting for my trial period to expire before trying it,
but I actually have the specific version 1.33 XC16 mentioned in the file, and the specs.txt file method doesn’t work.

Assuming this was a hex editor view, what actually has to be changed to what here?
Code: [Select]
8472db5: 8b 35 a0 25 94 08    mov    0x89425a0,%esi
 8472dbb: 85 f6                test   %esi,%esi
 8472dbd: 0f 85 d2 05 00 00    jne    8473395 <pic30_override_options+0x895>
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #235 on: January 22, 2018, 03:24:38 pm »
Hi :D I was waiting for my trial period to expire before trying it,
but I actually have the specific version 1.33 XC16 mentioned in the file, and the specs.txt file method doesn’t work.

In case it doesn't work out, you can always fall back to the method described here:

https://www.eevblog.com/forum/microcontrollers/pic32-evolution/msg1007099/#msg1007099
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #236 on: January 22, 2018, 04:17:58 pm »
Hi, mine is on a Mac, and I don’t have the tools for that.
I was hoping the easy way would work :D

I’m on a phone in bed now, and realised the blank line in the
Spec.txt might be wrong.
TextEdit for Mac insets 0x0A characters for new lines,
where other editors such as Windows Notepad inserts
0x0A, 0x0D. Hopefully it’s just that.

I have the same Ver XC16 as in the help document,
and my MPLAB-X ver is actually a few updates old,
so I don’t see how any new measure could stop it working.
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #237 on: January 22, 2018, 09:33:42 pm »
Quote
Hopefully it’s just that.
I doubt it. My specs.txt file for xc16 has only a 0x0A (linux, created with kwrite), which works.

I would suspect something wrong with the global option-
-specs=specs.txt
although if something was wrong, the compiler would start complaining (you did add that option, right?)


You should be able to run this script (option 3) on a Mac
if not, then my opinion of Mac OS just went down :)
need- terminal- bash (or similar), objdump, grep, xxd, sed

get to terminal in this directory-
/opt/microchip/xc16/v1.33/bin/bin/
(not sure, maybe Mac uses something else, adjust as needed)

copy and paste this script-

Code: [Select]
for f in elf-cc1 coff-cc1; do
[ -e $f.bak ] || cp $f $f.bak
a=$(objdump -T $f | grep mchp_mafrlcsj)
a=${a:6:2}${a:4:2}${a:2:2}${a:0:2}
b=$(objdump -t elf-cc1 | grep gcc_version)
b=${b:6:2}${b:4:2}${b:2:2}${b:0:2}
old="\(8b..\)${a}"
new="\1${b}"
xxd -ps $f.bak | sed "s:$old:$new:" | xxd -r -p - $f
done

summary-
line1- just simply do for each  of these 2 files (nobody probably uses coff file, though)
line2- if backup copy not previously made, make one
line3- using objdump, get address of mchp_mafrlcsj
line4- convert address to little-endian
line5- using objdump, get address of gcc_version
line6- convert to little-endian
line7- create var for sed search- 8b..address of mchp_mafrlcsj
line8- create replacement var for sed- 8b..address of gcc_version
line9- dump file into sed as hex, replacing first (only) instance of match, dump back out to binary
line10- done

You can also use a hex editor on elf-cc1-
you need the address of mchp_mafrlcsj so you have something to search for (address is little-endian)
option1- replace the address of the mov instruction target from mchp_mafrlcsj to gcc_version
(need both addresses, from objdump)
option2- replace the jne soon after the mov to je (I think 0f 85 to 0f 84)
« Last Edit: January 22, 2018, 11:33:19 pm by cv007 »
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #238 on: January 23, 2018, 03:03:52 am »
It looks like it will work, as in no errors, but actually doesn’t.

Code: [Select]
for f in elf-cc1 coff-cc1; do
[ -e $f.bak ] || cp $f $f.bak
a=$(otool -T $f | grep mchp_mafrlcsj)
a=${a:6:2}${a:4:2}${a:2:2}${a:0:2}
b=$(otool -t elf-cc1 | grep gcc_version)
b=${b:6:2}${b:4:2}${b:2:2}${b:0:2}
old="\(8b..\)${a}"
new="\1${b}"
xxd -ps $f.bak | sed "s:$old:$new:" | xxd -r -p - $f
done

otool is apparently the Mac version of objdump.
It ends up with errors unless I change it.

Code: [Select]

Breks-Mac:desktop bmar0000$ cd XC16_Backup
Breks-Mac:XC16_Backup bmar0000$ cd xc16/v1.33/bin/bin/
Breks-Mac:bin bmar0000$ for f in elf-cc1 coff-cc1; do
> [ -e $f.bak ] || cp $f $f.bak
> a=$(otool -T $f | grep mchp_mafrlcsj)
> a=${a:6:2}${a:4:2}${a:2:2}${a:0:2}
> b=$(otool -t elf-cc1 | grep gcc_version)
> b=${b:6:2}${b:4:2}${b:2:2}${b:0:2}
> old="\(8b..\)${a}"
> new="\1${b}"
> xxd -ps $f.bak | sed "s:$old:$new:" | xxd -r -p - $f
> done

Breks-Maci:bin bmar0000$

No complaining in the terminal, but the project still tells me my license is restricted just the same.


« Last Edit: January 23, 2018, 03:05:52 am by @rt »
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #239 on: January 23, 2018, 03:27:31 am »
First, my script does have an error- line5 should be $f instead of elf-cc1 (probably didn't cause any problem as it only effects coff-cc1 users)

In linux, the ones to modify are in bin/bin- the ones in bin call the ones in bin/bin- a level of indirection for some reason (prevents -mafrlcsj option for one thing).

I'm not a Mac person, so not familiar with its tools, and its exe format (not elf apparently).

I would start over, cp your .bak copies back to original name so you are working with original copies again (always keep the .bak versions around for times like this).

in your bin/bin directory-
cp elf-cc1.bak elf-cc1
cp coff-cc1.bak coff-cc1

now you are working with the originals again

forget the script for now, just get the addresses from the command line-
otool -T elf-cc1 | grep mchp_mafrlcsj
otool -t elf-cc1 | grep gcc_version

once you get those two addresses, report back- will simply then need to run a hex edit program.
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #240 on: January 23, 2018, 03:52:04 am »
I backed up the whole XC16 directory elsewhere before touching them. Then when it didn’t work,
deleted XC16 from the Application directory, and replaced the whole lot with original, so the .bak files don’t even exist anymore.

Code: [Select]
Breks-Mac:~ bmar0000$ cd /Applications/microchip/xc16/v1.33/bin/bin
Breks-Mac:bin bmar0000$ otool -T elf-cc1 | grep mchp_mafrlcsj
Breks-Mac:bin bmar0000$ otool -t elf-cc1 | grep gcc_version

I guess that’s a problem then :D
« Last Edit: January 23, 2018, 03:58:10 am by @rt »
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #241 on: January 23, 2018, 04:14:24 am »
I’ve subscribed monthly to XC16 Pro, because I need it working, and it’s running again.
$29US per month is what the free software costs, or $1500US for a USB dongle for XC16 only.

Just like the spec.txt method, I won’t really know if it works now on the Mac, because it’s Pro now anyway.

I can just as easy install this on a Windows 7 boot tonight, and try the other methods again.
I actually prefer the specs.txt way, without modification of anything, and it’s actually the project that enables it,
which could transfer between machines.

If it all works on Win 7, I’ll forgo my licence on the Mac install, and start fiddling with the Mac install again.

I’m pissed enough that I’m prepared to go and say anything on a well established account on Microchip’s own support forum
because I’m writing free, and what will become open source software with the thing!
I’m also pissed enough that I’d go look at starting again on another controller for my next project.

I only want this working for bugs others might discover.
I spent the last couple of weeks of the 60 day period looking for bugs while I could still compile.

Is this a rant yet? I’ll stop now :D







« Last Edit: January 23, 2018, 04:15:56 am by @rt »
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #242 on: January 23, 2018, 05:50:29 am »
I'm not sure otool options are the same as objdump. There are other utilities to do the job, like nm , maybe osx has nm?

nm elf-cc1

I'm not familiar with osx binary format, but 'something' should be able to give you the address of the symbol we want.

There is also the possibility Microchip uses unreleased source for the osx version, but I doubt it.

You can also use a hex editor to search for mchp_mafrlcsj in the elf-cc1 file, which would just confirm its in there.

Quote
I actually prefer the specs.txt way,
You did add the -specs=specs.txt global option I assume?
It seems odd that if you do have the global -specs option set, it should either work or get a complaining compiler- there is really no middle ground or silent failure

I tried xc16 again (with original elf-cc1), and I can get the specs file to work, and contrary to what I wrote it does not seem to make a difference if the extra line is there or not for xc16- it was required for xc32 as that needed 2 options where a blank line was required between them.

« Last Edit: January 23, 2018, 06:30:45 am by cv007 »
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #243 on: January 23, 2018, 06:01:58 am »
Thanks for sticking it out :)
I will try with Win 7 tonight. That would still be inconvenient, but workable.
I got my first Mac for writing iOS Apps for iPhone. Got sick of that soon enough,
but I ended up with a strong preference for actually using the Mac, over a Windows PC.

If the Win 7 install works the same, I don’t care then what happens to the Mac install, and can fiddle again.
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #244 on: January 23, 2018, 08:00:18 am »
I'm not sure otool options are the same as objdump. There are other utilities to do the job, like nm , maybe osx has nm?
Otool is the Mac tool for that, but macOS executables normally don't include symbol info.

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #245 on: January 23, 2018, 08:38:32 am »
Thanks for clearing that up. I don’t pretend to understand the script other than the for loop.
I’m just a programmer :D

A win installation is better than $29US a month for the free software.
I shouldn’t have even licensed it today. I should have waited to find some bug in my program.


 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #246 on: January 23, 2018, 12:33:18 pm »
I now have MPLAB-X up to date on Both Win 7 and Mac.
There was some problem with Microchip’s page, so I downloaded XC16 v 1.32B from their archive page for the Win & install.

So far the specs.txt method isn’t working. The Build window gives the same messages as the Mac version does,
that I have license restrictions and blah...
I do have cygwin installed in Win 7 too, so I can try the other tomorrow maybe.
 

Online JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #247 on: January 23, 2018, 01:41:34 pm »
actually the specs.txt method IS working for me, on win 7 win 10 and on osx 10.10

it works with XC16 v1.32 and v1.33, IDE versions 4.00, 4.05 (on windows) and 3.85 (on osx)

i attached the txt file i'm using (if for whatever reason you were generating an incorrect one)
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #248 on: January 23, 2018, 03:13:10 pm »
Well I don’t know what to say  :-//

It would be pointless to mess with the Mac install because it’s authorised now anyway,
but the Win 7 install, I used your specs.txt file, and it looks the same to me.
I have been placing it in the project root directory which is of the format PROJECT.X,
but ended up scattering copies of it in other places as well when it didn’t work.
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #249 on: January 23, 2018, 03:44:11 pm »
cygwin didn’t like one of those commands. I think it was xxd.

Can someone pm me the modified file since it’s free open source?
You may have to include the source code of the modified file right?
So can someone not only send it to me, but also take out a front page add in a newspaper that they sent it to me?
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf