Depends how embedded and how many servers it's talking to. I'm also not sure you can really tolerate false positives, since the main domain you talk to might get revoked, but there are alternatives to Bloom filters that eliminate those. In any case it's going to be hard to go below about 0.8-1 byte per revoked cert (common case where most certs aren't revoked) even with a fancy data structure.
You will surely want to shard the CRL, so if the device only accesses a few servers (and thus only has a few shards) then it'll be fine, but if it accesses many servers then there will be trouble, and you'll want to reserve extra space in case of a mass revocation.
I don't think this comment deserves to be downvoted. For the specific constraints imposed by embedded environments, a bloom filter seems perfectly cromulent here. The odds of a false positive scale according to the amount of memory that you can afford, and even in the event of a false positive it would fail closed, which is a better security posture than not checking at all.
You will surely want to shard the CRL, so if the device only accesses a few servers (and thus only has a few shards) then it'll be fine, but if it accesses many servers then there will be trouble, and you'll want to reserve extra space in case of a mass revocation.