alexvh's firmware. Update: Hidden strobe, Ramping and optional mode memory added.

111 posts / 0 new
Last post

Pages

alexvh
Offline
Last seen: 1 year 10 months ago
Joined: 05/28/2013 - 23:40
Posts: 29
Location: Canada
alexvh's firmware. Update: Hidden strobe, Ramping and optional mode memory added.

Update: March 9, 2015 Hidden strobe mode
I’ve added a hidden strobe mode to my firmware. After 2 very short on times the light goes into a strobe mode. To access it, half press the switch as fast as you can 3 or more times. I tried to make it hard to accidentally enter strobe, but easy enough to get into it when you want to, so it requires a very short on time between presses. You pretty much have to turn it off again before you see the light. A long press is needed to exit strobe mode.
https://github.com/alexvanh/basic_off_time_driver

Update: January 17, 2015 Ramping, Optional mode memory
Hey guys, I’ve added ramping to my firmware. I tried to make it a nice smooth ramp, it’s kind of like the sleep LED on a mac or something. It uses the ram retention trick, so it won’t wear out your eeprom. You can change the code to use the default ramp() function which rises and falls /\/\/\/\, or ramp2() which is rising only /////. Just do a short press when it is ramping and that brightness level will be selected. I’ve also added mode memory (disabled by default) just uncomment #define MODE_MEMORY to enable it.

Original Post
Hey guys, I’ve been lurking here for a little while and thought I might contribute something back. I’ve been experimenting with writing firmware for NANJG drivers.

I’ve come up with a method for using off-time mode switching on stock nanjg drivers. This requires no hardware modifications, there is no need to solder any extra capacitors to the stars for example. It works by storing data in memory that does not get initialized on startup. The bypass capacitor that is already on the nanjg driver is able to supply just enough power to keep the data stored in memory for about 500ms. This happens to be a very convenient amount of time for off-time mode switching. For this to work, brown-out detection must be enabled in the fuse bits when you flash the chip.

I’ve only actually tested this with the NANJG 101-AK-A1, but it should work with the others as well.

This isn’t really meant to be a complete firmware, it’s mostly intended to demonstrate the method and allow others to add off-time mode switching to their own firmware. I plan on releasing more stuff in the future when it’s finished but I thought I would share this with you guys now. Please try it out and let me know what you think (and whether it actually works with your driver).

You can read a more in-depth description and download it here: https://github.com/alexvanh/basic_off_time_driver

My firmware for nanjg attiny13 flashlight drivers: https://github.com/alexvanh/basic_off_time_driver

Discussion: http://budgetlightforum.com/node/36932

Off-time mode switching on stock drivers (no off time capacitor mod necessary) and ramping withou

Edited by: alexvh on 03/09/2015 - 22:39
driveX
driveX's picture
Offline
Last seen: 3 months 3 weeks ago
Joined: 06/25/2012 - 07:58
Posts: 173
Location: Czech Republic

Great job, thank you! I’m willing to try this!

wight
Offline
Last seen: 2 weeks 2 days ago
Joined: 11/27/2013 - 16:40
Posts: 4968
Location: Virginia, USA

Interesting! Thanks for sharing, I’ll take a closer look at the code soon.

Break’s over for now. That was a long one! wight catchup WinkWinkWink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

FmC
FmC's picture
Offline
Last seen: 49 min 22 sec ago
Joined: 03/31/2013 - 05:23
Posts: 2124
Location: Brisbane, AU

Very interesting work!

I just flashed this to the new style(no stars) 105d.

Unable to change modes – stuck on full output.

Willing to try any suggested changes.

wight
Offline
Last seen: 2 weeks 2 days ago
Joined: 11/27/2013 - 16:40
Posts: 4968
Location: Virginia, USA

FmC wrote:
Very interesting work!

I just flashed this to the new style(no stars) 105d.

Unable to change modes – stuck on full output.

Willing to try any suggested changes.

You could try doubling up C1.

Break’s over for now. That was a long one! wight catchup WinkWinkWink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

FmC
FmC's picture
Offline
Last seen: 49 min 22 sec ago
Joined: 03/31/2013 - 05:23
Posts: 2124
Location: Brisbane, AU
wight wrote:
You could try doubling up C1.

Pinched the cap from another 105c & stacked it, but no change.

