Maple Mini serial voltage « LeafLabs Garden

LeafLabs Garden » Support » Maple Hardware Support

Maple Mini serial voltage

(15 posts) (2 voices)

Started 3 years ago by jake1981
Latest reply from jake1981

jake1981
Member

Hi.

I am thinking about using a maple mini in my project. It seems perfect for my needs-- except for a one thing that I am wondering..
I need to use 1,2 or maybe even 3 of available usarts in my project as serial ports and documentation does not say properly what is the working voltage..

Documentation says that I should not connect them directly to rs232 port as either maple or my device in port uses 12v.. o_O
Is Maple using 12v in it's ports? Well, then it's going to be tricky to use in my project :/

On the maple mini doc I find that tx1&rx1 are 5v tolerant, so I can use 5v serial on these? (Connect to arduino for e.g.) - what about rest of the ports, can I interface with.. For example, raspberry that is using 3.3v serial..?

Serial voltages should definetly be added to the docs..

Posted 3 years ago #
gbulmer
Moderator

jake1981 - The Maple Mini STM32F103 runs at 3.3V. That is the maximum voltage a Maple mini MCU pin can produce.

"5V tolerant" means that a pin can be driven by something external to the Maple mini to 5V without damage to the Maple mini MCU.
Maple mini can not drive a pin directly to 5V, but the pin can be pulled upto 5V by an external device, or by a pull-up resistor without damage. So you may be able to connect to and drive the USART on a 5V device by using components external to the Maple mini. Some USARTs which run at 5V are designed to be driven by lower-voltage (3.3V) signals, and may work 'directly' (it is comon to put a resistor in series on each connection to ensure one device can't short the pins of the other device).

RS232 typically runs at +/-12V (potentially even higher). So connecting any Maple mini pin directly to RS232 will damage the Maple mini. There are implementations called "TTL RS232"; those typically run at 0-5V, not +/-12V.

If you need a clearer or more complete explanation, you will need to post more precise and accurate details of what you are trying to do.

(Full disclosure: I am not a member of LeafLabs staff.)

Posted 3 years ago #
jake1981
Member

Sounds perfect for my needs- just had to be sure about 3.3v on usart and was hoping for 5v for possible future projects..

Okay, my project has a doorbell camera connected to raspberry with rs485.
I am planning to add a TTL jpeg camera from adafruit and a rs485 module to maple mini. Camera runs with 5v but has 3.3v serial.
Currently I don't have 3.3v rs485 modules but they are being shipped now as are maple's. Arduino with mp3 shield is wired to doorbell
and send a Message to raspi about doorbell press, raspi checks if we are in silent mode- if not, asks arduino to play tune.

After this it contacts maple mini and requests for a image from camera and saves it.
Converts it to suitable format and sends it to another arduino with display which then
displays it.

I made some initial tests with arduinos and had some progress but I had to forget
my protocol plans for filetransfer.. Because arduino can listen for one serial only
At time- so while sending image it listens camera and sending only is active on rs485.

Cannot switch listening with cam and 485, Because if I listen to rs485 camera needs reset
To talk with board again and looses the image.

What about maple mini.. Can it listen on multiple usart interfaces at same time
Or is it the same and I need to switch with Serial1.listen() or something similar?

Posted 3 years ago #
jake1981
Member

Serial1.listen() is not in docs atleast, but I first planned to do this with arduino and as it didn't workout
I was pretty disappointed and don't want to get my hopes up if maple comes with the same limitation. Such
Limitation doesn't seem to be in docs - like ain't SerialX.listen() as well, so this far it seems perfect.

I plan to power the maple with 5v which can also then power the camera. Possible is also
To add more sensors to maple like temperature and a pir.. But let's start with cam and rs485..

Posted 3 years ago #
gbulmer
Moderator

jake1981 -Maple has three complete hardware USARTs. There is no need for SerialX.listen(). Each USART can send and receive data simultaneously.

Your program needs to read each USART often enough to retrieve data before the next character arrives. Or your program needs to set up DMA, to receive data directly into memory, but still it needs to use it in a timely way.

The specification for the Maple chip is at
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00161566.pdf
A Maple mini is a LQFP48 part (STM32F103CB)

Arduino's software-serial-library has listen() because the library code can only listen to one 'serial port' (really only software) pin at a time.

Posted 3 years ago #
jake1981
Member

Thanks. As this is the case, maple is going to do what I needed.

About the protocol, I am planning to make it very simple and it's going to be using AT commands or something similar so I think it's not going to be that hard - after all, rs485 that I have planned using, is half duplex, so only 1 device can send data on-line, and while reading - you cannot write. Here's some thoughts of how I planned it..

ATSETxx=zz#
sets setting XX (hex) to value ZZ (hex). For example packet size. After it's done, return OK# to master.

ATGETxx#
returns value of setting XX (hex) with VALzz#

ATIMAGE#
Takes a photo with ttl camera and returns OK# or ER(ror)# to master

ATFSIZE#
Returns filesize of jpeg in the camera in bytes as FSIZExxxxx# xxxxx is 00000 if camera has no image taken

ATSENSxx#
Returns value reported by possibly connected sensor number xx(DEC or HEX, not decided yet). SENSxx# where XX is hex.

ATCAPAB#
Returns capabilities of device (has camera, kind of sensors with numbers..) way device answers is not yet decided.

ATDOWNLOAD#
Starts download of image file from camera. Master goes to filereceive mode and packet transfer starts.
byte check is introduced and every byte from camera that goes to packet is added to this variable. I know it goes round when it
goes beyond 255, that's the point. After this, check is sent over serial to master. And after that bytes from image are sent till amount set is equal to packet size, slave goes to listening stage with rs485 and waits for OK# or ER# from Master. Master has 2 seconds timeout set, so if packets lost, they don't get counted to byte check2 that master calculates incoming bytes into. After amount of packet size is received, or timeout has occured- master equals check and check2 and if they differ it's ER# otherwise OK.

I am not yet this far, but this is what I initially had in my mind - before changing states of rs485, device has to wait until all data is sent and flush, so it's not going to be ultra fast so I guess I don't need DMA.. Similar testing already is done with arduino (more simple protocol, without any checks because of arduino serial limitation described earlier)

I know my file transfer protocol has it's flaws, but.. I think it suits this and is simple enough to not fill the rs485 line with protocol chit chat - less chatting, more actual data :)
Well, actually I already see, that I should sent amount of bytes in a packet before I send check number as initial packet size is 56 bytes - bigger packets mess up the line, with protocol like this.. I guess it should be 52 bytes.. We'll see.. But anyway, last packet propably isn't full 56 or 52 bytes, in some cases, it might be just 1 byte..

Anyway, shipping to Finland takes ages, and I am trying to build a Master software for raspi during shipping and decided to go with Lua language with librs232 library because I chose openwrt as my distro and it prefers Lua. I never programmed with Lua before, so I am still far from getting anything properly done, but I am not in a hurry - it's supposed to be a hobby project that might turn out usefull..

I never done anything before with arduinos and I decided to go Mapple as I already became a bit familiar with arduino and maple is like arduino, but more advanced in a necessary way for my needs..

Planning to build it in a way that there wouldn't be so many components soldered together, so it could be easily taken a part if I figure out a different project some day--

And sorry for all the lingual headache I've caused with my posts :)

Posted 3 years ago #
gbulmer
Moderator

jake1981 - Why do you need such long commands?

There appears to be only 6 or 7 commands, and you seem to be able to choose anything that suits the purpose. I would be tempted to use 'A', 'B', 'C', 'D', 'E', 'F', (or '0', '1', '2', '3', '4', '5', '6', ) etc.

With those long commands, each end is going to have to get all the characters, buffer them, check they are accurate, be prepared to do something appropriate if they are not valid. What benefit do you get for that complexity?

Similarly why 'OK#'? Why not '0', '1', or 'Y', 'N', or something simple?

If I were worried that the communication mechanism were unreliable or subject to noise, I might use parity (the hardware will do that), and maybe checksum every packet (to make the communication simple and consistent)

The protocol description doesn't explain what would happen if there is an error. For example, it doesn't say how the ends might re-synchronise after an error. If the protocol is going to have these failure states, then you need to decide what to do when it reaches a failure state, and also are all the failure states equivalent.

If damage to the protocol is a real concern, ensure it is "restartable". For example, the packets of picture might carry a sequence number (or byte offset within the picture) so that a packet can be retransmitted.

I would also be extremely tempted to make all exchanges easily printable, i.e. printable ASCII, so that it is easy to build tests by hand (using a dumb text editor), and easy to use e.g. diff to check that things are working correctly. This also avoids problems where some systems might convert some binary values to something else (e.g. libraries which convert line-feed carriage-return)

Hence I would probably unpack an 8-bit binary (picture) into a stream of 6 bit (ASCII printable) values at one end, and back to binary at the other. This is easy code to write, but might help testing and debugging.

Write the code for your proposed protocol using simple one-byte-at-a-time I/O. I think you'll want to ditch a lot of its complexity.

Posted 3 years ago #
jake1981
Member

That sounds good idea. As I said, I only have ideas and a concept - nothing is complete yet. There is also a calling mechanism needed (to which device should we be talking with) and a hangup command. Always on failure/unknown or corrupted command device does not answer at all and returns to idle state to wait for commands so garbage on the line is ignored, this way - longer commands make it more fool-proof as one letter(byte) changing to other, won't be understood as a wrong command- and also it is more human readable when debugging.

There is no line-feeds, # is instead. Master device has time-out while waiting a reply and if no reply is received- it sends the command/query again.

Might be that I ditch the at style commands but I wouldn't want go with that simple protocol as single byte commands can cause mis-understandings on receiving end on failure. I have to check that parity thing but I am pretty sure it won't work- these rs485 modules have 5 connections to board.
3.3v-5v, gnd, driver enable, rx, tx. When I want to receive data de is connected to pin with low output and when I want to transmit, de must be on pin with high output. There are also modules with auto-switching - but these are the ones that I already have bought so let's not waste all my funds as I already have wasted enough by buying staff not suitable for this project - for e.g. Those arduinos.

Well, they are not going to be wasted- I'll find other uses for 'em at time being and device with display is going to be arduino(due) driven anyway since maple doesn't have enough pins for touchscreen+sd+proximity sensor+piezo buzzer+rs485 module..

Posted 3 years ago #
jake1981
Member

Although, Because of difficulties I have encountered with Lua, I might also go with Python and pySerial. Lua changes too much when new versions are introduced, I wasn't able to get librs232lua to compile for latest Lua 5.2.1 and both Python and Lua are unknown for me, but Python is easier to get started with, all necessary packages are already available as binaries.

Although, Lua would be more light-weight, but if that's what I am only after - I should go with C..

OpenWRT doesn't come with native toolchain, they prefer cross-compiling on "a real computer" but both; Lua and Python are available, which I think is important on project like this as I don't need to install gentoo on a virtual machine along the proper toolchains everytime I want to make changes to source code.

Posted 3 years ago #
gbulmer
Moderator

jake1981

Always on failure/unknown or corrupted command device does not answer at all and returns to idle state to wait for commands so garbage on the line is ignored

How do you ignore garbage data? What if the 'end transmission' byte gets damaged?

longer commands make it more fool-proof as one letter(byte) changing to other, won't be understood as a wrong command

Repeat the one letter N times. That might actually be more robust. I don't think data communications is about being 'fool-proof'. A more complex piece of code certainly has more opportunities to be wrong. Go write the code in C, for Maple or Arduino, and see which is easier to write, easier to test, and more obviously understandable.

I think what you are assuming, or trying to describe, is error detection (I recommend also looking at correction):
http://en.wikipedia.org/wiki/Error_detection_and_correction
http://en.wikipedia.org/wiki/Hamming_distance

I'd recommend you look at those.

Let's separate two ideas:
1. Sending data
2. Error free communication

If you separate those, you can adjust the two individually to suite the problem. For example, you can get as much error detection (and correction) as you like without trying to solve that problem in the data; you won't have to redesign and rewrite the message protocol just to cope with more, or fewer, errors in the communications. So you could use techniques which not only detect the error, but also correct it, without changing the data encoding at all.

This approach is called layering.

I suspect that the error rate for a good installation using RS485, over some reasonable wiring (e.g. twisted pair) might be extremely low. The long commands don't give help. They might even make things worse by increasing the number of bytes transferred, and hence increase the number of bytes corrupted by noise. But that isn't really the point. By separating the two requirements, you might get enough adaptability to do them both well, rather than tangle them together, and compromise both.

There is no line-feeds, # is instead. Master device has time-out while waiting a reply and if no reply is received- it sends the command/query again.

Okay, so you intend to use only printable ASCII? If so, good.
So does time out mean the send got corrupted, or the response? If it is the response that got lost, is that okay? It might be reasonable to acknowledge error-free receipt of the data.

Might be that I ditch the at style commands but I wouldn't want go with that simple protocol as single byte commands can cause mis-understandings on receiving end on failure.

Again, try to separate the design of the data from the error detection and correction. This is usually implemented as a 'layered' protocol, so that changes in one layer don't effect another. It is certainly easier to write software to read and use one byte commands, than variable length, multi-byte commands.

For example, how the end-points are identified (on a bus-like transmission medium) may be independent of the messages.

I have to check that parity thing but I am pretty sure it won't work- these rs485 modules have 5 connections to board.

Parity is not about the number of wires, just as checksums, CRCs etc are independent of the number of wires.

I strongly recommend reading http://en.wikipedia.org/wiki/Error_detection_and_correction
Try to separate the design of the messages from the mechanism used to detect (and correct) errors.

You may ultimately come to the view that the two can be entangled, but while trying to understand what works, try to separate them. You might discover a large set of issues that you haven't thought about once you start to actually build the software and system.

Posted 3 years ago #
jake1981
Member

Thanks. This has been a great conversation. As command set has low amount of commands- it is quite good idea to make commands to be 2bytes with same character. AAFFFF## for command A with value 0xFF(255) for example.

This has been more fruitful thread that I imagined- just by asking some technical details, my protocol has gone better. :)

