Hi N,How much data?, how often?, and does it need to be permanently stored?.
To cope with pretty well anything, I would suggest adding a FRAM memory chip, like EEPROM but much faster to write to (no delays required). You can get them as I2C or SPI, I use I2C ones - and the exact same code as for external I2C EEPROM's, with the simple change of using a #define to remove the write delays. The ones I use are 32KByte.
Hi R,Definitely not EEPROM - it has a limited life and is slooow...
Use a character array or data structure in RAM.
In which case the data eeprom is probably fine, as you don't need much space - the data EEPROM has a MUCH higher number of write cycles than the program memory, which would be a very bad idea.Hi N,
At the moment, there are 35xBYTES, this may grow slightly, but I don't predict by much.
It would take a lot of re-design to add a chip, so if possible I would like to use the 18F4431 PIC memory.
C.
Hi N,In which case the data eeprom is probably fine, as you don't need much space - the data EEPROM has a MUCH higher number of write cycles than the program memory, which would be a very bad idea.
But you mention 'continually', and give no idea how fast that is - it could be 'continually on the first of every month', you also give no idea how fast 'fast' is - but as you're using the data EEPROM, presumably you really meant 'slow'.
If by 'continually' you mean every few milliseconds for ever, then get a FRAM - even the data EEPROM will soon wear out at that usage.
Perhaps you might like to explain exactly what you're trying to do?, and why you feel this would be the best way? - it seems like you've not thought it through, and not paid attention to the original hardware design either. Storing it in GPR's (RAM) would make the most sense, and if you need it storing, then store it to EEPROM when the device shuts down - a little hardware design would allow you to do so if the power fails.
Hi T,Don't store the data in program memory or eeprom, and don't use absolute memory addresses.
Think of the "read address byte 0" request form the master as "read parameter #0", and then the slave can read/write the data from where ever it needs to. That way as things change in the slave it won't effect the master commands.
I'm totally confused as to what you're trying to to do? - but you seem to be making it vastly more complicated than it need be?. But there seems to be zero reason for writing to non-volatile memory?.Hi N,
This is part of a project, I've been working on for years, and you've contributed to it before.
During the project things have been changed, so what worked before, may not be able to work as it was then.
The PIC is an 18F4431, and has QEI, voltage measurements and GPS DATA, which needs to be sent to the MASTER PIC when called for.
It has been working, but so far never got in SYNC, I think because of timing.
There are other SLAVE peripherals connected to the MASTER via SPI e,g, Altimeter, compass etc, all working happily.
When the PIC as SLAVE is chip selected, it's DATA needs to be sent via SPI also.
In the other peripherals a READ ADDRESS BYTE is sent to them, and they look in that addresss for that DATA.
After many exchanges on this and other forums, no accurate solution has appeared, so I'm trying to guess how a peripheral would store DATA in its memory, so that I can emulate it with this PIC.
I have now succeded in storing DATA in this PICs memory, as mentioned, so next I want to get the MASTER to request it and prove this works.
If it works, then I can change thing a bit and change the type of memory, i,e, RAM.
EDIT: The DATA is READ by the SLAVE PIC and put in RAM, but I need to PARSE out BYTEs for SPI to MASTER, so maybe it can be done by READing the actual RAM?
C
// list of incoming commands to search for
#define NumCommands 13
char master_list[NumCommands][10] = {
"READING=",
"SIGNAL=",
"NETWORK",
"APNOK",
"BATTERY=",
"SHUTDOWN=",
"NETFAIL",
"APNFAIL",
"ESP32=",
"OK",
"REPLY",
"IMEI=",
"ERROR="
};
Hi N,I'm totally confused as to what you're trying to to do? - but you seem to be making it vastly more complicated than it need be?. But there seems to be zero reason for writing to non-volatile memory?.
If I'm using two PIC's (or one PIC, and say an ESP32 etc.) I simply connect them via a two wire serial (RS232 style) interface.
Both devices are sat looking to receive serial data, and doing anything else that needs doing in the meantime - one could be updating the display, the other could be reading sensors. So the master could send a command to the slave, asking for a specific reading (for example battery voltage), the slave returns the value, and the master processes it (if needed) and displays it accordingly. Likewise, the slave may discover an event that the master needs to know about - like the battery is below acceptable voltage, and it can then send a command to the master informing it of the issue, and the master can take appropriate action, such as shutting the unit down.
A big advantage of this type of connection (other than it's simplicity) if that you can test each part individually using a terminal program on a PC.
One of my current two processor projects uses a PIC and an ESP32 with a SIM800 modem - the commands received from the ESP32 are these:
C:// list of incoming commands to search for #define NumCommands 13 char master_list[NumCommands][10] = { "READING=", "SIGNAL=", "NETWORK", "APNOK", "BATTERY=", "SHUTDOWN=", "NETFAIL", "APNFAIL", "ESP32=", "OK", "REPLY", "IMEI=", "ERROR=" };
Some are single words (NETWORK, OK etc.), while ones that end in '=' have values, one or more, delimited with commas, attached to them. Once a full command (terminated by CR/LF) is received, the data is parsed and processed accordingly.
The serial ports are all interrupt driven, and use a circular buffer large enough to hold more than the largest anticipated data, so there's no issue with it missing any commands.
The slave operates in a similar manner, with a list of available commands to look for.
The PIC part does display, keyboard reading, and battery charging (including the actual buck PWM charging generation), the ESP32 does all the modem related stuff. Oh, and the PIC also stores any altered settings in EEPROM, so that next time you turn it ON, it comes on set to how you left it - it's a nice feature of most PIC's.
Hi P,Why can't you just use a variable array for this? Why store and retrieve it from memory?
There is no timing?, or 'synchronisation', it's not working because you don't know what you're doing and you're making it FAR too complicated. As we've explained, one device simply sends a request to the other one, the second one replies - end of story. It's easier to do via serial (and takes less pins), and far easier to debug and develop (as you can use a PC to test it in sections), but doing it via SPI would work just as well, just more complicated and not so easy to develop and debug.Hi.,
I've had advice from this and other forums, and much of it seems as if it is what many of you are suggesting, and I've had it working with approval from the forums, but I never got the DATA to be synchronised, and my tests seemed to suggest it was timing related, so this is why I'm trying to guess how, the working peripherals are working.
They all have the MASTER sending the SLAVE the address where the DATA is in the SLAVE, as indicated in the D/S
This is what I'm trying to do.
It appears that my question is difficult to either understand, or the suggestions want me to try what I've tried before. I'm not sure.
The tests, I'm trying seem to be almost working, as I guess it all through.
Perhaps it's best, that I carry on with my existing tests, and I'll report back.
Thanks.
C
Hi N,There is no timing?, or 'synchronisation', it's not working because you don't know what you're doing and you're making it FAR too complicated. As we've explained, one device simply sends a request to the other one, the second one replies - end of story. It's easier to do via serial (and takes less pins), and far easier to debug and develop (as you can use a PC to test it in sections), but doing it via SPI would work just as well, just more complicated and not so easy to develop and debug.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?