To answer the question of how to package the ciphertext and IV, concatenation should suffice:
IV || ciphertext || tag. This format is convenient because it allows streaming of encryption. You generate and send the IV, stream the encryption, then calculate and send the authentication tag (decryption output can't be streamed however as the tag must be checked first).
The downside of course is that it makes it more difficult to change the algorithm or to support multiple algorithms. You could include an unencrypted algorithm identifier, but you would have to be very careful, as an attacker could change it to whatever they like, opening the door to downgrade attacks.
But you're wanting to do this with a pre-shared key as an alternative to TLS, so there's a lot more to it than that. TLS doesn't just provide confidentiality, it also handles key management and authenticity (among other things). The problem with a pre-shared key is that you have to be very aware of the constraints. RFC 4107 is worth a read.
ChaCha20-Poly1305 and AES-GCM both use a 96-bit nonce, meaning there is a 50% chance of repeat after 248 messages when using random nonces, so the key should be changed well before that (NIST says before 232 messages for GCM). It's also possible to use a counter instead of a random IV for certain algorithms, but there are difficulties with that as well. Due to this risk, the RFCs for ChaCha20-Poly1305 and AES-GCM as used in CMS both require that an automated key management system be used.
The simplest key management system is symmetric key-encryption keys. A content-key is randomly generated for each message and used to encrypt it, and a pre-shared key is used to encrypt the content-key to send along with the message.
Your question mentions a salt, which implies that you're using a password. This is a bad idea. To derive a key from a password requires a slow KDF like Argon2, bcrypt, or PBKDF2, and a constrained device is likely not fast enough to run such a KDF with a high enough cost to be secure. It would be much better to generate the pre-shared key with at least 128 bits of entropy. Confusingly you also want to transmit the salt, which implies that the password is changing, but this contradicts your comment that you put a "key" on the device.
TLS provides authenticity, which is important because commonly used encryption modes like CBC and CTR are malleable. It would be best to use an AEAD mode like ChaCha20-Poly1305 or AES-GCM, or, failing that, to use an HMAC with Encrypt-Then-MAC.
On constrained devices that aren't capable of generating cryptographically secure randomness (and thus can't generate a random nonce/IV or a per-message key), a pre-shared key with a stored nonce counter might be the best you can do. You just have to be very careful to make sure that nonce reuse is prevented even when the device is power cycled, and make it as easy as possible to change the key if/when that becomes necessary.