Code Crashing...?

[MarkO]

@jpearman

The user processor (the STM32) communicates with the master processor (LPC2458) over SPI, not sure who initiates the SPI comms, I did know but have forgot. The master sends joystick and other control information to the user processor. The user processor sends pwm values for motor ports 2-9 to the master and a few other flags. There is also an asynchronous channel between the two used for code download and debugging. Obviously this is all conjecture on my part, I have no official details, but last summer I reversed engineered the entire IO map to see who was controlling what peripherals (all done through software using ROBOTC, nothing at the hardware level).

That is good to know… I would love to know more about the Debugging Support… That could be very Handy in EasyC…

I think the 20mS delay may be to just slow down the communication to at most 60 (or so) messages per second, I have to say I’m somewhat horrified to see it done this way but there may be a good reason we don’t know about.

Sometimes it’s the “Quick and Dirty” way to get it working… The thing is, with Interrupts and Multithreading, you Setup a Que, and have the Que emptied on a Regular Interrupt, so your not Slowing Everything Down continuing polling the Que…

I’m wondering if the user processor kicks off the SPI comms using a timer, the SPI IRQ handlers don’t have much of anything in them, they look like stubs functions. On the other hand I always thought it was the master, well, doesn’t really matter anyway.

If the Master Processor is also the SPI Master, then the User Processor might need an Interrupt to know when to feed the SPI Out Buffer. OTOH, I think I set up a 16 Byte Buffer, and filled it with a couple Messages, and there was a mechanism to transfer a Byte from the Buffer for each SPI Clocking… I will need to review that code…

We have warped brains to enjoy reading disassembled machine code originally created by a C compiler.

That reminds me that my first Serial Que project, started in 1988, was an MS-DOS program that ran fine on 80286 and 80386 processors, but in Windows 3.0 or 3.1 on a 80386 at 19,200bps, lost characters…

There were many ways to solve this Issue, because I started with a vary Inefficient way of Coding, I had many choices for improvement…

I was using TurboC 2.02, I dumped the Interrupt Service Routine ( ISR ) in Assembler, and Hand Counted the Machine Cycles for the whole ISR… What I found was that since I chose to support Multiple Com Ports, and was loading the I/O Port Address from an Array, it was too slow for each pass through the ISR, which processed One 8 Bit Character, each pass. By switching the Com Port Base I/O Address from an Array Lookup, to a Pointer Lookup, I saved 15 Machine Cycles, per ISR pass…
The end result is it now worked great at 19,200 bps in a Windows 3.0/3.1 DOS Box…

[MarkO]

@bradley4kevin

As the advisor of the 569 teams I just wanted to extend a huge Thank You for taking your time to help work out bugs like this. It saves teams like ours hours frustration. Your expertise is appreciated by Dpbailey and the rest of the 569 teams. Thank you. How would be go about reporting this to Intelitek? Thanks…Kevin

I know that jpearman like doing this kind of “work”, just like Quazar and I do…

The Learning Curve required to use all the Neat Features, like the LCD Display, would take the Beginning Programmer magnitudes more of time, if they had to be developed from Basic Code…

This is why the EasyC Libraries are Created, or the RobotC Libraries.

It gives the Less Experienced Programmers, the ability to Solve More Advanced problems…

This has been reported, and Responded to:
Using SetLCDText is causing problems in V4.1.0.1

[jpearman]

@MarkO

If the Master Processor is also the SPI Master, then the User Processor might need an Interrupt to know when to feed the SPI Out Buffer. OTOH, I think I set up a 16 Byte Buffer, and filled it with a couple Messages, and there was a mechanism to transfer a Byte from the Buffer for each SPI Clocking… I will need to review that code…

I looked back through my notes from last year. The user processor is the SPI master (0x0B65 is in the SPI_CR1 register), the communication runs at 2.25MHz (pclk/32). As it is SPI, when write is happening it is also reading, my notes say there are 16 transfers each of 16 bits (so 32 bytes total). It also looks like a couple of GPIO pins are used to supervise the transfer. GPIO PortA bit 11 and GPIO PortE bit 0, one is probably the CS (chip select) signal. The EasyC code looks like the transfer happens in 4 groups of 4 words with a small delay between each group, one day perhaps I will put a scope on the signals.

[MarkO]

@jpearman