LinusHofmann
LinusHofmann's picture
Offline
Last seen: 1 year 3 months ago
Joined: 09/28/2013 - 08:27
Posts: 974
Location: Switzerland

I’m loving anything off-time at the moment so if this works reliably on a stock Nanjg, that’s fantastic news. Well done! Smile

alexvh
Offline
Last seen: 1 year 10 months ago
Joined: 05/28/2013 - 23:40
Posts: 29
Location: Canada

FmC wrote:
Very interesting work!

I just flashed this to the new style(no stars) 105d.

Unable to change modes – stuck on full output.

Willing to try any suggested changes.

Make sure brown out detection is enabled by setting the correct fuse bits when you flash it. The startup time fuse bits may be important as well. I flash it with these fuse bits: low=0×79 high=0xed

My firmware for nanjg attiny13 flashlight drivers: https://github.com/alexvanh/basic_off_time_driver

Discussion: http://budgetlightforum.com/node/36932

Off-time mode switching on stock drivers (no off time capacitor mod necessary) and ramping withou

FmC
FmC's picture
Offline
Last seen: 49 min 22 sec ago
Joined: 03/31/2013 - 05:23
Posts: 2124
Location: Brisbane, AU
alexvh wrote:
Make sure brown out detection is enabled by setting the correct fuse bits when you flash it. The startup time fuse bits may be important as well. I flash it with these fuse bits: low=0×79 high=0xed

Yes, I used those fuse bits when flashing.

WarHawk-AVG
WarHawk-AVG's picture
Offline
Last seen: 1 month 4 days ago
Joined: 01/04/2014 - 06:47
Posts: 5048
Location: H-Town

Oh wow…so this method of doing the code could actually replace the OTC on ALL the builds correct?

Very awesome build and very very slim on the coding…

Interesting method for making the levels..

Quote:
// set noinit data for next boot noinit_decay = 0; noinit_mode = mode + 1; switch(mode){ case 0: PWM_LVL = 0xFF; break; case 1: PWM_LVL = 0×40; break; case 2: PWM_LVL = 0×10; break; case 3: PWM_LVL = 0×04; break;

are the 0x** numbers written in HEX?

Welcome to the coding fray good sir Wink
most importantly, welcome to the forum!

Awesome first few posts Smile

alexvh
Offline
Last seen: 1 year 10 months ago
Joined: 05/28/2013 - 23:40
Posts: 29
Location: Canada
FmC wrote:
alexvh wrote:
Make sure brown out detection is enabled by setting the correct fuse bits when you flash it. The startup time fuse bits may be important as well. I flash it with these fuse bits: low=0×79 high=0xed

Yes, I used those fuse bits when flashing.

Hmm, I have only tested this method with the nanjg 101-AK-A1. It is possible that there are hardware differences that break this method. What resistors does the 105d use for the voltage divider? Do you have any way of measuring the capacitor?

Maybe try a low fuse of 0×75, I’ve found that also works. Maybe also try raising the brown out detect voltage to 2.7V by setting the high fuse to 0xeb. Maybe some combination of these will work.

Also, has anyone else tested this with their hardware and had success or failure? I’m interested to see which drivers this works for.

Edit: Also did you compile it from source yourself or did you use the hex file I compiled?

My firmware for nanjg attiny13 flashlight drivers: https://github.com/alexvanh/basic_off_time_driver

Discussion: http://budgetlightforum.com/node/36932

Off-time mode switching on stock drivers (no off time capacitor mod necessary) and ramping withou

alexvh
Offline
Last seen: 1 year 10 months ago
Joined: 05/28/2013 - 23:40
Posts: 29
Location: Canada

WarHawk-AVG wrote:
Oh wow…so this method of doing the code could actually replace the OTC on ALL the builds correct?

Very awesome build and very very slim on the coding…

Interesting method for making the levels..

Quote:
// set noinit data for next boot noinit_decay = 0; noinit_mode = mode + 1; switch(mode){ case 0: PWM_LVL = 0xFF; break; case 1: PWM_LVL = 0×40; break; case 2: PWM_LVL = 0×10; break; case 3: PWM_LVL = 0×04; break;

are the 0x** numbers written in HEX?

Welcome to the coding fray good sir Wink
most importantly, welcome to the forum!

Awesome first few posts Smile

