Wow my hello world 16f18446 got 21 downloads

[be80be]

"This is probably stating the obvious, but in both Br@y and CoolTerm you are supposed to press the "light bulbs" in the lower right hand corner to set the DTR signal."

Not so that doesn't work you have to set the com port up in options first then open the port if you try to change it after the com port opens it hang's the port or messes up loading hex's

Then you have a problem with Linux the stty program that is used does not have a DTR command it's done with a work around to let you set dtr stty has none.

 

[Evan VENN]

Wot? I am sorry but I cannot understand. I see words but do not understand. Sorry.

 

[be80be]

Simple lol
You have to set the options first

Linux doesn't use DTR on com ports if you read the man page DTR is not really for what microchip is doing here in linux you have only a CTS command
To use the dtr you have to write a warper that set's dtr coolterm has the option to do so

 

[Evan VENN]

Dont agree.

Setting DTR will cause the new board into debug mode. Setting DTR will then change the operating status of the Microchip part in terms of the communication lines between the ATMEL part and the Microchip part.
Without DTR set the terminal should operate as normal.
I have just got off calls with Microchip and these are the correct assumptions.

 

[Evan VENN]

With respect to programming. Some insights.

The recommended CONFIG setting is LVP = 1 and MCLRE = 1 in the PIC16F18446 on this new board. Note therefore the constrained use of Re3.

I have now, with the latest firmware, programmed the hex through the mass storage drive and verified that the application flash is written correctly.
The board operates as expected when the application is programmed.

I have also completed the following test:

WRITE: 0A000E00 8F3F FE3F 9F3F FF3F FF3F 83
READ: 0A000E00 8F3F FE3F 9F3F FF1F FF3F A3

The hex writes the LVP bit to 0, as the nEDBG does not support high voltage programming and programming process flips the LVP to 1 before programming.​

All this information is missing in the Xpress user guide. This has been logged as bugs and Microchip will update the documentation.

 

[be80be]

Whatever you think setting the DTR wrong cause lot's of problems but The serial didn't work till I used coolterm and set it as shown

This tells you you have to set dtr to use the com port of the nEDBG

 

[Evan VENN]

I will share more. When you reset the new board, with the original firmware, the ATMEL firmware sets the VPC port correctly for and two bytes are transmitted to a terminal without DTR high, then VPC communications stops. When you reset the new board, with the latest firmware, the ATMEL firmware sets the VPC port correctly for 32 bytes to a terminal without DTR high, then VPC communications stops.

So, something is not correct.

 

[be80be]

Here what I don't get from what your saying the only data sheet they printed is wrong.
But this is my finding the stuff in it works as said I use Linux mostly from what I found out they cutout control of the DTR years ago so my ubuntu didn't have a way to set DTR.
But programming and debugging worked fine only the com port that didn't.
Next I gave a try on windows 10 using realterm didn't work there too found coolterm and set the options to match the datasheet and it all works now
debugging progamming and the comport

So what broke there.
It's like it said my problem was I had no program for serial in linux that let's you set the dtr and the one for windows 10 that did wasn't doing so from what i reading most any that's usb to serial don't cause DTR is really not used much for that it was used back when we had serial printers not a comport talking to a uc LOL

 

[Evan VENN]

So, something is not correct.

Something is not correct. We have bytes, valid data being transmitted. Microchip have accepted that today. They will fix the firmware.

Remind me. Do you have the same board? I posted a photo.

 

[be80be]

Mine look just like what you posted

 

[Evan VENN]

Then, wait for the firmware. The current firmware is not safe for production.

I would not be making this up. There are serious issues in the firmware.

I got this today from Product Development. I video'd the serial errors.

At 02:16 you showed that you are able to receive a many bytes at power-up / early initialization of the board.
This is unfortunate and may be related to the initialization state in the nEDBG firmware, a bug has been logged to investigate the boot state and fix the issue.​

 

[be80be]

The whole thing not safe you wouldn't use that in production you would buy a 16f18446 and make a PCB install a programmed chip LOL

 

[Evan VENN]

Did you mean.

The whole thing not safe. You wouldn't use that in production. You would buy a 16f18446, make a PCB and the install the ATMEL programmed chip.

You agree. Good.

 

[be80be]

No Id forget the SAMD21 and use a just the 16f18446 and program it with a pickit 3 or 4

 

[Nigel Goodwin]

No Id forget the SAMD21 and use a just the 16f18446 and program it with a pickit 3 or 4

Of course you would, the board under discussion is a simple development board - for any serious project you'd then move to the plain chip - in fact I got plain chips while I was waiting for the board to come

 

[be80be]

I like the 16f18446 moved on to adc the 12 bit looks fun.

I have 3 of the boards 16f18877 16f18855 and this one 16f18446

I order 3 tubes of chips the 28 pin and 40 pin of 16f18855 the 16f18875I like these newer chips

 

[Nigel Goodwin]

I order 3 tubes of chips the 28 pin and 40 pin of 16f18855 the 16f18875I like these newer chips

Yes so do I, great facilities on them.

I was planning my next project with one, but reverted to the 18F26K22 for the extra memory and twin serial ports.

 

[be80be]

I was playing with the adc it's 12 bit why an i getting 1715 when the pot is at 3.3 volts should it not be 4096

 

[be80be]

Oh forget the above post lol it was a bad pot LOL i burnt some of them up setting a 317 with them the LM317 had pinout wrong
I just changed the pot
this looks way better

That's sent out using a 32 bit buffer using hardware Interrupts
Think if I keep playing with xc8 i'll be doing something useful soon LOL

 

[Nigel Goodwin]

Just a little update to this thread, which hopefully might help others.

I've been working on a 16F18446 project for the last few days, using XC8 1.45 - and have been seriously struggling, first I couldn't get the I2C working, there were no signals on the allocated pins - and gave up on it for now. Next was the UART, the TX part was working fine, but not the RX part - after hours of struggling I decided to examine the header file (I was THAT desperate) - to find that the PPS address allocations were wrong in the header file. Editing the header file means the RX side works OK now, the I2C PPS addresses were wrong as well, and I've got signals on the pins now - but nothing 'working' yet, I may have broken some code with my previous changes to make it work.

So if you're using XC8 v1.45 be aware that PPS may not work, and if not check the header file and compare it with the datasheet.

Anyway, I've just downloaded XC8 V2.0 (I hadn't bothered before, because it basically just adds AVR support), but it also adds a correct 16f18446.h header file