PIC18F25Q43 serial combiner - possible?

Hi Folks,

I have a project in mind that will combine 3 incoming serial streams into 1 which is then streamed via a 4G modem. All are 9600,8,n,1 with different start headers so can be identified on the receive end.

The first serial string consists of 50-60 bytes of various data (much like a GPS string) incoming at 10 strings per second (10hz). The other two strings are around 15 and 20 bytes repeated at 1hz. I'd like to receive all 3 strings, process/filter wanted parameters then combine the data into one string for sending via a modem (baud rate preferably still 9600 but higher speeds if necessary). All in real time and without missing samples.

I have some 18F25Q43 (with 5 UART on board) samples on the way but then a quick check of MeLabs' device list shows no support for the Q41 (3 UART) or Q43 families. I've emailed them but don't expect anything to change anytime soon. Other compilers support the Q family but my preference is to use PBP3 wherever possible.

Can the above be done with a 2 UART device and a software (Serin2) 3rd serial port?

Any suggestions or guidance appreciated.

Kind regards,
Bill

First off, the newest version of PBP3.1 does indeed support the Qxx families. If you still use PBP 3.0 you will need to upgrade. If you already have PBP 3.1, just go to the ME Labs site & download the free update.

Secondly, receiving data from several UART sources is easy. Just create variables/buffers to store the data as it comes in, then filter through at your convenience. I would use interrupt driven RX so no data is lost (as opposed to polling). This is a job for DT_Interrupts or ASM interrupts (definitely not "ON INTERRUPT GOTO").

Thirdly, since the newest PBP 3.1 supports the Q43, your other question becomes irrelevant.

Quote:

---

Originally Posted by mpgmike

First off, the newest version of PBP3.1 does indeed support the Qxx families.

---

Hi. I can't find that documented anywhere on the ME site? Do you have a link?

On the Melabs forum, see this thread:
https://support.melabs.com/forum/pic...fxxq43-support

Specifically post #32 where there's a download link to the beta version of PBP supporting Q43 devices but also post #49 where updated/corrected library files are available (to replace those that comes in the 3.1.4.4 download).

Get input data into buffers, parse with ARRAYREAD, populate output buffer and send. Might be a good candidate for some DMA-action :-) I wonder how hard it would be to make DT-Ints work on this device, I have a Q43 devboard on the bench, using it to write code for MCP25625 at the moment but have not tried anything DT-ints yet. Oh, the vectored interrupts is tempting too. I'm rambling so I'll just shut up now :-)

Hi Henrik,

Thanks for the info, don't you EVER shut up - ramblings and all, your input is always welcome and appreciated.

I don't have 3.1 but this is the excuse I've been looking for to upgrade... I assume there is some knowledge around to access > 2 USARTs with PBP3?

Please let us know if you are successful with DTInts using the Q family device too.

Kind regards,
Bill

I find it simpler to read the data sheets and work with the SFRs using simple PBP BASIC code rather than trying to manipulate PBP commands to do something that didn't exist when the PBP commands were created. Specifically, DMA is awesome, but there aren't any PBP commands to make working with it easy. Essentially, you have to trudge through the DMA SFRs to get it to work. By the time we get to the Q43 series, there are so many new peripherals that simply didn't exist when PBP was created, we have to work with the SFRs. I get frustrated when I see posts where folks are trying to use inadequate PBP commands to do stuff the PIC itself is amply capable of.

With that said, the PIC18F27Q43 will easily accomplish your goals, but you may have to get creative with what and how you implement your ideas using PBP3. Fortunately Microchip does include example code in ASM and XC8 for most of their peripherals. Furthermore, there are usually Application Notes and/or Technical Bulletins expanding peripheral usage applications. Just parse through what the foreign code is trying to accomplish and apply it to PBP. I did it, so it is possible -- after all, I'm not any smarter than anybody else.

Thanks Mike, that's good advice but... I'm not an ASM or XC8 person which is why I use PBP and just made the upgrade purchase online (thanks Henrik).

