How long does this take to execute

[HenrikOlsson]

DMX512 by any chance?
If you really need a continous stream at 250k baud then I think you need to some careful planning (and I guess that IS what you're doing with these test so thumbs up!).
At 250k baud you've only got 40us to do stuff Before you need to feed the next byte the UART (well you CAN wait up to 80us since there'a basically a single byte buffer) between each byte.

[dsicon]

yes, DMX
Jeff did it for me many years ago @4MHz, but it was 100% assembler, i don't think picbasic was around then

and there was much less other stuff to do on that one than this new one which is on the boards now, less channels, less functionality
what about the Instant Interrupts ? would that help here ?
do i need an 18F for that ?

[HenrikOlsson]

The correct 18F would allow you to run at 64MHz while I believe the 16F tops out at 32MHz but I might be wrong, haven't verified. Another benefit is that an 18F series device will allow you to have a single 512byte wide array for your DMX data. This doesn't work in the 16F series (max array length is 96). I'm not saying it can't be done on a 16F series just that I think you need some good reasons for selecting a 16F series chip over an 18F series device.

DT-Ints (Instant interrupts) is available for both 16F and 18F series so that doesn't matter but for this application I'm not entirely sure they're the correct aproach, especially if you're writing the ISR in PBP (which you are since you're using DT-Ints.....). The reasom I'm not too sure they're the right aproach is the overhead they add due to the system variable save/restore it has to do each time an interrupt occurs. This takes dozens and dozens of instruction cycles and at an interrupt rate of 25kHz it's going to eat away you're processing power.

With that said there are ways around that but they're not straight forward and you really need to know what you're doing so instead I'd look at one large loop type program calling tight subroutines with known execution time(s) and keep feeding the UART in between. Like,

* Feed the UART - OK, we've got 40us to do something useful.....
* Start the ADC - it'll take xx us to complete - go do something else....
* Read a pin
* Do something with it
* Write a pin
* Wait for the UART, Feed it.
* ADC done? Get result.
* Start ADC, next channel.

And so on.

An interrupt driven sender would be cleaner and if "all" the ISR is doing is indexing a 512 byte long array then examining the generated code and manually saving ONLY the system variables actually USED by the ISR will make DT-Ints work a lot faster but as I said, it's tricky and a very sensitive and delicate way of doing it from a code maintanence and expansion perspective.

/Henrik.

[dsicon]

incredibly helpful!, thanks so much again Henrik
want a job ?

[HenrikOlsson]

Glad I could help.
As for the job, I'm fortunate to have one that pays the bills but it's not as fun as developing PBP code so if you're serious about that then drop me PM and we can talk :-)

[dsicon]

it almost makes want to think about external hardware UART that has a 512 or 1k buffer, but i guess getting the data into that would be an issue too
are there such things ?

[HenrikOlsson]

Took a quick look at the Digikey and of the chips they've got the largest FIFO buffer available is 256bytes. I think you need at least 1k to really benefit from an external UART - and I think the interface would have to be parallel or really fast SPI or you'll spend most of the time sending data to the UART just as you would when using the on chip UART.

What would be ideal is a PIC with DMA but that feature doesn't exist in the 16F or 18F series. But really, this should be totally doable with a PIC and on chip UART but it'll take some careful planning.

/Henrik.