Posted 3 years ago #
gbulmer
Moderator

jake1981 - I am pleased to help people who are clear, ask questions well, and have done some work and thinking (i.e. not just asking us to do everything :-).

Best of luck.

Posted 3 years ago #
jake1981
Member

Yes. About that - it's time to start programming of the Master device's code so I'm off - but I'll check here every now and then just in case someone has a great idea to improve this idea. I work full time at my job, so this is only a hobby and it will take a very long time for this project to finish but I'll keep posting for updates once I have some parts working :)

Posted 3 years ago #
jake1981
Member

Some initial RS-485 testing..

http://forums.leaflabs.com/topic.php?id=9744

Posted 3 years ago #
jake1981
Member

Hi.

I promised to post some results ones in awhile.. So here goes..
---

Idea has evolved to a full alarm system with camera surveillance (non video, only stills).. With still also working as a doorbell camera, sensors also send other data as well, plans are that "normal" sensor module would be based on maple mini that has 1-3 PIRs, 1 serial jpeg camera, LDR, MQ2, SHT11 or SHT22 (depending is device outside or inside) 1 rgb led, 1 buzzer.

I decided that system needs an automatic reset on failure + I wanted to make it fully modular (while respecting rs485 max. 32 nodes..).. And this system no longer works with just maple and raspberry Pi, I also plan to have atleast: 1 arduino Due and 1 Arduino Mega.