Thanks.
I’m not sure what you mean by OTC? I think this could be used on all the builds to get off-time memory. It’s a bit of a hack and I’ve only tested it on a few drivers, so I’m interested to see if others are able to get it working reliably as well.

Yes the 0x in front makes it hex. It’s the same as 255, 64, 16, and 4.

My firmware for nanjg attiny13 flashlight drivers: https://github.com/alexvanh/basic_off_time_driver

Discussion: http://budgetlightforum.com/node/36932

Off-time mode switching on stock drivers (no off time capacitor mod necessary) and ramping withou

wight
Offline
Last seen: 2 weeks 2 days ago
Joined: 11/27/2013 - 16:40
Posts: 4968
Location: Virginia, USA

WarHawk-AVG means “off time capacitor”.

Break’s over for now. That was a long one! wight catchup WinkWinkWink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

FmC
FmC's picture
Offline
Last seen: 49 min 22 sec ago
Joined: 03/31/2013 - 05:23
Posts: 2124
Location: Brisbane, AU

alexvh wrote:
Hmm, I have only tested this method with the nanjg 101-AK-A1. It is possible that there are hardware differences that break this method. What resistors does the 105d use for the voltage divider? Do you have any way of measuring the capacitor?

Maybe try a low fuse of 0×75, I’ve found that also works. Maybe also try raising the brown out detect voltage to 2.7V by setting the high fuse to 0xeb. Maybe some combination of these will work.

Also, has anyone else tested this with their hardware and had success or failure? I’m interested to see which drivers this works for.

Edit: Also did you compile it from source yourself or did you use the hex file I compiled?

Sorry, I can’t measure the Caps. The resistor values are the same between the 101, 105c, & 105d.

I compiled the code from source using AVR Studio 5.1

I’ll try the different fuse values & report back.

FmC
FmC's picture
Offline
Last seen: 49 min 22 sec ago
Joined: 03/31/2013 - 05:23
Posts: 2124
Location: Brisbane, AU

Ok – I thought I’d try your pre-compiled hex first, & it worked on the 105d.

At that point I still had the additional Cap on the board, which I removed, & tested successfully again after the removal.

Success!

What I didn’t realize though, untill re-reading your Readme & OP, is that it is off-time memory switching , rather than off-time memory.

If this method can be implemented to save the current mode as well, I’m sure there will be a lot of happy people!

Great work, oh & welcome to BLF! Beer

alexvh
Offline
Last seen: 1 year 10 months ago
Joined: 05/28/2013 - 23:40
Posts: 29
Location: Canada

FmC wrote:

Sorry, I can’t measure the Caps. The resistor values are the same between the 101, 105c, & 105d.

I compiled the code from source using AVR Studio 5.1

I’ll try the different fuse values & report back.

Maybe you also try the hex file I’ve uploaded on github as well? There could be a difference in the way it is being compiled.

I tried replacing the 10uF capacitor on the 101 driver I was using with a 5uF (approximate values) from a 105c and it works fine with either of them. So I don’t think it is the hardware.

I’m compiling it on linux using the commands below:

avr-gcc -g -Wall -Os -mmcu=attiny13 -c driver.c
avr-gcc -g -Wall -mmcu=attiny13 -c driver.c -o driver.elf driver.o
avr-objcopy -j .text -j .data -O ihex driver.elf driver.hex

and flashing it using:

avrdude -p t13 -c usbtiny -u -Uflash:w:driver.hex:a -Ulfuse:w:0×79:m -Uhfuse:w:0xed:m

My firmware for nanjg attiny13 flashlight drivers: https://github.com/alexvanh/basic_off_time_driver

Discussion: http://budgetlightforum.com/node/36932

Off-time mode switching on stock drivers (no off time capacitor mod necessary) and ramping withou

FmC
FmC's picture
Offline
Last seen: 49 min 22 sec ago
Joined: 03/31/2013 - 05:23
Posts: 2124
Location: Brisbane, AU

cross-post…. Smile

wight
Offline
Last seen: 2 weeks 2 days ago
Joined: 11/27/2013 - 16:40
Posts: 4968
Location: Virginia, USA

FmC wrote:
Ok – I thought I’d try your pre-compiled hex first, & it worked on the 105d.

At that point I still had the additional Cap on the board, which I removed, & tested successfully again after the removal.