My knowledge of C is very limited but if I have to I'll have a go, assuming PBP doesn't come to the party soon enough, but that then begs the question: what's the use of PBP if it is relegated to dinosaur chips?

Kind regards,
Bill

I agree with mpgmike, 100%.
Really, the only three PBP commands I can think of that targets hardware peripherals are ADCIN, HPWM and HSERxxx (well, the EEPROM and READ/WRITECODE too of course). For everything else (SPI, I2C, DAC, CLC, CWG, CMP, NCO, FVR, DSM, SMT, ZCD, DMA and so on), you need to twiddle the registers yourself - it's always been that way and I bet to say it's not going to change. That's NOT to say you can't USE those peripherals, in fact it's quite the opposite. Most of the time it's only a couple of registers while in some cases it's more complicated (like with built in CAN).

Take the DAC in the Q43 for example, there's one configuration register and one data register. Set the config register once according to your preferences (or change it at will) and then write to the data register ( DAC1DTL = xxx ) whenever you want the output to change. You really don't need a DACOUT command for that now, do you?

Peripherals today are a lot more advanced/capable than before, take the Q43 UART for example, doing DALI and DMX or the new(ish) ADCC module. Even if ADCIN supports it in, like, legacy mode you're not taking advantage of the peripherals capabilites by just using ADCIN. It's not realistic to expect PBP to have "commands" for every permutation of every peripheral in every PIC. Instead, try to write reusable code and supbroutines FOR the peripherals USING the basic PBP commands.

With that said, the HSERxxx commands are just damn convenient and I certainly wouldn't mind having built in support for more that two :-) A "trick" I've used is to use the two UARTS supported by HSERxxx and multiplex them with the PPS feature. This isn't always applicable of course.

The thing is that you HAVE to allow yourself time. If you expect to sit down and have everything working in 30 minutes you're either extremely good or extremely naive.

a bit more detail on the streams would not go astray , i expect the streams are not synchronized in any way, don't have fixed lengths, the length is not embedded in the stream and that there is no discernable end of tx char and for full inconvenience there is no flow control. you will need a good strategy not to get mixed messages, bit banging serial in or out will be near impossible, q43 looks good to me.
in the olden days 90's we had these things called print sharers . 8 pc's 1 serial printer they managed ok somehow

Well said Henrik! If you aren't willing to spend some time with the data sheet and learn how to use the cool stuff on the newer PICs, just stick with your antiquated "Model T's" and do what you can. As Henrik said, most of the built-in peripherals require manually manipulating SFRs anyways. PBP commands regarding SPI and I2C (and I think PWM commands) aren't even using the built-in peripherals but accomplishing the functionality with software.

One of the most prolific contributors to the PBP community was the late Daryl Taylor. He was not the creator of PBP; he got involved after PBP was somewhat mature. He learned ASM by writing PBP code, then opening the .asm file to see what PBP did. In every data sheet is an Instruction Summary that lists the ASM commands and what they effectively do. You wouldn't need to become a master ASM programmer to learn enough to follow the bouncing ball. As for C code (XC8), with the exception of the "printf" type commands, you'd be surprised how much of it makes sense when you look at it. Of course, you'll never know until you try. Live life on the edge, my friend!

Thanks gentlemen, all good information.

Of course the only real method of achieving success is to put the 'hands on' and work my way through it, it's a background task and will take time but I'm sure the fruits of success will be very sweet.

@Richard
Your assumptions are correct mate, however each of the incoming streams end with CRLF and also have distinct start headers (as mentioned a bit like GPS NMEA strings) so there is hope. If you don't have any Richard I can post a couple of the Q43 to you when I receive samples because I'm sure to ask for help at some stage (same address?) - you have my email address from before however please change the gmail to yahoo, otherwise the same.

The print sharers would have only worked with handshaking I reckon.

Cheers,
Bill in Perth

Quote:

---

I can post a couple of the Q43

---

i have some 26q43 you sent me earlier thanks, but have not gone to 3.1 either yet.
you could consider something like the esp 32, it could probably do it while still asleep [has 3 uarts]


a few sample messages from each source would be handy to test with [hex list maybe]