Arduino Due becomes the keyboard and status monitor of this system: it has a touch screen on it and with initial tests it also works. I also posted some libraries on Arduino forums as I added initial picojpeg support to display library. This could propably had been done with Maple too, but I decided to go with Arduino Due, as Arduino(not due) had some libraries premade-- porting them to Due was some work, porting them to Maple - would had been even more..

Okay, what for Arduino mega then? Arduino Mega was chosen since it is a 5v device, I add a mp3 shield for it which is then connected to amp and speakers, there's also 1 button (doorbell) and possibly a rgbled (doorbell device light). Oh, the most important thing - this ships also with a 5x74hc595 chips that are control 4*8x5V relays which power up all the sensors and RasPi + 1*8x12V relays. Relays all are opto-isolated. 12V relays are the to power up, for example, siren.

This mega device also has internal wdt enabled for booting the system if problems are encountered. There should be some ports left, so this could also be monitoring voltage of backup battery..?

---

Ok, how am I planning to make this work?

When system gets powered; Only Arduino Mega controlling relays will start, I earlier told you about my rs-485 initial test. Devices have phone numbers.. Check that.. Arduino Mega is now on called relayBoard. 2 devices on the system get fixed phone numbers:
RelayBoard and RasPi. Although, RasPi is the one calling, so it wouldn't need a number - but it's for future purposes. When other devices start, they have initially phone number 99 or something.. Now one would think that how can this work, all the devices have same phone number, so rs485 line is full of garbage pretty soon since everyone is answering..