Success!

What I didn’t realize though, untill re-reading your Readme & OP, is that it is off-time memory switching , rather than off-time memory.

If this method can be implemented to save the current mode as well, I’m sure there will be a lot of happy people!

Great work, oh & welcome to BLF! Beer

Sounds good. Alexvh’s method should adapt fine to the “normal” style of offtime memory rather than “offtime no memory”. Both the cap and this new method could be considered flags: the same method of keeping track of modes used by STAR_off_time is fine.

Break’s over for now. That was a long one! wight catchup WinkWinkWink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

alexvh
Offline
Last seen: 1 year 10 months ago
Joined: 05/28/2013 - 23:40
Posts: 29
Location: Canada

FmC wrote:
Ok – I thought I’d try your pre-compiled hex first, & it worked on the 105d.

At that point I still had the additional Cap on the board, which I removed, & tested successfully again after the removal.

Success!

What I didn’t realize though, untill re-reading your Readme & OP, is that it is off-time memory switching , rather than off-time memory.

If this method can be implemented to save the current mode as well, I’m sure there will be a lot of happy people!

Great work, oh & welcome to BLF! Beer

Oops, I posted before seeing your reply. So yes, it seems they are being compiled differently. We should try to figure out what’s different so that people compiling with AVR studio have the right options set.

The flashlight terms can be a little confusing, but I think I know what you are asking. Yes mode memory can be added to this using the eeprom just like in the other drivers. I’ll upload a version with that soon. So that the light turns on in the mode it was previously left on in (unless it is a short press, in which case it comes on in the next mode). This was mostly meant to show how it works and what can be done using this method. I wanted to show that you don’t have to use the eeprom at all unless you want mode memory.

My firmware for nanjg attiny13 flashlight drivers: https://github.com/alexvanh/basic_off_time_driver

Discussion: http://budgetlightforum.com/node/36932

Off-time mode switching on stock drivers (no off time capacitor mod necessary) and ramping withou

FmC
FmC's picture
Offline
Last seen: 49 min 22 sec ago
Joined: 03/31/2013 - 05:23
Posts: 2124
Location: Brisbane, AU

alexvh wrote:
Oops, I posted before seeing your reply. So yes, it seems they are being compiled differently. We should try to figure out what’s different so that people compiling with AVR studio have the right options set.

The flashlight terms can be a little confusing, but I think I know what you are asking. Yes mode memory can be added to this using the eeprom just like in the other drivers. I’ll upload a version with that soon. So that the light turns on in the mode it was previously left on in (unless it is a short press, in which case it comes on in the next mode). This was mostly meant to show how it works and what can be done using this method. I wanted to show that you don’t have to use the eeprom at all unless you want mode memory.

I’m certainly no expert with AVR Studio, but I can try suggestions for different settings to compile & test. I know there has been a few minor differences in versions of AVR Studio that have caused hick-ups in the past.

wight wrote:
Alexvh’s method should adapt fine to the “normal” style of offtime memory rather than “offtime no memory”. Both the cap and this new method could be considered flags: the same method of keeping track of modes used by STAR_off_time is fine.

I figured that should be the case. This is a real nice chunk of meat for the programmers here Beer

Mike C
Mike C's picture
Offline
Last seen: 18 hours 16 min ago
Joined: 01/22/2014 - 08:03
Posts: 2030
Location: Sweden

Good stuff! Maybe this method can’t replace the short, medium and long press with the off time cap but it will surely make the stock driver much better. Thanks for sharing.

tterev3
Offline
Last seen: 7 hours 22 min ago
Joined: 03/28/2014 - 11:22
Posts: 247
Location: NC, USA

I can confirm that this method works well, it’s what I use on all power cycle lights, and implemented on a PIC in my code example here: http://budgetlightforum.com/node/30556#comment-569012

DrJones
DrJones's picture
Offline
Last seen: 2 years 6 months ago
Joined: 01/05/2011 - 13:30
Posts: 1044
Location: Frankfurt, Germany

I found off-time memory via RAM retention some months ago, too. It's a known behavour with PICs, and I've seen tterev3 use it, but less known for AVR since it requires disabling the initialization the compiler does by default.

