LPC1114 Kernel 8.35d

Description of your first forum.
Post Reply
gonzalov
Posts: 1
Joined: Fri Mar 27, 2015 9:16 pm

LPC1114 Kernel 8.35d

Post by gonzalov »

Does anybody know what changed between BasicChip Kernel 8.34a and 8.35d, that affected the PRINT instruction?

Thanks



basicchip
Posts: 1090
Joined: Fri Oct 19, 2012 2:39 am
Location: Weeki Watchee, FL
Contact:

Re: LPC1114 Kernel 8.35d

Post by basicchip »

At the beginning of 2015 we decided to make all new parts shipped run at 115Kbaud, while not real important on the 1114, it is a big deal for downloads on SuperPROs and other big Flash parts.

Could you describe what you are seeing? Our tests do extensive use of PRINT and they all are passing so we don't see any difference.

BASICtools has been modified to automatically switch from 19.2 to 115Kb. Going back is a bit of a pain, and if you find yourself with a mix of parts, let us know and we will setup a new firmware download so you can either upgrade (we prefer that) or downgrade. For our OEM customers we ship firmware to whatever their last version was.

basicchip
Posts: 1090
Joined: Fri Oct 19, 2012 2:39 am
Location: Weeki Watchee, FL
Contact:

Re: LPC1114 Kernel 8.35d

Post by basicchip »

>continued stream of this from emails

I developed an application for BasicChip with Kernel 8.34a, which worked as I wanted it to, few months ago.

I purchased 2 new BasicChips last week, which came with Kernel 8.35d, and the application didn\'t work. After updating the compiler to the latest version online, the program runs (I have a heart beat showing that my program loops properly), but seems to have problems with (at least) the PRINT instructions. It also has difficulties with baudrate setting; I can only work at 115,200 bauds to interact with the chip, but PRINT doesn\'t work properly at that baudrate

I tested again the old chip with kernel 8.34a, and it work perfectly fine with the new updated \"compiler environment\" (didn\'t recompile/downloaded to the old chip)

Is there anything I should do, to make my software compatible with the new 8.35d ? If not, Could I convert new chips / buy old 8.34a\'s to keep going with my project?

basicchip
Posts: 1090
Joined: Fri Oct 19, 2012 2:39 am
Location: Weeki Watchee, FL
Contact:

Re: LPC1114 Kernel 8.35d

Post by basicchip »

we changed over BASIC firmware to run at a default 115Kb rate at the beginning of this year, as many of our part have much larger Flash than 32K and download times were getting too long.

All the testing we did show no other differences.

While I can send you files to backup the firmware to the earlier version, I would prefer to understand what issue you see with the PRINT statement in the new firmware.

Can you describe what you are doing and what you see wrong with the PRINT statement

basicchip
Posts: 1090
Joined: Fri Oct 19, 2012 2:39 am
Location: Weeki Watchee, FL
Contact:

Re: LPC1114 Kernel 8.35d

Post by basicchip »

.... continuing with my previous message 1h ago, and after some more testing

PRINT seems to work in 8.35d if interrupts are enabled Is 8.35d (vs 8.34a) have improved PRINT in such a way that it now can work while interrupts are enabled? (so it goes back to continuing to execute PRINT even if an interrupt occurs while PRINTing)

If this is the case then:
1) Good ! thanks for the improvement
2) User manual has to incorporate the new PRINT condition
Else
1) Need to let the program to have control while
PRINTing by disabling interrupts (...I would suggest)

basicchip
Posts: 1090
Joined: Fri Oct 19, 2012 2:39 am
Location: Weeki Watchee, FL
Contact:

Re: LPC1114 Kernel 8.35d

Post by basicchip »

More than 3 years ago we converted PRINT so that it used interrupts to send characters out UART0. Prior to that the FIFO was used, so less than 16 characters could be sent out, but more than that the user BASIC program would have to wait until the UART FIFO was empty.

That transition was made before 8.34. In both versions a user BASIC program sends characters into a buffer and they will be sent out later when the interrupt indicates the TX register is available. If the user program sends more than 256 bytes to be printed it will wait until there is space in the buffer.

I think in your case what you are seeing has to do with the baud rate change and timing with your program.

Yes if you disable interrupts, PRINT will stop.

Post Reply