 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Windows PC master and PicoMites as slaves
  Page 3 of 3 |
|||||
| Author | Message | ||||
| Volhout Guru  Joined: 05/03/2018 Location: NetherlandsPosts: 5214 |
Hi Phenix, Thanks for the details, below is my idea's about it (constructive critics). First of all a generic question ? Why not use MODBUS. It does exactly what you plan to do. But let's go to your proposal. There are 2 options: 1/ you design for single-drop RS422. In that case you can drop the address byte, since you know where the cabe is going, and one of the commands in your 16 wide command set could be "identify". 2/ you design for multi-drop RS422/485/rs232. In this case there is 1 master, and N slaves. The slaves have to synchronze the the masters message stream, and pick out the packets that are target to this slave. Therefore it has to (partly) decode the message. This means the slaves have to keep up with the masters datarate. This is why I would change the protocol. To be as fast as possible, you need to let the ARM doe the work, so make use of only a few efficient MMBasic commands. The commant I particularry have in mind is: LINE INPUT. This reads (ARM) UART data until it hits a <CR>. In your proposal you started with a header byte... drop that.. and add a termination byte..&h0D (or <CR>). That means that you can read a whole message with one command. There is a drawback... &h0D cannot be part of the message. Unless we use some creative thinking. Message proposal: -control byte (lower nibble = type of operation, upper nibble = number of data bytes to follow) -address byte (for multidrop RS422) -data byte -data byte -data byte -data byte etc. -checksum byte. -termination (<CR>) Note that I swapped nibbles in the control byte. By doing this the mosy significant nibble contains the length, and the message length is never equal to zero (the control byte itself is 1 byte), so &h0D cannot be in the control byte (high nibble cannot be 0). This means that the message length can always be read at left$(a$,1), and be compared with the length of a$. When not long enough,, do another LINE INPUT, until length parameter, and length of the string match. If you want to drop of early: when the length is >2 you can stop decoding if the address is not your address. But you have to read the whole message (length=len(a$)) to make sure you capture the termination<CR>, and stay in sync with the stream. Since the data inside the message can be any value (also &h0D) statistically each byte (16 max) can be &h0d (chance 1 in 256), so 1 in 16 messages will be a half message (or part of a message), and needs another LINE INPUT to construct the message. I hope this make sense. There is still a lot of MMBasic going on, but the most time critical is solved in ARM code (LINE INPUT). I hope this helps. Volhout Edited 2025-09-03 17:00 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 1511 |
Too clunky, only half-duplex and I can't use MMEdit to directly edit the code of each PicoMite. The Windows system is merely Data input/output but the PicoMites handle all of the sequence control. It becomes a true multiprocessing and multitasking solution. Need another process...add another PicoMite. I am unaware of anything on the market that can do this. Each PicoMite that is connected via USB can be a sub-master. If can command other PicoMites via UART/RS422 Full Duplex Multidrop. |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5214 |
Phenix, There is 1 catch if you want to use the same port from your messages, and for MMEdit. You need to design the message such that it can not contain ctrl-C. That is the command MMEdit uses to stop running code. The control byte is (as such) ignorant for the &h03 (ctrl-C) but the PicoMite firmware is not. It will stop execution. So ctrl-C can not be in the message. This can be achieved by changing the message content to ASCII (readable characters). Inefficient, but can be done. Volhout PicomiteVGA PETSCII ROBOTS |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 1511 |
  Great point!ASCII would not be a problem. It's what the other guys do. But what about: OPTION BREAK nn Set the value of the break key to the ASCII value 'nn'. This key is used to interrupt a running program. The value of the break key is set to CTRL-C key at power upand when a program is run but it can be changed to any keyboard key using this command in a program (for example, OPTION BREAK 4 will set the break key to the CTRL-D key). Setting this option to zero will disable the break function entirely. |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5214 |
Hi Phenix, Agree, that is an option. But then there is no way MMEdit can stop the remote running program in the pico, to edit it. The alternative could be to reserve 1 message that STOPs execution of the pico. To allow MMedit to take control. But this message must be designed such that it cannot occur in a normal transfer. An option could be to use CRC16 as the "check byte". There are several types of CRC16 - CCITT CRC16 - ANSI CRC16 - IBM CRC16 Use, for this specific message an alternate CRC method. Then the message will be ignored in any normal transfer. Then design a smallbasic program that sends exectly this CRC'ed code to let MMEdit take over control of the slave. Of coarse the message should contain the slave address, to prevent every slave to disconnect. Using this method, combined with disabling ctrl-C, and CRC on every message might even allow editing 1 pico in a multidrop running system. The system is not 100% fail safe, but it may be sufficient for your project. Volhout PicomiteVGA PETSCII ROBOTS |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8051 |
I personally wouldn't use USB full stop. There's no real reason to and it exposes the console input, which to my mind is insecure even if it does make things easier. RS485 would only use 2/3 pins and you still get the buffered COM port. It simply has too many advantages to list, although you'll have to splash out a quid for the chip and a terminator. :) You can even have full duplex if you want. If you simply have to have both UARTs available then it's definitely possible to write another UART using a PIO. There's an example in the Datasheet. It's just that MMBasic won't recognize it natively. Of course, if you are using a USB hub and the Picos are less than 1m away from it you are probably ok using that. The leads cost more than the RS485 chip though. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 1511 |
Each UART with MAX3491 becomes FD This is what I've been doing:  What has worked extremely well for me is remote installations (apart from time zones ) and diagnostics.I do quite well with hooking-up to my Android tablets via TeamViewer but editing code has always involved some inconvenience. This approach would make things a little bit easier. Clients love it because they avoid the costs associated with me having to be there. I'm not worried about USB. There are industrial USB devices on the market. A few years ago: "CAT5/CAT6 is absolutely not suitable for machine control" Today: "Hey TwinCAT and EtherCAT are the way to go. We can achieve real-time control and 100Mbs over CAT5/CAT6" |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 1511 |
I have very few commands for my command nibble. Zero command could trigger a program END(?) A good thing here is that it can be an orderly shutdown (disable servo-drives, etc.) |
||||
Bryan1 Guru Joined: 22/02/2006 Location: AustraliaPosts: 1535 |
just be careful stretching the Cat that far you may endup with a few scratch's |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 1511 |
I'll get yer coat |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 1511 |
I figure I'm gonna try this but keeping the USB as short as possible and away from PWM. BUT I totally welcome ongoing questioning/debate. I truly, truly believe that we have something here that can easily kick butt with what brainwashed engineers have been programmed to believe. If it ain't broke...well break it and do something better  |
||||
| Page 3 of 3 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