It worked, and I was quite excited at first, planned to make an off-time version for lucidrv with it, but found that the time was a bit too short on my test NANJGs to be comfortable; it required a decisively short tap and would often not recognize a 'normal' tap. So I didn't pursue that further and instead made a version for an off-time cap.

BTW, it's the voltage divider that pulls voltage below RAM retention level so fast. One could use double values for both resistors to make it more comfortable, but then again, adding a cap is easier than that. Without the divider, the driver held the 'cookie' (the value I used for RAM retention checking) for 10 minutes.

Also, if you want memory, you still need to store the mode in EEPROM.

Edit: I didn't use brown-out detection.

wight
Offline
Last seen: 2 weeks 2 days ago
Joined: 11/27/2013 - 16:40
Posts: 4968
Location: Virginia, USA

DrJones wrote:

I found off-time memory via RAM retention some months ago, too. It’s a known behavour with PICs, and I’ve seen tterev3 use it, but less known for AVR since it requires disabling the initialization the compiler does by default.

It worked, and I was quite excited at first, planned to make an off-time version for lucidrv with it, but found that the time was a bit too short on my test NANJGs to be comfortable; it required a decisively short tap and would often not recognize a ‘normal’ tap. So I didn’t pursue that further and instead made a version for an off-time cap.

BTW, it’s the voltage divider that pulls voltage below RAM retention level so fast. One could use double values for both resistors to make it more comfortable, but then again, adding a cap is easier than that. Without the divider, the driver held the ‘cookie’ (the value I used for RAM retention checking) for 10 minutes.

Also, if you want memory, you still need to store the mode in EEPROM.

 

 

 

 

Thanks for the additional info DrJones. This sounds like it may be an effective dodge for the Tiny10’s lack of EEPROM (offtime / no memory with high-value voltage divider resistors).

That said, who wants to fool with the Tiny10? :~

I think it is also not possible to tune offtime periods in firmware with this method. With the OTC method those who do flashing can easily tune the values if desired.

Break’s over for now. That was a long one! wight catchup WinkWinkWink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

DrJones
DrJones's picture
Offline
Last seen: 2 years 6 months ago
Joined: 01/05/2011 - 13:30
Posts: 1044
Location: Frankfurt, Germany

Here's my code with memory, based on MiniDrv:

 

#define F_CPU 4800000                    //use fuses  low:0x75  high:0xff
#include <avr/io.h>
#include <util/delay.h>

//change modes here; just change/add/delete values
uint8_t modes[]={8,90,255}; //PWM values, 5..255

#define NOINIT __attribute__ ((section (".noinit")))

volatile NOINIT uint16_t cookie;

int main() {

DDRB=2; //define PB1 as output

EEARL=4;EECR=1; uint8_t mode=EEDR; //read from EEPROM

if (cookie==1338) {
mode++;
}
//else mode=0; //NOMEM
cookie=1338;

if(mode>=sizeof(modes)) mode=0; //wraparound, also check if invalid
EEDR=mode; EECR=4;EECR=4+2; while(EECR&2); //write mode to EEPROM

uint8_t lvl=modes[mode];
TCCR0A=0b00100001; TCCR0B=0b00000001; //PWM setup, 9kHz
OCR0B=lvl; //set PWM level

while(1) {} //endless loop
}
 
alexvh
Offline
Last seen: 1 year 10 months ago
Joined: 05/28/2013 - 23:40
Posts: 29
Location: Canada
DrJones wrote:

I found off-time memory via RAM retention some months ago, too. It’s a known behavour with PICs, and I’ve seen tterev3 use it, but less known for AVR since it requires disabling the initialization the compiler does by default.

It worked, and I was quite excited at first, planned to make an off-time version for lucidrv with it, but found that the time was a bit too short on my test NANJGs to be comfortable; it required a decisively short tap and would often not recognize a ‘normal’ tap. So I didn’t pursue that further and instead made a version for an off-time cap.

BTW, it’s the voltage divider that pulls voltage below RAM retention level so fast. One could use double values for both resistors to make it more comfortable, but then again, adding a cap is easier than that. Without the divider, the driver held the ‘cookie’ (the value I used for RAM retention checking) for 10 minutes.

Also, if you want memory, you still need to store the mode in EEPROM.

Edit: I didn’t use brown-out detection.