I looked back through my notes from last year. The user processor is the SPI master (0x0B65 is in the SPI_CR1 register), the communication runs at 2.25MHz (pclk/32). As it is SPI, when write is happening it is also reading, my notes say there are 16 transfers each of 16 bits (so 32 bytes total). It also looks like a couple of GPIO pins are used to supervise the transfer. GPIO PortA bit 11 and GPIO PortE bit 0, one is probably the CS (chip select) signal. The EasyC code looks like the transfer happens in 4 groups of 4 words with a small delay between each group, one day perhaps I will put a scope on the signals.

The User Processor is the SPI Master…

A 32 Bit Processor, with 16 Bit Words???

If they use one of the Output Pins for CS, they must be expecting to have other Devices on that SPI Bus…

Thanks for the Info…

[jpearman]

This is a little off topic, however, we were discussing the SPI connection between user and master processor so it’s of interest to some.

Firstly I had posted previously that the SPI communications takes place every 15mS. This is true for ROBOTC, however, with EasyC it’s a little less often and happens every 19mS.

We have also asked before whether ROBOTC or EasyC was the better development environment. It’s common knowledge that I prefer ROBOTC but have also acknowledged that EasyC has the potential to write more complex code as it’s really just a pretty GUI over a conventional C compiler. So when it comes to looking into the inner workings or the cortex (I was going to say hacking ), EasyC certainly makes thing easier.

This little bit of code allows examination of the SPI data flowing between user and master processors, the TX data show the values for motors 2-9 (1 & 10 are handled by the user processor directly) as well as a few flags. The RX data shows values for both main and partner joysticks along with some flags indicating competition state etc. No real use to anyone but perhaps MarkO and Quazar. Call DumpSpiData() from a loop running in operator control every 50mS or so. Tested in EasyC 4.1.0.1, the globals may be different in older versions.

// MyFunc.c : implementation file
#include "Main.h"

// globals for the SPI TX and RX buffers
extern unsigned char SPI1_Buffer_Tx;
extern unsigned char SPI1_Buffer_Rx;

void DumpSpiData()
{
    unsigned char *c;
    int i;

    // Point at TX buffer
    c = &SPI1_Buffer_Tx;
    PrintToScreen("TX - ");
    
    // print out 32 bytes
    for(i=0;i<32;i++)
        PrintToScreen("%02X ",*c++);
    PrintToScreen("\n");

    // Point at RX buffer
    c = &SPI1_Buffer_Rx;

    // print out 32 bytes
    PrintToScreen("RX - ");
    for(i=0;i<32;i++)
        PrintToScreen("%02X ",*c++);
    PrintToScreen("\n\n");
}

[Quazar]

@jpearman

This is a little off topic, however, we were discussing the SPI connection between user and master processor so it’s of interest to some.

Firstly I had posted previously that the SPI communications takes place every 15mS. This is true for ROBOTC, however, with EasyC it’s a little less often and happens every 19mS.

We have also asked before whether ROBOTC or EasyC was the better development environment. It’s common knowledge that I prefer ROBOTC but have also acknowledged that EasyC has the potential to write more complex code as it’s really just a pretty GUI over a conventional C compiler. So when it comes to looking into the inner workings or the cortex (I was going to say hacking ), EasyC certainly makes thing easier.

This little bit of code allows examination of the SPI data flowing between user and master processors, the TX data show the values for motors 2-9 (1 & 10 are handled by the user processor directly) as well as a few flags. The RX data shows values for both main and partner joysticks along with some flags indicating competition state etc. No real use to anyone but perhaps MarkO and Quazar. Call DumpSpiData() from a loop running in operator control every 50mS or so. Tested in EasyC 4.1.0.1, the globals may be different in older versions.

Thanks for the nod Back during the days of the PIC microcontroller, I went through a similar exercise and sorted out the master/user communication and division of labor. I haven’t attempted that on the Cortex, so thanks very much for going through the tedious work of decoding that and posting it for all to see.

I’ve been spending most of my time recently on the VEXpro. I have to say one of the biggest selling points of the VEXpro is that Each development seat costs $0.00 and comes with full source for the development environment, the tool chain, the OS, the platform library (libqwerk), and even the firmware and FPGA.

It is refreshing to not have to reverse engineer anything. There is a lot of source to sift through, but you can see it all and make changes to any part.

Cheers,

• Dean