On a boot up, relayBoard powers up RasPi and waits for it to end it's booting process (let's say, 2 minutes to be sure..)--
RasPi then asks relayBoard to power up relay1. When device powered up by relay1 is ready it answers to phone number 99 and raspi asks it to take phone number 1 for itself and maps devices capabilities. And this is done for every device connected to system. If a new device is added - and system is rebooted, it gets automaticly included in the system; therefore: modular.

Well, almost. New device still has to be configured in raspi ( is it supposed to start alarm if state is armed, or is it a doorbell like device, for e.g.).. But adding devices should be pretty hassle-free this way..

RasPi also calls these devices one by one and if one isn't answering on.. let's say 3rd time in a row when called.. RasPi decides that device has been lost and asks relayBoard to cycle power on that device. After device reboot, RasPi gives back the phonenumber and what ever raspi had set on the device earlier.

What about raspi then? what if it get's hanged. Well, I could activate raspi's wdt.. But nope. RelayBoard listens for rs485 communications. If there is no data going on the rs485 - it decides that raspi/system has hanged, kills power on all relays and reboots itself by stopping renewing it's wdt timer. When system has restarted - raspi logs that system has started on date+time.. If system is programmed to restart automaticly, let's say.. 1 in a day for some reason.. Before raspi commands halt for itself (rs485 stops and in 2 minutes relayboard resets all) it logs that it's restarting the way it was programmed, so it's easy to find from log if restart was due to failure in the system or.. Requested for reason..

Yes.. Here's some theory, and it's far far far away from any progress-- building relayboard currently and waiting for miscalleneous parts to arrive from the world..

Posted 3 years ago #

RSS feed for this topic

Reply

You must log in to post.