Do you have a way of measuring how much off time you can have before the cookie expires? I’ve found I can get about 500ms of off time before the memory decays with the capacitor on the 101 driver (I measured it to be about 10uF). If I swap it with one from a 105C driver (about 5uF) I find I can still get about 400ms. When I’m using my flashlight normally, I find I press the switch for 200-300ms. I find that this method works fine for me. I’ve been using it in my flashlight for a little while now and I’m happy with it.

I’m curious if you found it was too small based on personal preference, or if the max off time was just shorter in your experiments.

My firmware for nanjg attiny13 flashlight drivers: https://github.com/alexvanh/basic_off_time_driver

Discussion: http://budgetlightforum.com/node/36932

Off-time mode switching on stock drivers (no off time capacitor mod necessary) and ramping withou

tterev3
Offline
Last seen: 7 hours 22 min ago
Joined: 03/28/2014 - 11:22
Posts: 247
Location: NC, USA

On my drivers with pics I’ve seen greater than 10 seconds. This is without a voltage divider, so there’s no significant drain on the capacitor. Usually I tune the time to be where I want by adding a resistor in parallel with the cap. My normal combination is 2.2uF and 150k for about a half second timeout, which is my personal preference for this type of UI

Cereal_killer
Cereal_killer's picture
Offline
Last seen: 3 hours 33 min ago
Joined: 07/22/2013 - 13:10
Posts: 3263
Location: Columbus, OH USA Earth

DrJones wrote:

Here's my code with memory, based on MiniDrv:

 

#define F_CPU 4800000                    //use fuses  low:0x75  high:0xff
#include <avr/io.h>
#include <util/delay.h>

//change modes here; just change/add/delete values
uint8_t modes[]={8,90,255}; //PWM values, 5..255

#define NOINIT __attribute__ ((section (".noinit")))

volatile NOINIT uint16_t cookie;

int main() {

DDRB=2; //define PB1 as output

EEARL=4;EECR=1; uint8_t mode=EEDR; //read from EEPROM

if (cookie==1338) {
mode++;
}
//else mode=0; //NOMEM
cookie=1338;

if(mode>=sizeof(modes)) mode=0; //wraparound, also check if invalid
EEDR=mode; EECR=4;EECR=4+2; while(EECR&2); //write mode to EEPROM

uint8_t lvl=modes[mode];
TCCR0A=0b00100001; TCCR0B=0b00000001; //PWM setup, 9kHz
OCR0B=lvl; //set PWM level

while(1) {} //endless loop
}
 

Warning very basic question (I'm not really using Atmel studio at all anymore)... Where do you find / add the include files? Or does 6.2 do that all on its own at compile time?

Always remember SPC Joey Riley, KIA 11/24/14.

wight
Offline
Last seen: 2 weeks 2 days ago
Joined: 11/27/2013 - 16:40
Posts: 4968
Location: Virginia, USA

Cereal_killer wrote:
Warning very basic question (I’m not really using Atmel studio at all anymore)… Where do you find / add the include files? Or does 6.2 do that all on its own at compile time?
That’s the purpose of the includes. They are brought in at compile time by the compiler. This is a pretty universal thing, not limited to Atmel studio or even to the C programming language family. http://en.wikipedia.org/wiki/Include_directive

Break’s over for now. That was a long one! wight catchup WinkWinkWink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

Cereal_killer
Cereal_killer's picture
Offline
Last seen: 3 hours 33 min ago
Joined: 07/22/2013 - 13:10
Posts: 3263
Location: Columbus, OH USA Earth

Yea I get what they are, PIC used them in EVERYTHING (MPLAB 8.x) but you have to manually add them to the project tree. So in AS6.2 you don’t have to do anything at all but name them and the compiler handles looking them up?

Always remember SPC Joey Riley, KIA 11/24/14.

wight
Offline
Last seen: 2 weeks 2 days ago
Joined: 11/27/2013 - 16:40
Posts: 4968
Location: Virginia, USA

Sure. I’ve never had to do anything manual to get includes working… in Atmel Studio, in other IDE’s, on the CLI, etc… it’s strange to me that MPLAB requires you to do something special to get includes to work… but sure enough, Google shows exactly the kind of thing you are talking about… http://microchip.wikidot.com/xc16:set-the-include-directory-path

Break’s over for now. That was a long one! wight catchup WinkWinkWink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

Pages